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  September 2001

EAD September 2001

Subject:

Re: XSL and EAD

From:

Daniel Pitti <[log in to unmask]>

Reply-To:

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

Date:

Tue, 18 Sep 2001 13:04:19 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (186 lines)

Hugo,

Responses below.

At 11:06 AM 9/18/01 -0400, you wrote:
>Daniel,
>Perhaps 'content' and 'presentation' standards are not the right terms to
>use.  There seems to be some confusion in everybody's mind what exactly each
>should contain or should standardize.  I think both ISAD(G) and EAD have
>elements of both content and presentation.  For example, ISAD(G) prescribes
>a structure (multilevel) and so does the EAD DTD.


I think we need to be careful about conflating intellectual structure
(multilevel description and inheritance) and the visual communication of
that structure to users. They are not the same thing. It is perfectly
possible to describe intellectual content components and structures and to
devise computer representations for them without explicit reference to
layout and presentation. On the other hand, given that archival description
is intended to be useful and must be communicated to be so, it is
impossible and, in fact, it would be irresponsible to devise standards with
anticipating communication to users.


>However, I cannot agree that > EAD is independent from any presentation
>whether electronic, conventional
>paper, Web or whatever.<   You actually say that yourself in the next
>sentence: > All of these presentations are possible DERIVATIVES of EAD, and
>in a wide variety of styles. > (Emphasis added).

While there is certainly a relation between the computer representation of
the intellectual content of archival description and its communication to
users, visual and otherwise, this fact does not make the former dependent
on the latter. Rather it makes the latter dependent on the former. The EAD
instance supports the creation of derivatives.

>But this quibbling aside,
>it is the naming of the EAD elements and their associated explanation in the
>tag library where, I think, Liz Shaw sees a problem.  The explanation of
>elements in the tag library are not explicitly linked to rules of archival
>description (where applicable).

EAD accommodates archival description, good or bad. It is simply a carrier.
I do not think EAD should be tied to one particular content standard. Given
national and cultural differences in archival description, EAD would become
exclusive and thereby fail politically. Standards that fail politically are
not standards. In connecting content standards to EAD, it would be better
to come from the direction of the content standards, which is to say,
content standards based on ISAD(G) should reference EAD. Of course, the
various content standards should inform the ongoing revision of EAD, as it
needs to serve them. I think you touch on this latter point when you say
below that "rules are implied."

>Archival description or cataloguing rules
>are probably the true content standards.  The rules are implied and if you
>look at the explanation in the tag library, and you are familiar with APPM,
>it follows it. Furthermore, it seems to follow the first edition of APPM.  I
>think this is a problem with non-American archival users because they would
>not describe (or make finding aids) using APPM. The terminology used in EAD
>(and APPM) are not familiar to them.  The problems in EAD run parallel with
>the problems which non-American users have with the problems of APPM.  For
>example, I seem to recall that one of them was that APPM (in its first
>edition) stated somewhere that the rules apply to finding aids. ( I do not
>have the first edition of APPM here with me at home.) This results in the
>element Title proper (rules) to translate in EAD to <titleproper> which is
>in the tag library explanation defined as the Title Proper of the Finding
>Aid . In the second edition of APPM a distinction is made between a Formal
>title (1.1B1), and Supplied titles (1.1B2). Only under the Supplied title
>rule is there mention to use a finding aid title if it exists. There are
>many such problems.  The reference in my previous e-mail to the problem of
>EAD addressing the description of finding aids rather than archival
>collections or fonds was about the above.

There is no question that EAD arose in an American context and that much in
it reflects this. As international interest in it has grown, though, the
American presence on the EADWG has decreased, and the international
presence increased. This is an ongoing change. It is anticipated that this
i will lead to a gradual internationalization of the EAD terminology and
text. In fact, in the current round,  many of the revisions are to
terminology and definitions of various elements, and not changes to the
elements themselves. Many of the suggestions were inspired by ISAD(G). I
suspect this will continue.

