> When I read the information about the Physical Location tag in the EAD
> tag library, it seems that physical location information is input at the
> container level. Am I reading this correctly? In other words, if you
> had 30 boxes, you would need to input the physical location thirty times
> 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 c02s (or
whatever) were completely in the
same location, there were just as many that weren't. This meant that some
finding aids would be done one way and others another way. We preferred an
encoding decision that could be applied consistently.
Second, we were concerned about relying on inheritance of information. By
placing LOCATION information at a higher level, you assume that all lower
level (child) elements will inherit that information. The nested nature of
an XML document makes that an understandable assumption. But we all know
what happens when you assume things with technology!
<physloc>File Cabinet 42</physloc>
What happens to Doug? Does he inherit from the previous sibling, Charlie?
Or does he inherit from his c02 parent, Photographs? Will your display
method (XSLT or whatever) handle this correctly and recognize that Charlie's
own location info needs to override the parent info? If not, can you modify
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 extract
fragments of the finding aid and it extracts Bill? Bill doesn't have any
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 built-from-scratch
uses of our XML documents would meet this assumption, we couldn't be sure
that all other infinite possible future uses would (e.g. search engines,
future content management systems, other people's union catalogs, etc). So
we decided to play it safe and include container and location information at
each lowest-level c0# element. It's not too much of a pain, really, a lot
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 more
sense to put that information in once, at the top, and not repeat it. (If
that's the case, you could actually put the PHYSLOC up in the ARCHDESC/DID
rather than in the inventory at all.) If you have some complete c0#s within
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. That's
the nice thing about EAD -- it was designed to be flexible so for a lot of
decisions there is no right or wrong way, there's just what works for you :)