I think you're spot on, especially with that last paragraph.  Also, in
your statement about EAD being an enabler of interoperability.  Given
EAD's laxity, it's still easier to predict the existence of a given
element using an XPath search on a known element name than it is to try
to predict the location or existence of a piece of info in a random HTML
file.  I've used this listserv this week as a platform for why the music
community should seek its own solutions, and hopefully I've done so in a
manner that doesn't put down EAD.  This is the music community's issue
to solve, not EAD's.  I just simply don't think EAD should try to become
any more general than it already is for *bibliographic* description,
unless we can build it in after having the needed conversations and
actions regarding lax descriptive practices extant in the *archival*

For what it's worth, I don't think the lack of interoperability comes
from directly from EAD.  The makers of the DTD have done as best as they
can to keep up with the various national and international content and
presentation standards that exist.  IMO the real focus needs to be on
determining what level of prescription can be added into new standards.
I've argued in the past that archivists (at least Americans) don't beg
for flexibility in descriptive practices per se.  If prescription
existed, I sense the rate of standards adoption, compliance, and usage
would rise.  Most archivists I speak with essentially say they'd like
prescription from the data content and presentation standards.  Now that
DACS/CUSTARD has ended (this might not be accurate, as I never heard
what happened to the project), I urge the standards creators to at least
research the demand for more prescription when developing the new
content standard (preferably with strong prescription for presentation
of data elements).  This is all easier said than done, I know, but then
EAD could be revisited to avoid the laxity.


Terry Catapano wrote:

>I'd like to second much of what Liz and Clay have written, but also to go
>off on a slight tangent about EAD's "non-specificity and lack of rigor
>that confounds effective processing for resource discovery". I once
>mentioned to Liz speaking of TEI, but it applies to EAD as well, that our
>community sorely needs to come to the understanding that a large,
>inclusive, and flexible DTD *enables* interchange, it does not *guarantee*
>it. If interchange, or "effective processing for resource discovery" are
>serious goals, then serious effort must be undertaken to apply EAD
>properly. Mere EAD validity does not buy you much from a machine
>processing standpoint, indeed. Yet, it does narrow the range of
>possibilities and establishes a space for further conversation and action.
>No mean feat.
>That said, I confess my uncertainty as to how inadequate EAD really is as
>a descriptive metadata standard. unitid, unittitle, unitdate, physdesc,
>extent, physfacet, controlaccess, subject, persname, corpname,
>scopecontent, bioghist...their accompanying attributes, the allowance for
>expression of hierarchical relations... Pretty rich set of elements.
>Certainly it lacks the specificity needed in certain domains and
>disciplines, but to the extent what you are describing shares the
>characteristics of a competently arranged and described archives or
>manuscript collection you'll probably be pretty well served. There's
>likely *some* way of getting what you want. Take Clay's example of his
>wrapping MARC in EAD to express subfacted subject headings:
><ead:subject><ead:mdWrap><ead:xmlData><marc:datafield tag="650" ind1=" "
><marc:subfield code="a">Indians</marc:subfield>
><marc:subfield code="x">Antiquities.</marc:subfield>
>It is not evident to me why this is more proper or useful than the
>entirely EAD encoded:
><controlaccess encodinganalog="650">
>        <subject encodinganalog="650a">Indians</subject>
>        <subject encodinganalog="650x">Antiquities.</subject>
>The difference, of course, is mostly semantic. The first views the terms
>as a subject consisting of a MARC datafield with two subfield components.
>The second views them as a controlaccess heading made up of two subject
>terms.  What impedes interoperabilty here is not so much that EAD lacks
>the ability to express a subfacted subject heading, but that, in some
>circumstances another person or machine process might not expect or
>understand a given valid EAD usage and therefore fail to process it as
>intended or wanted.
>Enhancement of EAD's capabilities via external schemata using W3C Schema or
>inclusion of fragments using RelaxNG would be welcome.  However, what also
>might be needed is collaborative development of ancillary techniques of
>specifying EAD usage to enable well defined applications. These can range
>from the highly formal (e.g., Schematron), to moderately formal (something
>like METS Application Profiles), to informal (e.g. RLG's Application
>Enough for now,
>Terry Catapano
>Special Collections Analyst/Librarian
>Columbia University Libraries Digital Program
>[log in to unmask]
>The opinions expressed do not reflect those of my institution, nor perhaps
>of myself at a some future time.