Print

Print


Jerry,

Excellent diagnoses! This all makes sense.

While EAD is not officially open for revision, there are a number of 
initiatives that will require that it be shortly: reconciliation with 
Encoded Archival Context (archival authority control) and Encoded 
Archival Guide (description of repositories holding archival 
records). And yet another "EA," which is a schema for describing 
functions and activities. All of these have complementary 
International Council of Archives standards.

While it will be open for discussion, my personal view is that the 
next version of EAD should only support XLink simple pointers, in 
particular for pointing to "digital archival objects" by way of a 
METS instance (or instances, as the case may be). This may simplify 
the reconciliation if the working group agrees.

Daniel

  At 04:26 PM 5/8/2007, Jerome McDonough wrote:
>The good news (and the bad news) is that isn't your fault.  The METS
>schema and the EAD
>schema both declare the xlink namespace using the official xlink URI,
>and both associate
>the XLink namespace URI with a particular XLink schema file.
>Unfortunately, they do not
>associate the XLink namespace URI with the *same* schema file.  Both
>EAD and METS created
>their own schema files for XLink, and they are not the same.  Your
>instance file references the
>METS schema file in the schemaLocation attribute before it references
>the EAD schema file.  The
>METS file is loaded by the XML parser, and when that happens, it
>imports the METS Xlink schema
>file.  The reference by the EAD schema file to a different XLink
>schema file is ignored, since you've
>already associated a schema with the XLink namespace URI when you
>referenced the METS schema
>file.  The parser then tries to validate the EAD instance in your
>document, which in turn involves loading
>and parsing the EAD schema file; the parser tries to resolve
>references to Xlink entities in the EAD
>schema file within the METS Xlink schema file and fails, since they
>use slightly different names/constructions,
>and your parser throws an error.
>
>Short term solution: validate your EAD as a standalone EAD document,
>then import it into your METS file,
>and omit the reference to the EAD schema file in the schemaLocation
>attribute.
>
>Long term solution: Ask the METS board, the EAD schema working group
>and LC to resolve the
>incompatibilities between the METS/MODS/MADS Xlink schema and the EAD
>Xlink schema.
>
>On May 8, 2007, at 10:23 AM, Cory Nimer wrote:
>
>>I tried to cut down the METS document as much as possible, while
>>retaining the included EAD instance that is generating the errors. Any
>>suggestions that anyone could give would be appreciated.
>>
>>Here is the XML:
>>====================================================================== ==
>>=
>>
>><?xml version="1.0" encoding="UTF-8"?>
>><mets:mets xmlns:mets="http://www.loc.gov/METS/"
>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>     xmlns:ead="urn:isbn:1-931666-22-9"
>>     xmlns:dc="http://purl.org/dc/elements/1.1/"
>>     xsi:schemaLocation="http://www.loc.gov/METS/
>> > http://www.loc.gov/standards/mets/mets.xsd urn:isbn:1-931666-22-9
>> > http://www.loc.gov/ead/ead.xsd http://purl.org/dc/elements/1.1/
>> > http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd">
>>     <mets:metsHdr>
>>         <mets:agent ROLE="CREATOR">
>>             <mets:name>Cory Nimer</mets:name>
>>         </mets:agent>
>>     </mets:metsHdr>
>>     <mets:dmdSec ID="DMD1">
>>         <mets:mdWrap MDTYPE="EAD">
>>             <mets:xmlData>
>>                 <ead:ead>
>>                     <ead:eadheader>
>>                         <ead:eadid>BYU-MSS-001</ead:eadid>
>>                         <ead:filedesc>
>>                             <ead:titlestmt>
>>                                 <ead:titleproper>Test EAD
>>Instance</ead:titleproper>
>>                             </ead:titlestmt>
>>                         </ead:filedesc>
>>                     </ead:eadheader>
>>                     <ead:archdesc level="collection">
>>                         <ead:did>
>>                             <ead:unittitle>Test EAD
>>Instance</ead:unittitle>
>>                         </ead:did>
>>                     </ead:archdesc>
>>                 </ead:ead>
>>             </mets:xmlData>
>>         </mets:mdWrap>
>>     </mets:dmdSec>
>>     <mets:amdSec>
>>         <mets:rightsMD ID="RTS1">
>>             <mets:mdWrap MDTYPE="DC">
>>                 <mets:xmlData>
>>                     <dc:rights>Public domain</dc:rights>
>>                 </mets:xmlData>
>>             </mets:mdWrap>
>>         </mets:rightsMD>
>>     </mets:amdSec>
>>     <mets:fileSec>
>>         <mets:fileGrp/>
>>     </mets:fileSec>
>>     <mets:structMap>
>>         <mets:div>
>>             <mets:fptr/>
>>         </mets:div>
>>     </mets:structMap>
>></mets:mets>
>>
>>====================================================================== =
>>Thank you for your help with this.
>>
>>Cory Nimer
>>Manuscripts Cataloger/Metadata Specialist
>>Brigham Young University
>>1108 HBLL
>>(801) 422-6091
>>
>>
>>-----Original Message-----
>>From: Metadata Encoding and Transmission Standard
>>[mailto:[log in to unmask]]
>>On Behalf Of Brian Tingle
>>Sent: Friday, May 04, 2007 1:32 AM
>>To: [log in to unmask]
>>Subject: Re: [METS] Errors from EAD document embedded in METS
>>
>>Could you pass along one of your METS, either to me or to the list.
>>I'll take a look and see if I can figure out what's going on.
>>
>>-- Brian
>
>Jerome McDonough, Asst. Professor
>Graduate School of Library & Information Science
>University of Illinois, Urbana-Champaign
>501 E. Daniel Street, Room 202
>Champaign, IL 61820
>(217) 244-5916
>[log in to unmask]
>

Daniel V. Pitti, Associate Director
Institute for Advanced Technology in the Humanities
319 Alderman Library
P.O. Box 400115
University of Virginia
Charlottesville, Virginia 22904-4115
Phone: 434-924-6594
Fax: 434-982-2363