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,
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
"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
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 %\%\%\%\%\%\%\%\%\%\%\%\%\%