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]> 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]] On Behalf Of Creighton Barrett
Sent: Thursday, April 15, 2010 2:21 PM
To: [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