Print

Print


On Monday, May 5, 2014, Colin Gross <[log in to unmask]> wrote:

> 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]<javascript:_e(%7B%7D,'cvml',[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?
>>
>>
>>
>
>