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 document.”


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 www.bl.uk
The British Library’s new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook
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.