Date:Wed, 5 Sep 2001 06:35:16 -0700
Reply-To:Metadata Encoding and Transmission Standard
<[log in to unmask]>
Sender:Metadata Encoding and Transmission Standard
<[log in to unmask]>
From:Rick Beaubien <[log in to unmask]>
Subject:Re: METS change proposal for September meeting
Comments:To: Metadata Encoding and Transmission Standard <[log in to unmask]>
In-Reply-To:<[log in to unmask] u>
Content-Type:text/plain; charset="us-ascii"
I am rereading the METS postings in preparation for next weeks meeting, and
realized that I should have responded to MacKenzie's proposal here long
ago. Based on my current, albeit tentative, understanding of xlink, I
don't feel that adopting xlink syntax for external links in fLocat, mptr
and mdRef elements would pose a big MOA2 to METS migration problem for
Berkeley. Unless I'm really missing something--only too possible--it
doesn't look any more difficult to me than some of the other migration
issues. Besides, Berkeley's migration issues shouldn't be wagging the dog;
the general and long-term aptness of the choices is most important. From a
tool developer's standpoint, I can see some potential advantages to using
the xlink defined attributes for all external pointers, especially if these
were expanded to include xlink:title and xlink:label attributes.
To be continued next week...
Rick
At 05:00 PM 08/13/2001 -0400, you wrote:
>Hi all,
>
>Below is a write up of a possible change to the METS schema that I would
>like to discuss at the meeting in September. It's change to the
>linking elements that we (Harvard) would like, but which has some big
>side effects so it warrants discussion. It's a long posting, so if you
>don't care about linking elements in METS (and many won't) then you can
>hit delete now. Thanks,
>
>MacKenzie/
>
>*************************************************************************
>PROPOSED METS CHANGE FOR LINKING ELEMENTS
>
>There are three external linking elements in the current METS schema:
>mdRef, FLocat, mptr. The first is in the DescMD section, and points
>to an external location for relevant descriptive metadata. The second
>is in the FileGrp (i.e. inventory) section, and points to a component
>file of the METS digital object. The third is in the StructMap
>section, and points to an external parent or child METS file.
>
>mdRef and FLocat are defined similarly: uncontrolled, string-type
>elements with a required LOCTYPE attribute indicating the type of
>pointer (URN, URL, DOI, etc.).
>
>mptr was originally defined differently -- as an empty element using the
>new xlink syntax for its attributes. These included:
>xlink:type - the XLink type, in this case, simple.
>xlink:href - the URI for the resource.
>xlink:role - a machine-readable description of the role of the resource
> identified by the XLink. The following convention has been
> established for describing the roles of METS resources:
> "container" - indicates a resource which
> can be abstractly considered to
> contain this object, as in the map
> example.
> "content" - indicates a subsidiary resource
> contained by this object
> "related" - indicates a resource for which neither
> container nor contained provides an
> an adequate description of the
> relationship to the current object
>
>In the last round of changes the mptr definition was changed to be
>like that of mdRef and FLocat elements. This was done to improve the
>schema's consistency -- in general, a good thing.
>
>But in looking forward to new uses of METS, and to new communities of
>METS users, we wonder if making these elements follow the original
>FLocat model isn't the wrong direction -- maybe changing all three to
>the xlink model would be better? Here are a few reasons:
>
>1. xlink is a W3C recommendation and is becoming the standard for
> linking syntax in XML documents. In the future, METS users who are
> familiar with XML will expect to use xlink syntax for links.
>
>2. other DTD/schema standards in the digital library community use the
> xlink sytnax, namely EAD and TEI.
>
>3. xlink offers the possibility of better link functionality in the
> future, supporting things like bi-directional and out-of-line
> links. While nothing would stop a METS developer from supporting
> this functionality with the current uncontrolled syntax, it
> wouldn't be possible to take advantage of new tools supporting
> xlink as they become available.
>
>The main problem with changing the mdRef and FLocat elements to use
>xlink is the MOA2 -> METS migration. I know this would be a big issue
>for Berkeley, and an immediate question is who else else has made use
>of these two elements? And how difficult would it be to migrate these
>elements to a new xlink-based syntax if such a migration is needed
>anyway?
>
>Finally, are there any compensating advantages to the uncontrolled
>text definitions that these linking elements have now? Any good
>reasons _not_ to go with the xlink syntax?
>
>If we're going to suffer migration pain to adopt a more standardized
>way of handling links, now is the time. But we shouldn't impose
>unnecessary pain either. Hopefully we can reach some sort of decision
>on this in September.
>
>_____________________________________________________________________________
>MacKenzie Smith [log in to unmask]
>Digital Library Program Manager phone: (617)495-3724
>Office for Information Systems fax: (617)495-0491
>Harvard University Library %\%\%\%\%\%\%\%\%\%\%\%\%\%
>-----------------------------------------------------------------------------
>
>
-----------------------------------------------------
Rick Beaubien
Software Engineer: Research and Development
Library Systems Office
Rm 386 Doe Library
University of California
Berkeley, CA 94720-6000
510-643-9776
