I am impressed by two things--your knowledge and your ability to
explain what you know to someone just scratching the surface of EAD.
Your examples are so clear. If you are not teaching, I encourage you to
think about it.
We do have the situation where collections are split between two levels
in one building. I think the curators who have been in the archives
here a long time are thnking of just listing the two locations together
in the same field, without specifying exactly which boxes are on which
level (if I understand what they have been saying correctly). They are
not bothered by simply going to the other floor if the particular box
they want is not in the first location. If this what they want to do, I
will let the Director and Head of Systems know about your suggestion to
do this in the Arch Desc/DID.
From your examples, I am beginning to see that EAD is a whole lot more
flexible than I thought. This is good, but like you, I do worry about
future migrations of data if the programming has had a lot of local
modification to meet local needs. I helped our library convert our
manual catalog to MARC--then the OCLC tapes were converted to NOTIS.
Later, I managed the conversion of our manual serial records files to
NOTIS at our main library; then later migrated this data to Voyager.
Even though these two systems were both created by Jane Burke, and were
somewhat compatible, there was still a lot of cleanup to do after the
migration--and some data elements lost--so I know what you mean.
I will not be the decision maker in this conversion to EAD, but the one
doing the actual conversion of older finding aids (typewritten, in older
word processing documents, and in Excel). I want to do my best to make
the best recommendations to the Director and to our Head of Systems, but
in the end, these two will be making the conversion and programming
decisions. I just want to be in a situation where what I am asked to do
is actually do-able under the constraints of EAD. After all, if the
data input is not up to "Hoyle"--at least at a minimum level, the
document will not validate. So were are all somewhat safe there.
Thanks again so much, Michele, for taking the time to explain all of
this to me in such detail--with such clear examples. This has helped me
more than you can know.
>>> [log in to unmask] 8/10/2005 11:40:13 PM >>>
> When I read the information about the Physical Location tag in the
> tag library, it seems that physical location information is input at
> container level. Am I reading this correctly? In other words, if
> had 30 boxes, you would need to input the physical location thirty
> as part of the information about each box.
> Is there a way to input the location of the collection at the
> collection level--for example, tie it to the collection number?
The LOCATION element, like CONTAINER, is
available as a sub of any c0# element, so if you have
an entire c02 (with c03, co4 etc subs) that was all in the same
location, then yes, you can put that information
at the c02 level. Some institutions are doing it that way, I believe.
You'd have to make sure that whatever you use to display
the finding aids knows that child elements inherit container or
<physloc>File Cabinet 42</physloc>
We on the other hand are doing just what you describe: including
CONTAINER and LOCATION information at the lowest
level, which you're right, does mean repeating it.
We decided on this approach for two reasons. First, while a lot of
whatever) were completely in the
same location, there were just as many that weren't. This meant that
finding aids would be done one way and others another way. We
encoding decision that could be applied consistently.
Second, we were concerned about relying on inheritance of information.
placing LOCATION information at a higher level, you assume that all
level (child) elements will inherit that information. The nested
an XML document makes that an understandable assumption. But we all
what happens when you assume things with technology!
<physloc>File Cabinet 42</physloc>
What happens to Doug? Does he inherit from the previous sibling,
Or does he inherit from his c02 parent, Photographs? Will your
method (XSLT or whatever) handle this correctly and recognize that
own location info needs to override the parent info? If not, can you
it or is it some proprietary content management system that you can't
change? What happens if some future use of the file is able to
fragments of the finding aid and it extracts Bill? Bill doesn't have
container information and if he's a fragment he won't have a parent to
Although we could make sure that any current in-house
uses of our XML documents would meet this assumption, we couldn't be
that all other infinite possible future uses would (e.g. search
future content management systems, other people's union catalogs, etc).
we decided to play it safe and include container and location
each lowest-level c0# element. It's not too much of a pain, really, a
of it can be done with macros or search and replace.
In the end, though, it depends on your situation. If you have entire
collections that are located off-site somewhere, it definitely makes
sense to put that information in once, at the top, and not repeat it.
that's the case, you could actually put the PHYSLOC up in the
rather than in the inventory at all.) If you have some complete c0#s
collections that are located other places (4th floor, Rare Books, 6th
floor), then it's pretty much your call which way you want to do it.
the nice thing about EAD -- it was designed to be flexible so for a lot
decisions there is no right or wrong way, there's just what works for