On Mon, 20 Aug 2007, Priscilla Caplan wrote:
> 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.
To me, it makes a lot of sense to add the version attribute to each
separate schema. It is possible that someone may mix versions-- or that
one schema may not be updated when another one is. What do others think?
I would agree, it is better to specify that if you put all metadata in one
place that you use the container.
> 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.
The reason we proposed keeping it in both places as an option is that
there are programs that stick Jhove output (like in MIX) in a METS techMD
section. It would be easier to keep it than remove it. But we do need to
experiment with 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.
It might be good to experiment with transforming a METS structMap to
PREMIS relationships for the scenario where METS is used as a transfer
format and the repository takes it apart and stores the metadata in a
database as something like PREMIS semantic units-- or like Fedora, where
I'm told that relationships are treated separately.
> 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.)
One of our XML experts didn't understand this either, so please explain.