 |
 |
How about using @parent? In terms of locating something, you could convincingly argue that the shelf is the “parent” of the box – e.g., shelf 3, box 5 would
look like this:
<physloc id="shelf3">shelf 3</physloc>
<container type="Box" parent="shelf3">1</container>
If you have box and folder, you can connect all three via the parent attribute:
<physloc id=”shelf3”/>
<container id="mss1993-043" parent=”shelf3” type="box">1</container>
<container parent="mss1993-043" type="folder">1</container>
FWIW, we don’t store physical locations in EAD at all because we don’t want to have to update our finding aids every time we move collections around. In addition,
for security reasons we prefer not to have that information publicly available at all. I wonder how many of your users actually want this information exported in their EAD in the first place?
Michele
From: Encoded Archival Description List [mailto:[log in to unmask]]
On Behalf Of Dan Gillean
Sent: Wednesday, April 17, 2013 2:09 PM
To: [log in to unmask]
Subject: Establishing a relationship between containers and physical location
Greetings colleagues,
My name is Dan Gillean; I am one of the Product Managers for ICA-AtoM, an open source, web-based archival description software application (www.ica-atom.org).
I am wondering if anyone here might have some thoughts on managing relationships between physical location(s) and containers.
AtoM’s physical location manager was added before my time and, pending development support from our community of users, something we hope to improve in future. For now, I am working
to revise our EAD import/export to conform to best practice as much as possible, while ensuring that user data is not lost when roundtripped. For context to my question, you can see our existing interface for linking physical location information by going
to our demo site, logging in with the credentials provided on the home page, (http://demo.ica-atom.org), navigating to one of the demo archival descriptions, and clicking on “Link physical location.” We provide 3 fields:
type (which contains values such as box, folder, etc. – mapped to <container type=XXX>), name (mapped to <title> within <container>), and location (mapped to <phsyloc>). This option to link physical locations is available on all levels of description, and
can be repeated. Consequently, while the use case is low, a user might reasonably include multiple location links in a single <did>, with different physical locations – if, for example, someone chose to link physical location information at the fonds or collection
level, indicating multiple boxes across different storage locations. Conceivably, it might also be possible within a single file-level description, if, say a file spanned several folders, which fit into 2 boxes, which happened to be at the end of a shelf,
meaning the second file would be in a new box on a different shelf.
My question is: given this possibility, is there some acceptable and/or best practice method for providing a relationship in EAD between a <container> and a <physloc>?
Some possibilities that have occurred:
1) Assigning an ID to the <physloc>, and the same ID to the related <container> (s), so we can relate them on import. We might also use @PARENT in the <container>, but my understanding
is that this should be used for a parent container, such as a folder in a box, and not to relate a container to a location.
2) One of our developers has suggested using a <ref> element, which is available within both <container> and <phsyloc>, to link the two – but again, I have hesitations about this
as a practice, especially if we want to keep our EAD export records interoperable with as many other systems as possible.
3) We have noted that @PARENT is available in both <physloc> and <container>, meaning it could be possible to add an ID to <physloc> and a corresponding @PARENT to the <container>.
However, my understanding is that @PARENT is generally used to relate two of the same elements: for example, a <container type=”folder”> inside a <container type=”box”>. We wish to ensure that we are conforming to best practice as much as possible, and that
we’re doing everything we can to support wide interoperability, and this solution seems like it might be a bit of a hack.
For those interested, you can see the context of our discussion on this issue on its related ticket, here:
https://projects.artefactual.com/issues/3850
Does anyone have suggestions, advice, or examples on how we might best maintain this relationship? Thoughts on the possible strategies listed above?
Here’s an example of the problem we are trying to solve:
<pre>
<physloc>Shelf 3R, Aisle 1</physloc>
<container type="box">
<title>box 999</title>
</container>
<physloc>Shelf 3R, Aisle 1</physloc>
<container type="box" label="hollinger">
<title>123-4</title> <!-- container with same physloc as box 999 -->
</container>
<container type="box" label="cardboard"> <!--a container without a physical location specified -->
<title>35</title>
</container>
</pre>
Thank you in advance,
Dan Gillean
AtoM Product Manager / Systems Analyst
Artefactual Systems, Inc.