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.
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?
- 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.
- 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.
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.