With respect to APPM, while it certainly had some influence on the design
of EAD, it was not as major an influence as you suggest. Steve Hensen
stated more than once during the initial EAD design work that APPM was
never intended to constitute rules for archival description as such, but
rules for top-level, summary description. Finding aids serve as the chief
source of information for summary descriptions, but are not explicitly
addressed in APPM. In other words, APPM was not intended to provide
guidance in complete top-down archival description.

With regard to the title discussion above, I think you need to be careful
about distinguishing the title of the finding aid (or archival description)
from the title of the archival materials. EAD explicitly distinguishes
between the two, with the title of the finding aid being lodged in the
<eadheader>, and the title or titles of the archival materials in the
<archdesc>. The distinction is between describing the archival description
and describing the archival materials. As for where you get the title or
titles, EAD is silent. That is a content standard issue. EAD does not try
to be a content standard, and if you attempt to judge it as one, it
appropriately fails.





> > Instead of two standards, I would list three: content (or intellectual);
> > representation (sometimes called structural or communication); and
> > presentation. I am not aware of any formal efforts to standardize the
> > latter, though I would  very much welcome such an effort.
>
>I agree with you here.  ICA/CDS has produced a draft Guidelines for Finding
>Aids (note: guidelines; not a standard).  It was supposed to have been
>posted on the ICA Web site.  But the ICA Web site is, for all intents and
>purposes, extinct for the moment.  I understand that it will be revived
>elsewhere soon (October?) hosted by another host than the National Archives
>of Canada.  I would have liked to refer to these guidelines because they
>contain some very useful presentation recommendations.  We have to wait till
>it gets posted.
>
>Regarding your comments, Michael:
>I would argue that ISAD(G) is not a content standard or if it is, is
>one with very weak semantics.  RAD, now that's a content standard.  APPM
>too.  You could actually describe something using their rules.  Not really
>so with ISAD(G).  In North America, the CUSTARD project is attempting to
>blend the best of RAD and APPM to create a content standard that is
>independent of output.
>
>I agree that ISAD(G) is not suitable as a total standard with which to start
>describing archival collections (fonds).  However, it being an international
>standard, it was never meant to be a complete description standard.  It
>could not be that and it was never presented like that.  It is and was
>always presented as the basis for developing national descriptive standards.
>For example, RAD, being the Canadian national standard, is now pretty well
>completely conforming to ISAD(G) as AACR conforms to the ISBD(G) in the
>library world.  ISAD(G) has the same function in the archival world, or is
>meant to have that.
>
>I also agree very much with the efforts of the CUSTARD project to harmonize,
>or dare we hope for a single North American standard, for archival
>description.
>
>
>
>----- Original Message -----
>From: "Daniel Pitti" <[log in to unmask]>
>To: <[log in to unmask]>
>Sent: Monday, September 17, 2001 3:20 PM
>Subject: Re: XSL and EAD
>
>
> > Hugo,
> >
> > You make a distinction between a content standard and presentation, and
> > then state that ISAD and ISAAR are about content and EAD is about
> > presentation. This is not quite accurate.
> >
> > Given this sentence in your message:
> >
> > ISAD(G) and ISAAR(CPF) are independent from any presentation whether
> > electronic, conventional paper, Web or whatever."
> >
> > It would accurate to replace ISAD(G) and ISAAR(CPF) in your statement with
> > EAD:
> >
> > EAD is independent from any presentation whether electronic, conventional
> > paper, Web or whatever.
> >
> > All of these presentations are possible derivatives of EAD, and in a wide
> > variety of styles. Add voice sensitized output and Braille as well. And
> > perhaps other possibilities that we have not yet conceived.
> >
> > I would characterize EAD as an XML-based semantic and structural
> > REPRESENTATION of archival description. It provides a way of representing
> > the intellectual content prescribed in the content standard in a
> > machine-readable and usable form. Presentation being but one use.
> >
> > Instead of two standards, I would list three: content (or intellectual);
> > representation (sometimes called structural or communication); and
> > presentation. I am not aware of any formal efforts to standardize the
> > latter, though I would  very much welcome such an effort.
> >
> > Daniel
> >

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

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