I am not sure we really understand what object the <mptr> should
reference. The METS primer and the METS schema documentation are not
really clear:


The schema documentation says:

"The mptr element allows a div to be associated with a separate METS
document containing the content corresponding with that div, rather than
pointing to an internal file or file group. A typical instance of this
would be the case of a METS document for a journal run, with a div
elements for each individual journal issue. The div elements for the
issues might point to separate METS documents for each issue, rather
than having files and file groups for every issue encoded in one


The primer says:

"Through its subsidiary elements, each <div> element points to the
digital content that manifests it. It can do so through one or more
<mptr> element, if this content is represented by one or more external
METS documents, or through one or more <fptr> element, if this content
is represented by one or more <file> elements in the <fileSec>. "


What you assume in your posing is that the mptr is analogue to an fptr.
Which actually means both are pointing to a "Digital Manifestation" of
an object. With "Digital Manifestation" I mean a bytestream which can be
rendered and contains the content of the <div>.


But somehow the (referenced) METS document is _more_ than just a Digital
Manifestation. As each METS document must have a top level <div> element
in the structMap and this <div> does not represent a Digital
Manifestation, but an (intellectual) object, I wonder, if a mptr and a
fptr can be regarded as analogues. My feeling is that they cannot. A
METS file is NOT a "Digital Manifestation", but a container containing a
description of another "intellectual" object.


In this case, we have link between a <div> and another <div> (in another
METS file). And this is exactly what we represent by the smLink element,
with the difference that the <div> needs to be in the same METS file.

If we are "replacing" the smLink element by smLinkLocator, which will
allow links into METS files, we will have two possibilities to link one
div to another div.


Would like to hear some opinions....





From: Metadata Encoding and Transmission Standard [mailto:[log in to unmask]]
On Behalf Of Rick Beaubien
Sent: 26 November 2008 16:25
To: [log in to unmask]
Subject: [METS] Discussion regarding proposed xlink:extendedLink
implementation in METS


Regarding 1)  In my examples I tried to show my sense of what the
xlink:locatorLink elements would look like in cases where they expressed
links between structural divisions of structMaps in different METS
documents.  The xlink:href of the smLocatorLink would reference not just
an external mets document, but a specific div within that external mets
document by means of the ID attribute value that identifies the
pertinent div.  To my mind an mptr and a smLocatorLink are very
different "beasts" even when the smLocatorLink references a div in an
external METS document.  The mptr is analogous to an fptr, and as such
represents a manifestation of the content of it's parent div.  Typically
the mptr would reference an integral external mets document which, as a
whole, would constitute a manifestation of the parent div.  An
smLocatorLink doesn't represent a particular manifestation content per
se; rather it identifies a structural division in either its own or
another METS document which is somehow linked to another structural
division in either its own or another METS document.

Experience the British Library online at
The British Library's new interactive Annual Report and Accounts 2007/08 :
Help the British Library conserve the world's knowledge. Adopt a Book.
The Library's St Pancras site is WiFi - enabled
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the [log in to unmask] : The contents of this e-mail must not be disclosed or copied without the sender's consent. 
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.