On Sun, 28 Sep 1997, Alvin Pollock wrote:
> Matthew Nickerson's recent posting to
> the ead list on this topic really hit a nerve with me.
Like Alvin, Matthew Nickerson's post also hit a nerve with me, though as
an archivist (not a programmer) who has been grappling for the past year +
with EAD my response comes from a little different angle.
I started responding to Matthew's post, but it is getting *really* long
and isn't directly focused on his queries anymore. I'll probably continue
with it and post it later with the warning that it's long so you can
delete if not interested. I do, however, want to respond to some of
Alvin's points about stylesheets are well-taken; however, I would argue
that the way to deal with this is not to make EAD more style-intensive,
which I would view as a big mistake. The way to address this is to get
all style-realted tagging OUT of EAD completely and into stylesheets where
it belongs. I've felt from the start that all the tabular tagging that
accompanies <drow><dentry> is procedural in nature, has nothing to do with
the information contained in finding aids, and doesn't even belong in EAD.
I'd be happy to be disabused of that notion if I'm wrong and if
<drow><dentry>, etc. are in some way critical for the encoding of
descriptive information in archival finding aids.
> 2. A much more useful change would be the addition of a "style"
> attribute to the <dsc> element. My first thoughts are that
> style would not be a closed list but would be numeric. One
> of the responsibilities of an EAD working group would be to
> publish formal specifications for which types of container
> lists would conform to which style. Example:
> style=0: Tabular markup, using <drow>s, <dentry>s, etc.
> style=1: Non-tabular markup. One <unitloc> (or <unitid>)
> followed by one <unittitle> and other information
> such as <scopecontent>, <odd>, etc.
> style=2: Two <unitloc>s followed by a <unittitle> and other
> style=3: Three <unitloc>s followed by a <unittitle> and other
> Since the format of a container list can change from series
> to series, the <c> tag should also have a style attribute which
> could override the one in the <dsc>. altrender could be used for
> this purpose (and currently is in some institutions!) but I think
> it more useful to formalize something specifically for this use.
> The style attribute of course would not be required.
> An alternative to a numeric style attribute might be an attribute
> of type ENTITY. In a more sophisticated technological environment
> the SGML application could fetch a style description file from a
> server out on the net.
> In either case the important point is that a master list of container
> list types is maintained by an SAA working group which publishes
> the detailed markup specifications.
> This attribute would be a very slight intrusion of formatting
> information into the intellectual purity of a finding aid (We
> already have this intrusion in a big way with tabular markup of
> course. The style attribute might eliminate the need for tabular
> markup almost entirely). But the tremendous usefulness it would
> add to the way in which we display and otherwise work with our
> finding aids makes it well worth the addition of one, tiny attribute.
> We could then create pools of stylesheets. A finding aid author knows
> which style of container list she has and could download the
> appropriate stylesheet from a central web site. The attribute
> would greatly facilitate the interchange of finding aids between
> institutions and make the establishment of a union database of
> finding aids far easier.
...I have to vehemently disagree with all of the above except Alvin's
comment that this would be an "intrusion of formatting information into
the intellectual purity of a finding aid (We already have this intrusion
in a big way with tabular markup of course)." Note that I left the word
"slight" out of the quote. This intrustion would not be slight!
Yes, we need to develop delivery systems for EAD. And yes, we need a
variety of programmers at some large institutions to look at the various
possible delivery system options/solutions for EAD. But no, we don't need
to continually tweak EAD to accommodate delivery systems. I think this
would be a bad route for EAD to take. Not only would it make it necessary
to revisit EAD data every time delivery systems changed or matured, but it
makes the encoding of finding aids unnecessarily complex, which I think
will be an inhibiting factor in its application by the archival community.
> On another note, I have heard it often said that every <c> should
> have exactly one <unittitle>. This makes a great deal of sense to
> me but I have never seen it formally stated, either in the DTD, the
> tag library, or the application guidelines. I'm not sure it's ever
> been said on the ead list. If this is the case, can we formalize
> this "law" somehow? It's possible to hardwire this into the DTD
> I'm sure, but probably makes more sense to state it in the tag
> library, application guidelines, and perhaps comments within the
> DTD itself.
Since the <unittitle> is a part of the <did>, and the <did> as a whole is
what provides primary descriptive elements for any component tag, this
seems to be a part of the larger discussion of the <did> and what it
should contain. I do agree with Alvin that some descriptive elements
should be required for all components.
________ [Bill Landis] ___________________________ [[log in to unmask]]
Graduate School of Education & Information Studies
University of California, Los Angeles