The DAITSS programming group (Randy Fischer, Franco Lazzarino, Carol
Chou, and Manny Rodriguez) met on this late last week and these are
their comments:
3. Use of PREMIS container.
Overall, we preferred to say that if you want to keep all PREMIS
metadata together you MUST use the container, and if you want to
distribute it to multiple METS sections then you MUST NOT use the
container. Then the simple presence of the container would tell you
that you need not look anywhere else for PREMIS metadata.
However, Franco pointed out that if you do not use the container, you
don't get the version (i.e. v1-1 as opposed to v1). So that would argue
to always use the container. Or change the schema.
4. Use with format specific technical metadata
The proposed rule is, when the same element is defined in both PREMIS
and a format-specific scheme, always put a value in PREMIS and
optionally repeat it in the format-specific scheme. The problem with
redundant metadata is that it introduces the possibility of conflict --
what if the two values don't agree? So if you allow redundancy, one
place always has to be declared as authoritative, in this case
presumably PREMIS. So if only PREMIS is authoritative, that implies you
can't trust the non-authoritative metadata in the format-specific
scheme, and the question becomes, are there circumstances it may be
useful to record non-authoritative metadata?
Ideally values should be in one place only. We like Marcus Enders'
suggestion of using XPath expressions.
5. METS structMap v. PREMIS structural relationships
Agree METS structMap is preferred, but we recommend no redundant PREMIS
elements for the reasons stated above.
6. Other METS redundancies
Agree PREMIS is preferred, but we recommend no redundant METS elements
for the reasons stated above.
7. ID/IDREF and PREMIS identifiers
Franco's comment is that IDREF is global and it might be preferable to
use KEY and KEYREF. (I'm not sure I understand this so I'll just turn it
over to you XML experts out there.)
p
|