Print

Print


In France, numbered <c0#> are not in use in libraries, and as far as I 
know, are not  much used in archival repositories either. We recommend 
the use of <c> elements and the @level attribute. The @otherlevel 
attribute is also used, especially when converting legacy finding aids 
where descriptions don't match a series/file/item pattern or something 
similar. A large number of these legacy finding aids date from the 
late-19th or early-20th century and their descriptions were not 
structured in the way they would be today. The collections they describe 
include both individual manuscripts and archival fonds so the use of 
numbered <c0#>, where each number would always correspond to a 
pre-defined description level, would not have been satisfying. When 
these descriptions are being revised today the <c> structure can easily 
be changed by modifying the value of @level or @otherlevel. It saves us 
a lot of re-numbering <c0#>.
I understand the need for human-readable cues but I don't believe that 
<c level="[value]"> is more difficult to read than <c01>, <c02>, etc. It 
also depends on the software you use to edit your EAD data. Most people 
over here use XML editors, where the tree structure, and hence the 
description level, is easy to see.

Florent Palluault
Coordinator of the upcoming EAD Guidelines for French libraries/
/

----- Message original -----
*De :* Michele R Combs <[log in to unmask]>
*Pour :* [log in to unmask]
*Envoyé le :* 15/04/2010 11:34:25 PM +0200
*Sujet :* Promoting Container Levels


> Well, the numbers mean something in the sense that it's easy to see at 
> a glance how far down in the intellectual hierarchy a given c0# is -- 
> a c03 is 3 levels down -- and you know that a given c03 will be 
> intellectually (and XML-ly) a child of the first c02 encountered above 
> it.  Of course one can do the same thing by counting ancestral c0's, 
> but that requires a lot more thinking.  I guess in the end it depends 
> on whether you're likely to have human eyes looking at the EAD at some 
> point.  If so, the numbers are a nice human-readable cue.  If not, 
> then as several people have said, it doesn't really matter because 
> computers don't care, so as long as you a) do it consistently and b) 
> write, or choose, your output handling (XSLT or whatever) to deal 
> correctly with whatever option you choose to go with, you'll be good.
>
>  
>
> My personal preference is to include the human-readable cues because 
> you never know when the automagic processing will crap out on you and 
> you'll need a human being to fix it ;)   Also, if you go with 
> unnumbered, doesn't that mean you have to set the level attribute for 
> every single <c>?
>
>  
>
> Either way, I wonder how often Nathan's situation of needing to 
> promote/demote c0#s comes up?  Seems like it would be a fairly rare 
> occurrence.  We've created or converted about 2000 finding aids so far 
> and I can only think of one occasion when I had to do it.
>
>  
>
> Michele
>
>                                                                                                                 
>
>
> *From:* Encoded Archival Description List [mailto:[log in to unmask]] *On 
> Behalf Of *Ethan Gruber
> *Sent:* Thursday, April 15, 2010 4:15 PM
> *To:* [log in to unmask]
> *Subject:* Re: Promoting Container Levels
>
>  
>
> I think a problem lies in the perception that the numbers in 
> components have some sort of "meaning."  A c01 can be a series or an 
> item.  It is semantically incorrect to place emphasis on the numbering 
> system at all.  Suppose you were to process your collection into two 
> outputs for comparison.  For the first dataset, you strip out all the 
> level attributes and only have numbered components.  For the second 
> dataset, you replace all the numbered components with unnumbered <c>, 
> but retain the level attributes.  Clearly the second dataset retains 
> intellectual meaning.
>
> I can kind of see how <c level="series"> may be a little more 
> difficult to read than <c01 level="series"> if you are using a simple 
> text editor like NoteTab, but it seems like renumbering a collection 
> is a nightmarish scenario.  It seems as if there are not many 
> institutions that use unnumbered components.  The EAD cookbook 
> stylesheets don't work out of the box on a collection with unnumbered 
> components, I think.  It assumes top level components are c01 and that 
> template calls c02.  Any sort of machine processing is greatly 
> simplified by getting rid of numbered components, and I think the 
> community is trending towards using software applications to create 
> EAD rather than a slew of workflows in which guides are manually made 
> in NoteTab Pro or other such text editors.
>
> Ethan Gruber
>
> On Thu, Apr 15, 2010 at 3:14 PM, Jordon Steele <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
> Creighton,
>
>  
>
> We do <c>.  Archivist Toolkit's default output is <c>, not numbered 
> components (although there is an option).
>
>  
>
> The main problem for me is not technological at all---it's really hard 
> for a human being to read the code if you don't have cues like <c01>, 
> <c02>, etc.  Otherwise, it works fine.  When our tech guy was creating 
> our stylesheet, I asked him if having non-numbered components was an 
> issue, and he said that it was not.  I believe, like you indicate, he 
> just wrote the XSLT with the level attributes to differentiate.
>
>  
>
> Best,
>
>  
>
> Jordon
>
>  
>
> Jordon Steele
>
> Archivist
>
> Biddle Law Library
>
> Penn Law School
>
> 3460 Chestnut Street
>
> Philadelphia, PA 19104-3406
>
> (215) 898-5011
>
>  
>
> *From:* Encoded Archival Description List [mailto:[log in to unmask] 
> <mailto:[log in to unmask]>] *On Behalf Of *Creighton Barrett
> *Sent:* Thursday, April 15, 2010 2:21 PM
>
>
> *To:* [log in to unmask] <mailto:[log in to unmask]>
> *Subject:* Re: Promoting Container Levels
>
>  
>
>     This could be different from what is under discussion here, but I've
>
>
>     seen "false levels" at multiple institutions while cleaning up batches
>     of EADs. As far as I can tell, the main reason component padding has
>     been done historically is for display purposes. Some processors in the
>     past may not have understoond CSS or didn't have access to the finding
>     aid CSS files.
>
>
> For us, it was not a matter of CSS padding, it was problems that 
> occurred during XSL transformation.  The XSLT we were using was a 
> tweaked EAD cookbook stylesheet that couldn't handle a collection that 
> had series with sub-series and series without sub-series.   For 
> example, we were working with many collections intellectually 
> structured like:
>
> c01     Series: Vessel Papers
>
>          c02     Sub-Series: M/V "O.K. Service X"
>
>                 c03      File: Manifests
>
>                 c03      File: Captain's Logs
>
> c01    Series: Financial Records
>
>         c02      File: General Ledger
>
>         c02      File: Annual Reports
>
> As I understood the problem, the XSLT we were using was not testing 
> individual components to see if the attribute was series, sub-series, 
> file, etc.  It thought all c02s were sub-series and would not 
> correctly transform c02s that were files.  That might be a simple fix, 
> but it was beyond our XSLT knowledge.  In the absence of a dedicated 
> XSLT person to write the XSL test for us, we added "false" c02 layers 
> to our series that did not contain sub-series so all files would be 
> encoded as c03s.  We then uploaded static HTML files into the 
> university's content management system, which controlled all the CSS.
>
> It was less than ideal, but it got the job done.  I am especially 
> interested in Ethan's comment about just  using <c> and @level.  Is 
> anyone else doing this? 
>
> Cheers,
>
> Creighton
>
>  
>