Brian Tingle wrote:
>What about some sort of XPATH / XPOINTER based inclusion mechanism?
Xpointer and Xpath is a very good mechanism to link sementical related
elements; but anyhow we need to know where to store the inital metadata
and where to store the link. It should be one of the aims that
people/programs who are just interpreting the METS or just interpreting
the PREMIS should get as much information as possible without storing
- structural information:
I would like - as probably many others as well - want to store
structural information in METS. Premis provides an own
relationship-element, which might also describe other relationships than
just structural ones.
Therefore I would not suggest to remove this element - but I would like
to suggest using METS to describe an object with it's relations, if METS
offers possibilites for it (as it does for structural relationships).
Other relationships, which cannot be handled by METS I would prefer
using the relationship element from Premis.
It might be difficult here at all to avoid redundancies; therefore I
would not provide links between METS and PREMIS for redundant information.
- linking from Premis (e.g. checksum information):
METS provides already a possibility to store checksums for files. In
this case I would like to link the <fixity> information from Premis with
the CHECKSUM attribute in METS. Theoretically you could link both ways -
from METS to PREMIS or from PREMIS to METS.
As the checksum is attached to the file very closely, I would like to
keep in the file section of METS and point from PREMIS to METS.
In this case we need to have a field, in which we might store an
xpointer. There would be several possibilities to store an xpointer: To
distinguish if the content of the element is a value or a reference to a
value, the PREMIS schema should contain an attribute.
As the messageDigestOriginator is not stored in METS, it should be
amended in the <premis:fixity> element, as it is mandatory according to
In the end it might look somehow like the following example.
<messageDigestAlgorithm reftovalue="true"> xpointer to CHECKSUMTYPE
element in mets:file element</messageDigestAlgorithm>
<messageDigest reftovalue="true"> xpointer to CHECKSUM element in
mets:file element </messageDigest>
- linking to Premis:
Linking to Premis might be more complicate almost none of the premis
elements provide a possibiliy to attach xml identifiers to this element.
Linking can be done using xpath, but as METS/PREMIS files might become
very big and complex, chances are high that after modifying a file (e.g.
by adding new data, new metadata sections), that the path to the
appropriate PREMIS element would not stay the same.
Are there any objections not to have optional ID attributes for every
premis element. These ID attributes would be xml-ids.
As we are currently discussing the METS 1.5 schema - see Brians mail on
METS mailing list from end of july:
<Flocat /> <!-- location of *tar.gz file -->
<transformFile /> <!-- Instructions on reversing gzip -->
<transformFile /> <! Instructions on reversing tar -->
<file /> <!-- first embedded file -->
<file > <!-- second embedded file -->
<stream /> <!-- first embedded stream -->
<stream /> <!-- second embedded stream -->
For the instruction how to transform a file (the <transformFile> element) it would be great to point into a PREMIS enviroment information; i would prefer doing this using IDs as well.
As there are some possibilities linking from and to premis, I don't want to suggest, how we should link things, but for me it seems that we need mechanisms to make linking easier.