Hi Brian,
Hi everybody,

Brian Tingle wrote:

>What about some sort of XPATH / XPOINTER based inclusion mechanism? 
>
Great ;-)
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 
information redundant.

- 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.
<fixity>
    <messageDigestAlgorithm reftovalue="true"> xpointer to CHECKSUMTYPE 
element in mets:file element</messageDigestAlgorithm>
    <messageDigest reftovalue="true"> xpointer to CHECKSUM element in 
mets:file element </messageDigest>
    <messageDigestOriginator>...</messageDigestOriginator>
</fixity>

- 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:
<file>

    <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 -->
</file>

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. 


Ciao
Markus