LISTSERV mailing list manager LISTSERV 16.0

Help for EAD Archives


EAD Archives

EAD Archives


EAD@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

EAD Home

EAD Home

EAD  April 1996

EAD April 1996

Subject:

Re: EAD

From:

Stephen Davis <[log in to unmask]>

Reply-To:

Encoded Archival Description List <[log in to unmask]>

Date:

Mon, 22 Apr 1996 11:53:23 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (110 lines)

At 09:57 AM 4/22/96 -0400, Helena Zinkham wrote:
>        For Richard Rinehart's questions about tagging object type and
>media, I have been counting on even the current EAD accomodating
>item-level genre and physical description.  Since it looks like the <DID>
>elements can't contain any of the Phrase-level ACCESS elements, maybe
>something to fix not just for GENREFORM? Janice and Mary realized that
><UNITTITLE> can't contain things like <PERSNAME>.
>

I'm afraid I'm increasingly concerned, not only in the EAD, but in the TEI
and some other newly proposed DTDs, how far away from a "data dictionary"
approach we're headed, and instead apparently about to implement for all new
digital library applications an entirely postionally-based syntactic
approach to data structuring.

Realistically, how often do we want to wrestle with why a particular element
isn't defined within another element?  This seems to let the container drive
the content, where it should really be the opposite.  WHEREVER I need a
<persname> I should be able to use it.  At this rate it looks as though it
would be best to define every element as possibly appearing within any other
element, in any order!  And, actually, why not?

(A version of this issue came up several times at the recent TEI workshop in
DC.  When people finally get down and dirty with encoding a corpus, they
appear to need the flexibility of using an element _wherever_ it's needed,
rather than just where someone thought to define it. They also don't appear
to want to manage dozens of genre-based DTDs for poetry, prose, drama, verse
drama, etc. )

Perhaps we will need to rethink a good part of the structure of SGML
documents, e.g., to use broad hierarchies reflecting significant structural
components of the text, and then simply defining an extended data dictionary
that can be applied wherever needed under any of the hierarchical levels.
(Frankly, given that there are no "rules" for the content of a finding aid,
how can all elements NOT be valid under all other elements, in any order
desired??)  See below for a gross representation of what I'm getting at.

This kind of generalized strategy might have the added benefit of allowing
the creation of a few, more generic blanket DTDs, reducing the
DTD-proliferation we're starting to see.  A name is a name is a name, right?
Unfortunately, it quite shortly won't be, and we systems people will find
ourselves trying to write retrieval and indexing tools that have to
accommodate a hundred different ideas of just what and where a personal name is.

(Sorry to be the wet blanket here ...)            /Stephen

 ===========================================================================
===============
STRUCTURAL ELEMENTS

<tei rec_type=ead>
     <div1 name=eadheader>
     <div1 name=frontmatter>
     <div1 name=findaid>
          <div2 name=archdesc> archival description
               <div3 name=did>
               <div3 name=admininfo>
               <div3 name=bioghist>
               <div3 name=controlaccess>
               <div3 name=odd> other descriptive data
               <div3 name=note> general note
               <div3 name=scopecontent>
               <div3 name=dsc>
                    <div4 name=add>
                    <div4 name=bibliography>
                    <div4 name=fileplan>
                    <div4 name=index>
                    <div4 name=relatedmaterial>
                    <div4 name=separatedmaterial>
</tei>

DATA ELEMENT LIST (use where applicable under any of the above structural
elements)
        (NB: These elements need to be further generalized and added to.)

                    <unittitle> unit title
                    <unitdate> unit date
                    <extent> extent
                    <origination> origination, e.g., collector,
photographer, etc.
                    <repository>
                    <unitloc> unit location
                    <unitid> unit identification
                    <note> general note

                    <accessrestrict> access restrictions
                    <acqinfo> acquisitions information
                    <altformavail> alternative form available
                    <custodhist> custodial history
                    <prefercite> preferred citation
                    <processinfo> processing information
                    <userestrict> use restrictions
                    <note>

                    <chronlist> chronological list

                    <corpname>
                    <famname>
                    <genreform>
                    <geogname>
                    <name>
                    <occupation>
                    <persname>
----------------------------------------------------------------------
Stephen Davis                   email: [log in to unmask]
Director of Library Systems     phone: (212) 854-8584
219M Butler Li