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  December 1995

EAD December 1995

Subject:

ead answers and of course questions

From:

"Janice E. Ruth" <[log in to unmask]>

Reply-To:

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

Date:

Thu, 28 Dec 1995 15:21:52 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (278 lines)

Season's Greetings to All,

     Geez, isn't Michael a trouble-maker?  Just kidding, of
course.  Although I am concerned about changing the model at this
late date, I well know that if *we* don't understand it, we can't
expect others to grasp it (much less accept it).  I share
Michael's fears that we created a model in DC that leans too far
in the opposite direction from the Ann Arbor model.  In Michigan,
we created a model that was based on the arrangement of archival
collections, and in DC we created a model that supposedly was
based on the organization of the finding aid.  Somehow (and
quickly) we need to mesh the two.  I'm not sure what the answer
is, but I offer below in item #3 some thoughts on Michael's
proposed models.  The numbered sections correspond to Debbie's
list of questions.

     What's the latest on the LA meeting?  I will not be in the
office after Friday.  Monday is the holiday, and I will be off on
Tuesday.  I have an early flight Wednesday and will be getting
into LA in the late afternoon.  Are we planning to get together
Wednesday evening?   If not, where and when are we assembling
Thursday?

Janice


1.   EAD Group DTD

     In her 22 December 1995 response, Helena made a good case
     for why a group EAD would be beneficial, i.e., it might
     accommodate both the incremental creation of finding aids
     and the compilation of related finding aids.  I also share,
     however, Helena's concern that a group EAD might pose
     application problems.  For now, I propose that you leave the
     aggregate EAD option in the alpha version until we can all
     look at it more carefully and try to tag some finding aids
     with it.

2.   Title Page Elements

     I find it hard to believe that the Library of Congress is
     the only institution that will want to retain or create a
     title page in an SGML-encoded finding aid.  It has never
     been completely clear to me why folks don't think the title
     page is necessary.  I gather that people believe that the
     header is sufficient, but I don't understand fully how the
     header will be displayed online or printed, and I do agree
     with Helena that for the foreseeable future we will continue
     to print our finding aids and maintain a paper supply of
     them.

     I also am not sure what question I am being asked with
     respect to title pages.  If the question is "Are there
     elements unique to the title page?" my answer is no.  I
     assumed that the title page elements would be ones that are
     already available elsewhere in the DTD, whether in the
     header or the FindAid portions.  The Library of Congress
     generally includes the following in its title pages:  title
     of monographic series; title of individual finding aid;
     author or creator of finding aid; repository name (includes
     name of division); repository address (city/state only); and
     date of creation or publication.  I thought that all of
     these elements (except perhaps monographic series) had
     already been defined in the DTD.  We have either included
     them in the header, or they are basic bibliographic elements
     that would be used in contents lists or in bibliographies
     and other documents located in the Adjunct Descriptive Data
     (ADD) portion of the finding aid DTD.

     Helena's answer poses the general question of whether the
     title page needs subelements at all.  I suppose we could
     simply use paragraph, line, and emphasis tags and not tag
     the type of information since that is already captured in
     the header and would be duplicative to tag again.  I would
     be comfortable with this approach.

