Thanks for the good summary of our rationale for how behaviors and
structure are related to each other. I think you have clearly captured
what we concluded about why the behaviorSec should point to the
structMap instead of the other way around.
> -----Original Message-----
> From: MacKenzie [mailto:[log in to unmask]]
> Sent: Sunday, November 25, 2001 4:13 PM
> To: [log in to unmask]
> Subject: Re: [METS] METS Meeting Summary
> Thanks Jerry for the excellent meeting summary and change
> list! Very lucid
> and complete. I just have one follow-up comment and one change that we
> talked about but didn't make it onto your list...
> First, regarding the new behaviorSec metadata "bucket", I
> think it's worth
> a recap of our discussion about pointing out from behaviorSec to the
> structMap vs pointing into behaviorSec from the structMap. So far,
> pointers to metadata (descriptive and various flavors of
> originate in the structMap using the ID/IDREF mechanism. For
> however, the pointers will originate in beviorSec and _target_ the
> structMap using IDs assigned to the relevant div elements. While this
> might seem to introduce an inconsistency, it makes sense for
> a couple of
> While most parts of the METS document are thought to be
> fairly long-lived
> (assuming they reflect some inherent structure or properties of the
> logical digital object), behaviorSec metadata will probably change
> frequently as "disseminators" come and go. Having behaviors point at
> structures should make it easier to maintain the METS object since a
> behaviorSec element can be deleted or replaced without
> consequence (i.e.
> no broken ID/IDREF pairs).
> A related concern was the ability to exchange METS objects
> between digital
> libraries. The METS content & metadata defined so far is of
> general value,
> not just to the organization that creates it. But metadata about
> "disseminators" or behaviors may well be
> organization-specific and not of
> general interest, so we wanted to make it simple to exchange
> METS objects
> _without_ the behaviorSec metadata. And since behaviorSec
> will point out
> to the structMap it can be stripped without invalidating the
> rest of the
> METS file.
> I think we'd welcome any comments about this decision, since
> no one has a
> lot of experience at modelling "behavioral metadata" so far!
> Secondly, we spent a few minutes at the meeting discussing the two
> elements that point out of the METS document: FLocat and
> mptr. Currently
> these are defined identically but are scoped differently: mptr is only
> valid in a div element, while FLocat is only valid in the
> file element.
> Since they do seem to serve the same purpose, we thought it
> would be good
> to just use mptr in both places and do away with FLocat.
> That's it from my notes, hasta la vista,
> MacKenzie Smith
> [log in to unmask]
> Digital Library Program Manager phone: (617)495-3724
> Office for Information Systems fax: (617)495-0491
> Harvard University Library