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]<[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****
>