3.   Scope and Content View

     Just as I was about to take a stab at this issue, Michael's
     first message appeared in my inbox and confirmed what Helena
     and I had discovered during our attempts to summarize the
     Washington meeting, namely, that many of us left that
     meeting with different and conflicting ideas about what had
     been decided about the EAD model and why.  I started typing
     a response and lo and behold another message from Michael
     appeared, and I had to scrap that response and begin anew--
     both encouraged and energized by Michael's note.

     Michael has addressed and expanded upon the issue that I
     raised in my 14 December message, namely, that within the UV
     and CV, we might still need elements like the old UD and CD
     we had eliminated.  My point was that individual series
     headings and folder headings were not UVs and CVs.  They are
     components that, when strung together and presented in a
     certain way, make up the various "UVs".  If I understand
     Michael correctly, he has reached a similar (although not
     identical) conclusion.  Based on what Michael is proposing,
     I think we are now on the right track of merging the Ann
     Arbor and DC models to arrive at a DTD that captures the
     organization of the finding aid while preserving the
     descriptive arrangement of the collection.

     As I understand the issue before us now, Debbie has proposed
     changing Scope and Content from a type of UV to a separately
     named element on the same level as the UV.  I am not sure
     why Debbie thinks this is necessary, although there seems to
     be some feeling that a UV has to contain subelements (such
     as those that are in DID) rather than simply paragraphs.
     (Parenthetically, I would add that the Scope and Content
     Note, should one wish to tag to that level, does include the
     DID elements; they simply appear in narrative form.)  By
     making the Scope and Content Note a separate element, we
     alter the meaning of the UV.  A UV is no longer the only
     mechanism for providing a content view of the collection.
     Basically we would have a Frederic Miller approach to
     finding aids with separate elements for the admininfo,
     bioghist, scope and content, etc.  The description of series
     and contents lists would be type attributes under a UV.
     Under Debbie's scenario we give up the bundling of the three
     parts of the finding aid that provide content views.  One of
     the content views (Scope and Content) would now be a
     separate element and the other two (Description of Series
     and Contents List) would remain UVs.  What do we gain by
     pulling out the Scope and Content Note?  And if we remove
     the Scope and Content Note, why bother bundling the other
     two--Description of Series and Contents List?

     In grappling with this problem, Michael offers a couple of
     different models for our consideration.  He suggests that
     the UV is mislabeled and that it really is a unit
     description.  I disagree.  I bought into Anne's argument
     that there were administrative, content, and context views
     of a collection represented by different parts of a finding
     aid.  I think of the UV as an elegant mechanism for
     identifying the parts of a finding aid as opposed to the
     parts of a collection.  For that reason, I would have been
     more comfortable with a model that also identified the
     admininfo and bioghist as unit views, albeit different types
     than scope and content, description of series, and contents
     list.  This is what I think Michael is suggesting in his 2a.
     model.  Right?

     I am a little confused by Michael's models, however.  He
     suggests that all future finding aids might resemble the
     first model he typed.  If I read this future model
     correctly, it would eliminate the Description of Series
     section traditionally found in many current finding aids.
     As we have discussed before, this may not be a problem for
     future electronic finding aids, where we can pull out and
     assemble in one place the series descriptions that are
     embedded in container lists, but it would pose a problem for
     encoding existing finding.

     In model 2a, I am a little confused about the placement of
     the view type before the UD.  I would have thought that the
     view type could appear under the UD or CD.

     In model 2b. I am confused why there is no UD element
     specified.

     The bottom line for me is that I agree with Michael that we
     need UD- and CD-like elements.  I don't think, however, that
     we should eliminate the UV, but we should rename it VIEW so
     that it can be used under both the UD and CD.  I think that
     the Views should represent the sections of the finding aid;
     the CDs should represent parts of the collection (similar to
     the col.divs in Daniel's original model); and the UD
     (singular) will represent the whole of the collection.

     Here are yet two more models for everyone to review,
     improve, and flee from in horror.

MODEL A
(Similar to Michael's 2a. except for placement of view element)

<eadheader>
<frontmatter>
<findaid>
   <archdesc>
      <ud>
         <did>
            (may or may not be used; the finding aid may present
            at the beginning the key <did> information, or the
            <did> subelements may not appear until one gets
            inside one of the views or sections of the finding
            aid; at a minimum, however, I think there would be at
            least the title of the collection or record group)
         <view; type=x>
            ("x" can be admininfo, bioghist, scopecontent,
            description of series, contents list, combined series
            description and contents list, and odd; these views
            may or may not be used at the UD level; instead, the
            UD may contain only some <did> elements followed by
            CDs that have been arranged in various views; if the
            views are used at the UD level, then within certain
            views, such as the series description and contents
            lists, you can invoke the CD tags)
         <cd>
            <did>
            <view; type=x>
               (x can be admininfo, bioghist, scopecontent,
               description of series, contents list, combined
               series description and contents list, and odd)
            <cd>
   </archdesc>
   <add>
</findaid>


MODEL B
(This is similar to something that Steve DeRose mentioned at the
DC meeting; retain the idea of the views by making "view" an
attribute on the individually named sections of the finding aid)

<eadheader>
<frontmatter>
<findaid>
   <archdesc>
      <ud>
         <did>
            (may or may not be used; the finding aid may present
            at the beginning the key <did> information, or the
            <did> subelements may not appear until one gets
            inside one of the views or sections of the finding
            aid; at a minimum, however, I think there would be at
            least the title of the collection or record group)
         <admininfo; view type=administrative)
         <bioghist; view type=context)
         <scopecontent; view type=content)
         <description of series; view type=content)
            <cd> (nesting)
         <contents list; view type= view type=content)
            <cd> (nesting)
         <combined ser. desc./contents list; view type=content>
            (cd> (nesting)
         <odd; view type=admin, content, or context)
            <cd> (nesting)
         <cd>
            <did>
            <admininfo; view type=administrative)
            <bioghist; view type=context)
            <scopecontent; view type=content)
            <description of series; view type=content)
               <cd> (nesting)
            <contents list; view type= view type=content)
               <cd> (nesting)
            <combined ser. desc./contents list; view
               type=content>
               <cd> (nesting)
            <odd; view type=admin, content, or context)
               <cd> (nesting)
            <cd>
   </archdesc>
   <add>
</findaid>


4.   Controlled Access Attribute

     You may have noticed that on both of my models I eliminated
     <controlaccess> as a high-level element.  As Kris stated in
     her message of 6 December 1995, I think this should be an
     element that can occur within the any of the views.  I don't
     see <controlaccess> as a section of the finding aid (a view)
     nor do I see it as a part of the collection (a CD).

     I have nothing to add to the lists of sources that Helena
     and Michael provided.


5.   Status Attribute

     I agree with Michael that Helena has provided some good
     ideas, but I think that we need to choose among her
     suggestions, since they seem duplicative to me.  My personal
     preferences are:  Unverified Partial Draft; Unverified Full
     Draft; Edited Partial Draft; and Edited Full Draft

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996
September 1996
August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
December 1995

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager