Date: Fri, 30 Jan 1998 14:03:23 -0600 From: Kris Kiesling <kiesling@MAIL.UTEXAS.EDU> Subject: EAD Beta-->Version 1.0 Changes
[Note: In a followup message to Kiesling's post below, Daniel Pitti (Project Director, Institute for Advanced Technology in the Humanities, University of Virginia) clarified to the Encoded Archival Description List that the EAD DTD is to become XML compliant:
While the careful reader may conclude from the message below that the EADWG decided to make the EAD DTD compliant with XML (Extensible Markup Language), I note that we failed to mention this explicitly. And so please allow me to add to the following that Version 1 of the EAD DTD will be fully compliant with XML. For further information on XML, please see: http://www.w3.org/XML/ and http://www.microsoft.com/xml/.This message from Daniel Pitti confirms what had been publicized earlier (in a posting of January 12, 1998 to the Encoded Archival Description List), that "EAD Version 1, to be released in 1998, will be XML compatible." See also the specific issues in the list of changes below:
Daniel Pitti
Date: Fri, 30 Jan 1998 17:09:23 -0500
From October 31-November 2, 1997, fifteen members of the Encoded Archival Description Working Group of the SAA Committee on Archival Information Exchange met in Washington D.C. to discuss the suggested changes to the beta EAD DTD that were submitted to this listserv last summer. The Working Group is pleased to announce the changes that were approved at the meeting.
BACKGROUND
The EAD Working Group consists of sixteen individuals representing the United Kingdom, Canada, the Library of Congress, the National Archives, the Research Libraries Group and OCLC, and a number of American academic institutions and one historical society who have been involved for almost three years in the development of EAD. The WG is currently engaged in preparing three documents for final release early this year: version 1.0 of the EAD DTD, the Tag Library, and a set of Application Guidelines.
The group reviewed the Tag Library and Application Guidelines drafts in response to forty-seven email messages sent from beta testers around the world including the National Archives of Sweden, the British Public Records Office, the Bodleian Library, and the Canadian National Archives. The majority of the messages proposed potential changes to the DTD based upon experience with the beta version or relationships between EAD and other archival data structure or content standards such as MARC, the International Standard for Archival Description General (ISAD-G), and the Canadian Rules for Archival Description (RAD). The merits of each proposed change were considered individually and group consensus was reached by considering among other factors the global applicability of a proposed change, the amount of retrospective conversion for beta implementors a desired change would require, and whether other changes or existing structures would achieve the same result more effectively.
The Working Group would like to thank everyone who submitted suggestions. The revised DTD is currently being tested and a new version of the Tag Library is being created. These will be released as soon as possible, with the Application Guidelines to follow.
We welcome your comments and questions on these changes; please send them to the listserv, not to individual WG members. I will shortly send another message outlining changes that were submitted to the WG but were not implemented.
Kris Kiesling
Chair, EAD Working Group
EAD BETA to Version 1.0 Changes (Final 3: 1998 01 15)
Note 1: unless otherwise specified, ATTRIBUTES are of the following nature:
ATTRIBUTE NAME CDATA #IMPLIED
Note 2: unless otherwise specified, all elements have the global attributes:
ID, AUDIENCE, AND ALTRENDER
Note 3: m.block content model fragment includes the following elements:
address | blockquote | chronlist | list | note | table | p
-----------------------------
1. <abstract>: add element <abstract> to <did> and <dentry>
content model "basic phrase:"
ptr | extptr |
emph | lb |
bibref | ref | title | extref | archref |
abbr | expan
attributes
LABEL
ENCODINGANALOG
TYPE CDATA #IMPLIED
WG discussion:
It was felt that a very brief statement, which may contain
biographical/historical information and/or scope and contents information
may be desirable at the very beginning of the finding aid (in the initial
<did>), to provide users with enough information to determine if the
collection described will be of use. Further, placing the <abstract>
element in <did> and also making it available in <dentry> provides the
functionality that was requested for making <scopecontent> available in
<did> at the component level (e.g., if it desirable to tie together a
folder description with its title and date).
-----------------------------
2. <unitid>: add attributes for COUNTRYCODE and REPOSITORYCODE
Comment: to be used strictly for logical identification, not physical
location.
WG discussion:
This change makes the <unitid> compatible with ISAD(G) 3.1.1 by providing
content designation for a collection's country and repository codes.
-----------------------------
3. <eadid> change AUTHORITY attribute to SOURCE.
Comment: Also change content model from CDATA to #PCDATA (to comply with XML)
WG discussion:
Since the AUTHORITY attribute was intended to indicate source information,
it was decided to rename the attribute to bring it in line with SOURCE
attributes in other elements. However, this SOURCE attribute will not use
the semi-closed list of sources as the other elements for which this
attribute is available (see 12. below).
-----------------------------
4. <unitloc>: remove <unitloc> from the DTD.
WG discussion:
The <unitloc> element was eliminated and replaced by two new elements:
<container> and <physloc> (see 5. and 6. below).
-----------------------------
5. <container>: create element <container> to be available in <did>,
<dentry>, and <archref>.
Attributes:
LABEL
TYPE Add values "page", "folio", "reel-frame" and "volume" to the
following list of available values and change "oversize-cabinet" to
"oversize":
carton | box | folder | reel | frame | oversize-cabinet |
map-case | box-folder | othertype
PARENT declared value IDREFS, default value #IMPLIED
OTHERTYPE, ENCODINGANALOG
WG discussion:
The WG agreed that <unitloc> was carrying too much of a burden and that the
application of the LOCTYPE and CONTAINERTYPE attributes was too confusing.
The <container> element now carries the old CONTAINERTYPE attribute (now
simply TYPE) to specify the kind of housing, if desired.
-----------------------------
6. <physloc>: create element <physloc> to be available in <did>, <dentry>,
and <archref>.
Attributes:
LABEL, TYPE, ENCODINGANALOG
PARENT declared value IDREFS, default value #IMPLIED
WG discussion:
The <physloc> element is to be used to specify the location within the
repository, such as a shelving location, to note offsite storage, etc. It
essentially replaces the concept of LOCTYPE="repository" in the old
<unitloc> attribute.
-----------------------------
7. <scopecontent>: change content model of <scopecontent> to include
m.blocks instead of only <p> and <note>.
WG discussion:
This change adds <list> to the content model of <scopecontent>, as requested.
-----------------------------
8. <emph>: add existing element <emph> to <emph> content model.
WG discussion:
Making <emph> recursive simplifies the markup when multiple but different
types of emphasis are needed in a single string of text.
-----------------------------
9. Add XLL architectural form attributes to reference and pointing elements.
-----------------------------
10. <accruals>: add new element <accruals> to content model of <admininfo>.
Content and attribute model is to be the same as its siblings (e.g.,
<acqinfo>, <processinfo>, etc).
WG discussion:
This addition facilitates ISAD(G) and RAD compliance. Those guidelines
distinguish between information relating to future accruals and immediate
source of acquisition information.
-----------------------------
11. <altformavail>: add attribute TYPE.
WG discussion:
The addition of the TYPE attribute makes it possible to specify the
alternate format(s) of the materials that are available. No closed or
semi-closed list was specified.
-----------------------------
12. SOURCE: add values "CDWA", "NCARules", and "RAD" to list available
under SOURCE attribute wherever it occurs.
Comment: NCARules=National Council of Archives, Rules for the Construction
of Personal, Corporate and Place Names; RAD=Rules for Archival Description;
CDWA=Categories for the Description of Works of Art.
-----------------------------
13. <findaid>: eliminate <findaid> from content model of <ead> and add
attributes TYPE, OTHERTYPE, and RELATEDENCODING to attributes of <archdesc>.
WG discussion:
With the addition of the <add> element to <archdesc> and all the components
(see 14. below), the existence of <findaid> as a wrapper element was
unnecessary. The <findaid> attributes were transferred to <archdesc>.
-----------------------------
14. <add>: add <add> to <archesc> and all <c>s.
Change models of each to <did> followed by 0 or more <admininfo>,
<bioghist>, <controlaccess>, <odd>, <scopecontent>, <organization>,
<arrangement>, <dao>, <daogrp>, <note>, <dsc>, or <add>. For <c> and <c#>,
this group may be followed by <c> or the next <c#> in the hierarchy, as
appropriate.
Remove <div> from <add> content model. Change content model of <add> to
include m.blocks and add attribute TYPE.
WG discussion:
The name of the <add> element was also changed, from "Adjunct to the
Descriptive Data" to "Adjunct Descriptive Data," reflecting the need to be
able to describe related or separated material within the context of the
material being described in the finding aid, to insert an index or a file
plan for a single series, etc. The <add> element was also made recursive
and m.blocks elements were added (see Note 3 above), allowing the
elimination of the generic <div> element from <add>.
-----------------------------
15. <otherfindaid>: create element <otherfindaid> in <add> with same
content model and attributes as <separatedmaterial>, <bibliography>, and
<relatedmaterial>.
WG discussion:
Archivists frequently reference other types of finding aids for a
collection, such as card files, lists generated by the creator of the
materials, dealer's lists, etc. It may be desirable to code that
information.
-----------------------------
16. <dimensions>: add <dimensions> element to content model of <dimensions>
and add attributes: TYPE and UNIT.
WG discussion:
Rather than creating the requested <measurements> element to facilitate the
documentation of multiple measurements of a single object or item, making
<dimensions> recursive allows the same functionality. The TYPE and UNIT
attributes can contain CDATA, so the institution can specify whatever is
appropriate (e.g., the TYPE might be "height" or "width" and the UNIT the
kind of measurement, such as cm or l.ft.).
-----------------------------
17. <extent>: add attributes: TYPE and UNIT.
WG discussion:
The WG thought the same attributes added for <dimensions> (see 16. above)
would also be useful for <extent>.
-----------------------------
18. <physfacet>: add attributes: TYPE and UNIT. Add the access elements
(those contained in <controlaccess>) and <date> to <physfacet>.
-----------------------------
19. <physdesc>: add the access elements (those contained in
<controlaccess>) and <date> element to <physdesc>.
WG discussion:
The addition of these elements to both <physdesc> and <physfacet> was seen
as a way to satisfy the request to make <p> (which also contains these
elements) available in <physdesc>, and allows greater specificity of markup
of information that may be contained in these elements.
-----------------------------
20. <indexentry>: add element <indexentry> to content model of <indexentry>
and make pointer elements optional.
WG discussion:
Making <indexentry> recursive should facilitate the nesting of index
entries, rather than adding the requested <level> elements to the content
model of <indexentry>. Making the pointer elements optional enables the
creation of an index without links back to the text of the finding aid.
-----------------------------
21. <bibref>: add elements <famname>, <persname>, and <corpname> to content
model of <bibref>.
WG discussion:
This change enables more specific markup of author names within <bibref>.
Only <name> was available in the beta version.
-----------------------------
22. <name>: remove TYPE attribute.
WG discussion:
It seems somewhat illogical to specify a TYPE for a generic name element
when more specific elements are available.
-----------------------------
23. Attributes: change all defaulted attributes to #IMPLIED.
-----------------------------
24. Remove HyTime elements <nameloc>, <nmlist>, and <ilink> and remove
HYTIME attributes from reference and pointer elements. See 9. above.
-----------------------------
25. <admininfo>: change content model of <admininfo> to include m.blocks
instead of only <p> and <note> and add attribute TYPE.
WG discussion:
This change brings the content model of <admininfo> in line with the other
<did>-level elements.
-----------------------------
26. <bioghist>: change content model of <bioghist> to include m.blocks
instead of only <p> and <note>.
WG discussion:
See 25. above.
-----------------------------
27. <did>: make <did> required in <c>s and <c#>s.
WG discussion:
Since <did> contains the identifying elements for description of a
component, such as <unittitle>, it should be required. The <did> is not
required when using the <dentry> approach.
-----------------------------
28. Add notation for HTML.
-----------------------------
29. Add notation for EMAIL.
-----------------------------
30. Add notation for XML.
Kris Kiesling
Chair, SAA Committee on Archival Information Exchange
Chair, CAIE EAD Working Group
Head, Department of Manuscripts and Archives
Harry Ransom Humanities Research Center
University of Texas at Austin
Austin, TX 78713-7219
voice: 512-471-9113
fax: 512.471.9646
kiesling@mail.utexas.edu
Date: Fri, 30 Jan 1998 15:43:03 -0600 From: Kris Kiesling <kiesling@MAIL.UTEXAS.EDU> Subject: Changes not made for EAD V1.0 Sender: Encoded Archival Description List <EAD@loc.gov>
In case you were wondering what happened to the other suggested changes to EAD beta, the following is a list of suggestions that were *not* implemented by the Working Group. Each suggestion was discussed by the WG at the Oct. 31-Nov.2, 1997 meeting, and the rationale for not implementing the change is provided below.
Generally, the WG declined to add elements where an existing attribute or making an element recursive would serve the same purpose. In addition, the WG was very concerned about excessive content designation. Some of the suggestions seemed to be directed at tagging every scrap of information contained in a finding aid, regardless of whether it would be useful for display or retrieval purposes. The forthcoming EAD Application Guidelines will discuss at some length recommended content designation.
The WG welcomes questions and comments; please direct them to the listserv, not to individual WG members.
1. Make <head> available in <archdesc>.
The <archdesc> element is simply a wrapper that holds the rest of the
descriptive information together. It is possible to use a stylesheet to
insert a heading if one is desirable, but it is more likely that the
individual parts of the finding aid will need headings, rather than the
finding aid itself.
2. Create elements within <archdesc> to indicate level of description,
legal status, and language of the material to make EAD ISAD(G) compliant.
This is already possible using the <archdesc> LEVEL attribute (which is
required), the LEGALSTATUS attribute, and the LANGMATERIAL attribute to
specify this information. There is no prescribed order in ISAD(G) for this
information, so it was not thought necessary to add elements and constrain
them to a specific order.
3. Unbundle <did> at <c> level.
The design team's original intention in creating the <did> element was to
identify and group those pieces of information thought to be the most
important for ensuring a good basic description of an archival unit or
component. The team felt that by having the elements appear together as a
group on software menus, templates, and tag libraries, encoders might be
reminded to capture descriptive information that would otherwise be
overlooked. The <did> element has generated confusion, however, and some
early implementors have suggested eliminating it as a means of reducing
"tag overhead." Also, because the <did> is not required when using the
<drow> <dentry> approach at the component level, some archivists have
mistakenly concluded that display or formatting elements have overtaken or
replaced intellectual markup. In a setting of multi-level archival
description such as one has in EAD, it is important that the data elements
and structures be consistent at every level.
The WG discussion reaffirmed the purpose of the <did>:
a) a wrapper for essential information that permits resource
discovery and recognition;
b) a mechanism that supports multi-level description; and
c) a structure that holds information together for output.
4. Make <unitid> required.
This cannot be done because the elements within the <did> cannot be
required at the top level of description (in the mandatory initial <did>)
without also being required within the components. A component may or may
not have an ID.
5. Create an <orgarrang> element in <admininfo>.
It was thought best not to "elementize" undifferentiated information in
existing finding aids. If organization and arrangement information cannot
be teased apart, the information should simply be coded as a paragraph
under <scopecontent >, or as <odd>, which is a placeholder for legacy data.
6. Make the <...name> elements, <date>, and <occupation> available in
<acqinfo>.
These elements are all available in <p>, which is required within <acqinfo>.
7. Make <origination> available in <controlaccess>.
The creator role can already be handled with the ROLE or ENCODINGANALOG
attributes on the <persname>, <famname>, and <corpname> elements, which are
all available within <origination>. Alternately, the name given in
<origination> can be repeated in <controlaccess> if retrieval flexibility
is required.
8. Make the <...name> elements available in <head>.
Heads are display and navigational tools, rather than retrieval tools.
Adding these elements would make the content model of <head> messy, and
would encourage misuse of the element. It is possible to supply a name as
the text of the <head> element for display purposes, and then for retrieval
purposes to repeat the name in a <...name> element within the required <p>
and suppress its display by setting the AUDIENCE attribute to "internal."
Admittedly not an elegant solution, but it gets the job done.
9. Make <indexentry> available in <controlaccess>.
This suggestion seemed to be requesting that it be made possible to
automatically generate an index from the markup. EAD does not currently
support this capability, as the <index> element is intended to encode
existing indexes that are already part of a finding aid.
10. Allow elements within <controlaccess> to nest.
Use the ROLE or ENCODINGANALOG attributes for the elements within
<controlaccess> to clarify the purpose of the heading, e.g., to specify
that a personal name is also a subject.
11. Add <levelinfo> element to <dsc> and <c>.
This suggestion seemed to be aimed at machine processing, display, or some
other kind of manipulation of the data in the finding aid. EAD focuses
more on content designation than procedural markup. The level of
description can be identified with the LEVEL attribute on both the <dsc>
and <c>, and neither of the examples presented with the suggestions
illustrated a compelling argument for the addition of this element.
12. Add a STYLE attribute to <dsc> and <c>.
This suggestion also seemed to focus on procedural markup. XSL may handle
this need.
13. Make <unittitle> required within <c0x>.
While it is certainly desirable to have a <unittitle> for every component,
some institutions are using <unitdate> for folder headings that contain
only date information. This practice may have implications for retrieval,
and the EAD Application Guidelines will recommend the use of <unittitle> at
the component level.
14. Add <associatedmaterial> to <add>.
The <relatedmaterial> element is to be redefined as materials not related
by provenance that are located in more than one place (maybe administrative
units within the same repository, maybe separate repositories). The
<separatedmaterial> element will be redefined as materials that are related
by provenance but that have been withdrawn, deaccessioned, sent to another
administrative unit, or are part of another collection or fonds. By
ISAD(G) definition, associated material would be covered under the new
definition of <separatedmaterial>.
15. Make <note> available in <indexentry>.
The <indexentry> element was made recursive, which should increase its
flexibility. It is also possible to use <namegrp> within <indexentry>,
which contains <note>.
16. Make <date> available outside <imprint> in <bibref>.
The suggestion indicated that sometimes only the <date> element was needed,
without the <imprint> tag. However, there is a need to distinguish
different kinds of dates, such as publication dates. Opening an <imprint>
element to use the <date> element was not seen as serious tagging overhead.
Kris Kiesling
Chair, SAA Committee on Archival Information Exchange
Chair, CAIE EAD Working Group
Head, Department of Manuscripts and Archives
Harry Ransom Humanities Research Center
University of Texas at Austin
Austin, TX 78713-7219
voice: 512-471-9113
fax: 512.471.9646
kiesling@mail.utexas.edu