Print

Print


Dan,

Your email is timely.  There has recently been discussion within TS-EAD (the group currently working on revising EAD, which I co-chair), about the <physloc> element and the @parent attribute.  We struggled to envision a use case, but your question has helped me connect the dots.  One *could* use the combination of @id and @parent to bind two <physloc> elements, say a shelf and a range, much like the use you cited for a folder in a box.  So: thank you for the inspiration.

That said, I agree with Michelle and Kate.  Extensive use of <physloc> for tracking container location in EAD is probably a bad idea, though one that would be mitigated if the data is maintained in a database such as AtoM.

If your system and users require it, then I would more or less follow the examples Michelle gave.  Bind one or more <container>s to a <physloc> by referencing physloc/@id in [log in to unmask]  The only wrinkle to navigate is that you can't have a one <container> to many <physloc> relationship.

On an unrelated note: why are you encoding the contents of the <container> attribute in a <title> tag?  Title is intended for encoding the names of published works, not box numbers.  I would strongly recommend not doing this.  Nothing is final, but I'm fairly certain that in the revised version of EAD that <title> will not be permitted within <container>.  It is not permitted there in the current alpha version, at any rate.

Best of luck,

Mike



On Wed, Apr 17, 2013 at 4:50 PM, Bowers, Kate A. <[log in to unmask]> wrote:

I would second Michele's note about trying to maintain specific shelf address information in EAD.  Not only for security reasons and the changeable nature of storage, but from the reality that storage of holdings requires many-to-many and often complex relationships that EAD was never intended to manage.

 

Kate

 

---------------

 

Kate Bowers

Collections Services Archivist

Harvard University Archives

Cambridge, MA 02138

[log in to unmask]

voice: (617) 384-7787

fax: (617) 495-8011

web: http://nrs.harvard.edu/urn-3:hul.eresource:archives

Twitter: @k8_bowers

 

From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Michele R Combs
Sent: Wednesday, April 17, 2013 3:30 PM
To: [log in to unmask]
Subject: Re: [EAD] Establishing a relationship between containers and physical location

 

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.

www.artefactual.com