On Fri, 17 Aug 2007, Markus Enders wrote:

> Hi Rebecca,
> 
> thanks a lot for compiling the darft document. Just some comments from 
> me - just before the weekend starts ;-)
> 
> - I would not assume that the <premis:object> section contains mostly 
> technical data; therefore I would not vote for putting the 
> <premis_object> under techMD. This might probably be the case  for files 
> and bitstreams, but for "representations" the situtation is differently. 
> Storing just relationship information between DocStructs (e.g 
> MetadataUpdate event occured) doesn't really contain technical information.

I don't understand what you mean in the last sentence. Is it just
relationships that you think are not technical metadata? Or just
structural relationships? I would think that you could consider derivative
relationships technical metadata for instance. Of course this is the
problem we have in METS where you can't put elements directly under
amdSec-- that you have to categorize the information as techMD or
digiProvMD. And if you don't vote for putting premis:object under techMD
where would you put it?

> Anyhow: it seems that the Object.xsd contains several different kind of 
> information. Did you (the premis community) consider to extract the 
> relationship section and create an xsd of its own for it?

No, we didn't consider an xsd for relationships. The schemas that were
written were faithful to the PREMIS data model and thus there is one for
each entity in the model. This made it fairly implementation independent.
It should be possible to extract the relationship information if you
wanted to.
 
> - I just wonder, if we shouldn't really talk about, how we may avoid 
> storing metadata redundantly. Especially in more dynamic scenarios where 
> content gets updated by different tools, by different workflows, it 
> might become unhandy to keep data consistent.
> I'm not talking about changing the premis data model. One approach could 
> e.g. be to allow Xpath expressions stored in a separate 
> premis-attributes to point to different elements or attributes within 
> the same xml-file.

Sure, I think that we will see METS as a transfer format that gets
ingested or disseminated and then the metadata stored various ways. Could
you supply an example of how you might use Xpath expressions?
 
> - I doubt, we can describe best-practises in a general way without 
> specifying the context. E.g. the idea of linking METS and premis using 
> IDREF (somehow nothing else than a very special XPath) always leads to a 
> mix of a container format (METS) and a metadata format (premis), which 
> might not be appropriate. I think , in general the usage of a metadata 
> format should be independent of a container format. I can imagine a lot 
> of scenarios in which METS is used as an ingest format - but internally 
> the data is split up: the metadata gets indexed, stored in different 
> database fields, gets embedded into other container formats etc - in 
> other words: gets separated from the container format. Mixing the 
> container format and the metadata format makes it hard to pull data out.

So I think you are speaking about the suggestion of using the PREMIS
IDs with the METS IDrefs? I think it may be a concern that the only
way things are tied together are with these that only make sense within a
METS document. We might want to look at how understandable these are if
you store the PREMIS outside the METS document. Clay worked on that
example using mdWrap instead of mdRef (which is a little different from
what you're talking about, but even with that model it gives us another
way of looking at these issues).
 
> > For that reason, the decision, how strong the container format and a 
> metadata format should be tied together is really specific to the usage 
> scenario / application. In theory they shouldn't be tied together at all.

What does this mean for these best practices (or guidelines, or whatever
you want to call them)? What would you change? After all, the point of
them is to give guidance on how to use PREMIS with METS if that is your
scenario. For instance, even if you store things in a database and you
want to disseminate or ingest a METS document, we want it to be
predictable how the metadata will be carried and thus specify how in this 
particular container format PREMIS will look.

So any suggestions for specific improvements are welcome.

Rebecca

> 
> Ciao
> Markus
>