There are three issues here as I see it: content, style and recon.

1.  Content.  Think about EAD as multi-level description, not as a
specification for page-form presentation of information.   That, in my
mind, is a fundamental shift in how the profession thinks about
inventories and registers.   EAD challenges us to think about this data
in a new way.

   Every EAD component element is the description of a unit of archival
materials.  There is a correspondence between the intellectual concept,
its physical manifestation and its description.   Given this, we can
imagine manipulating and reusing each component descriptions in a
variety of ways, not just laid out in a linear sequence on the page or
screen.   If we can manipulate and reuse the data and if we can store it
in a variety of ways (encoded text in a file; as relational tables in a
database; as objects in an object-oriented environment, etc.), then we
have to start to think of how these components might sometimes have to
stand alone; sometimes stand along side their parents and children,
sometmes stand with their siblings, or sometimes with all of their kin.
In such an environment we may well want to have all the informational
elements relating to a component (including its physical location and
container designation) as part of its own descriptive package.

    The problem is that in the present page layout of many inventories,
location and container data often appear some distance away from the
component in question- often lined up with a sibling component.  We
visually make the association and the implied inheritance.  Computers
are obviously not so smart as we and have a difficult time making such
connections.   There may prove to be even more future situations- beyond
the very clear one that Elizabeth Dow describes- where we want to have
this data actually embeded in each component.   There have been lengthy
discussions of this problem and no easy solutions.  We certainly don't
want to start thinking of the container as the component.  That causes
far more problems than it solves.

     There is another solution within EAD- the PARENT attribute on the
<container> and <physloc> elements.   This attribute (in component A)
points to the ID attribute of another component (B) wherein the physical
location and container of component A is given.  It create a link based
on physical location and container info.   Now actually implementing
this manually may be more complex that just rekeying of the data in each
component, though it may be suitable for inclusion by machine
manipulation using a script.

     In our EAD workshops, Kris and I discuss this issue and the pros
and cons of repeating this data with every component or not.   I'd say
that the response seems about evenly split between the options which
would be consistent with the variety of solutions one sees at EAD sites.

2.  Style-  Encoding the text is one thing.  How it displays on the
screen is another.   As Maxs point out, one ought to be able to write
something into a stylesheet that would cause only the first instance of
a physical location and container to actually display.   I'm not sure if
the limited conditional scripting in Panorama could manage this.  Since
XSL lets one invoke scripts such as perl or ECMAScript, such
manipulations should be relatively simple to program.   Compare the data
in this <container> with the previous one; if it's the same, don't
display it.    It gets more difficult with screen displays that roll.
What we need is a running header function that would keep such data at
the top of the page.    But that too is a display problem not an
encoding issue (assuming that one has actually included the data)

3.    Recon.   Even if we start adding ever container and physloc
explicitly in all new finding aids, what will we do with legacy data?
What's the value vs cost?

Michael
Michael Fox
Head of Processing
Minnesota Historical Society
345 Kellogg Blvd West
St. Paul MN 55102-1906
phone: 651-296-1014
fax:  651-296-9961
[log in to unmask]
**NOTE NEW AREA CODE EFFECTIVE JULY 12, 1998**

> ----------
> From:         Katherine Hayes[SMTP:[log in to unmask]]
> Sent:         Thursday, October 01, 1998 3:12 PM
> To:   Multiple recipients of list EAD
> Subject:      More confusion over tagging containers!
>
> The waters muddy further!  In my quest I surveyed four web sites with
> guidelines
> for EAD tagging. They all differ slightly in their recommendations and
> examples.
>
> The American Heritage Project's Retrospective Conversion Guidelines
> (for EAD
> beta) show the 'old' way, i.e., a box for every folder, in their
> "Template (without
> tabular layout)". See http://sunsite.berkeley.edu/amher/upguide.html
>
> Harvard/Radcliffe's Guidelines for using the EAD v. 1 gives examples
> of both
> ways at http://findingaids.harvard.edu/dfap/eadguide.html
>
> Research Libraries Group, in their Recommended Application Guidelines
> for EAD,
> Appendix B, Sample Finding Aid, are using the newer way. The box
> number is
> only given once unless the series/subseries changes within a box. Then
> it is
> repeated after the series/subseries <c0X> tag.  See the hyperlink in
> the Guidelines
> at http://www.rlg.org/rlgead/tool2.html
>
> Finally, the Bentley Library's EAD Tag Set (for beta, with notes of
> v.1 changes)
> seems to promote the new way also, although it's not completely clear
> to me.
> http://www.umich.edu/~bhl/EAD/bhltags.htm
>
> All of the above are great resources.  Any comments or clarifications
> from authors
> or users of the above?
> <><><><><><><><><><><><><><><><><><><><><><><><><><>
> Katherine A. Hayes, Assistant Archivist
> Niels Bohr Library, American Institute of Physics
> One Physics Ellipse, College Park, MD 20740
> (301) 209-3179  [log in to unmask]
> <><><><><><><><><><><><><><><><><><><><><><><><><><>
>