Print

Print


Andrew,

Regarding the paragraph below, this is possible with XML Schema using
namespacing.  However, this is not possible using DTD.  At this point
you could get a well-formed XML document using namespacing (e.g.,
<ead:bioghist><marc:datafield tag="245">), but it would not validate.
Those schemas have to allow for mixed content, which most currently do
not.

So, for instance, if I wanted to put Dublin Core or MARC XML into the
<bioghist>, the EAD Schema would specifically have to allow it.  Or, the
EAD Schema would have to take the approach that METS does by using XLink
(which EAD does support in name only in the DTD) or the
<mdWrap>/<xmlData> metadata wrapper elements for nesting in embedded XML
data.

I converted the v1.0 DTD to Schema and embedded a <mdWrap><xmlData>
entity into it to experiment with such wrapping capabilities.  After
playing around with MARC, MODS, DC, etc., in EAD, it made up for certain
lack of features that attributes such as encodinganalogs now face in the
DTD.  It became much easier to deal with the common <subject
encodinganalog="650$a$x"> kinds of problems by nesting in MARC or MODS
tags inside the EAD as such:

<ead:subject><ead:mdWrap><ead:xmlData><marc:datafield tag="650" ind1=" "
ind2="0">
<marc:subfield code="a">Indians</marc:subfield>
<marc:subfield code="x">Antiquities.</marc:subfield>
</marc:datafield></ead:xmlData></ead:mdWrap></ead:subject>

So, theortetically, you could use any music-centric XML inside EAD.
However, as if standardization of markup was hard enough to achieve
across repositories, if arbitrary extension schemas were added into EAD,
one could make a strong argument that interoperability problems would
compound.

In general I disagree with making EAD more generalized (or specific) for
non-archival purposes.  Another similar markup standard exists out there
for marking up "collection"s of materials regardless of format: the
Research Support Libraries Programme Collection Description (also in
stages of becoming a Dublin Core standard).  You could use something
like DC Qualified to add subordinate items to the collection-level
description.  Plus that, if you think about it, METS delivers much the
same thing that EAD could with its ability to link/declare hierarchical
relationships.   EAD doesn't have a monopoly on hierarchical structuring
of description.  That's why the music community needs to create
something it's own rather that to settle for a 75% solution by using an
existing standard.  Reference Liz Shaw's "high heel and mountain
climbing" analogy.

The music library and music information retrieval communities are in
prime position to make the most of their own standards to serve as a
model for other disciplines.  Think of your ISMIR bretheren -- they can
add wonderful touches to music-based digital libraries, but not through
latching onto EAD.   I think they could mirror the archival description
movement with their own content standards, structure standards, and
presentation standards.  Here at Princeton we're looking at ways of
adding things like BWV (or insert other composer catalogs here) numbers,
name authority discrepancies, transliteration, etc., into Virtual
International Authority Files and XML Web Services to create a possible
union catalog/bibliographic utility type of tool for the larger music
bibliography community.  Not to mention FRBRization to solve the
problems that MARC currently has with displaying music resources in
online catalogs to end users.  We look forward to seeing if anyone else
out there is interested.

Clay

Andrew Hankinson wrote:

> Its strengths are
> that it is a defined structure which maintains hierarchical
> relationships, and allows physically separate items to "appear" as a
> single collection. (in theory, at least.)  If only there were some way
> of actually describing the stuff within the collection....On a more
> technical note, I'm not sure if you can mix standards within
> one another.  For instance, in a <c> tag within EAD, could you, for
> instance, place a <performance> tag taken from the TEI?  A thought that
> just occurred to me: Nested Schemas?  Could I, for instance, define a
> section as TEI, and then define the next section with, say, MusicXML?
> Or define a TEI section WITHIN a MusicXML section WITHIN an EAD
> document.  All with validation and/or corresponding DTD's.
>  Like I said, I'm new at this, so if my understanding of these things
> are a little off, please correct me.
>