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.

Rebecca
 
> p