MacKenzie,

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.

- Sandy

> -----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 
> administrative)
> originate in the structMap using the ID/IDREF mechanism. For 
> behaviorSec,
> 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
> reasons:
> 
> 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/
> 
> 
> ______________________________________________________________
> _______________
> 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                        
> %\%\%\%\%\%\%\%\%\%\%\%\%\%
> --------------------------------------------------------------
> ---------------
>