Print

Print


The METS schema itself does not appear to disallow replicate xlink:href
values.  The sample provided appears to be valid as each entry has a unique
ID.  However, it appears to violate the intent of the fileSec as it is
described:

The overall purpose of the content file section element <fileSec> is to
> provide an inventory of and the location for the content files that
> comprise the digital object being described in the METS document.


I would not expect a parser that validates using the schema to flag this as
an error.  It is syntactically and structurally correct according to the
schema.

However, this does look like a logical error.  Having multiple entries for
the same item in an inventory is generally a bad plan.  This would be the
sort of error that a purpose build validator for your profile could be
designed to flag.



/* Colin Gross
 * Application Programmer
 * Digital Library Production Service
 * University of Michigan Library
*/


On Mon, May 5, 2014 at 12:23 PM, Lydia Motyka <[log in to unmask]> wrote:

>  We’ve encountered a situation in METS files that passes validation
> against the METS schema but perhaps shouldn’t:  METS files that contain
> duplicate FLocat elements.  In other words, multiple FLocat elements within
> a fileSec that refer to the same file.  For example:
>
>
>
> <METS:fileSec>
>
> <METS:fileGrp USE="archive" >
>
> <METS:file GROUPID="G1" ID="TIF1" MIMETYPE="image/tiff">
>
> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="1.tif" />
>
> </METS:file>
>
> <METS:file GROUPID="G1" ID="TIF1.2" MIMETYPE="image/tiff">
>
> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="1.tif" />
>
> </METS:file>
>
> <METS:file GROUPID="G1" ID="TIF1.3" MIMETYPE="image/tiff">
>
> <METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="1.tif" />
>
> </METS:file>
>
> </METS:fileGrp>
>
>
>
> Shouldn’t this be considered invalid METS?
>
>
>