My thinking is as follows:
As the agent element exists currently, users have two choices in
designating roles with regard to the METS document:
1) stretch their local vocabulary to fit the implied semantics of the
ROLE attribute, resulting from and in decreased flexibility.
2) make use of the OTHERROLE attribute
Given use of the OTHERROLE attribute, applications could either
1)ignore it, resulting in decreased functionality
2)deal with it on a local basis, resulting in decreased interoperability.
I think that a pointer to or wrapper for an XML schema could retain
flexibility, functionality, and interoperability given (borrowing some
semantic web ideas here)
1) registration of the schema and
2) appropriate XSL transformations to allow conversion between schemas.
That said, I apologize if I am butting in here with concerns that are not
in keeping with the momentum of the group. Could someone orient me?
College of Information Studies
University of Maryland, College Park
On Thu, 18 Jul 2002, Jerome McDonough wrote:
> I think the list of agent roles could benefit both from elaboration
> and addition, but it's relatively low on the list of things to
> do at the moment. And the METS editorial board chair currently
> being under quarantine for chickenpox isn't speeding things
> I'm afraid. :/
> I'm afraid I have to disagree on the notion that extension
> schema enhance interoperability. Extension schema provide
> for flexibility in local practice, while retaining compatibility
> (read standardization) in the rest of the METS document format.
> To the extent we all agree on using one extension schema for
> a particular purpose, interoperability is enhanced, but frankly
> if the agreement is universal it would probably be best to
> make such an extension part of the primary schema. Extension
> schema were developed to handle those cases where the original
> METS community couldn't come to immediate agreement on issues.
> So, I'm somewhat reluctant to add new spots for extension schema,
> particularly when we haven't had any discussion to determine
> whether we need one (that is, whether there's widespread disagreement
> on agent roles). Clay, do have particular roles in mind
> that you think are lacking and should be added?
> > Might the enumeration of roles in the agent element of the METS header
> > benefit from a little elaboration? They are fairly intuitive, but
> > is it
> > useful to provide a list of options if they are not clearly
> > defined? Why
> > not just allow institutions to develop their own lists? This is
> > currentlypossible through the use of the "OTHERROLE" attribute,
> > but from the
> > standpoint of interoperability might be more productively
> > accomadated by
> > allowing for an extension schema.
> > Clay Templeton
> > MLS Student
> > College of Information Science
> > University of Maryland