Date:         Fri, 19 Jul 2002 11:10:43 -0700
Reply-To:     Metadata Encoding and Transmission Standard
              <[log in to unmask]>
Sender:       Metadata Encoding and Transmission Standard
              <[log in to unmask]>
From:         Merrilee Proffitt <[log in to unmask]>
Subject:      Re: METS Header
Comments: To: Metadata Encoding and Transmission Standard <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Clay,

Maybe you could elaborate on what interoperability you have in mind that
would utilize the agent element?  I think in developing METS, priority
needs to be allocated to real-life needs and applications, and not building
structure that won't be utilized in the near future.  This is not meant to
put a damper on discussion, but will help me, and perhaps others,
understand what you have in mind.  It's Friday, and I'm unimaginative.

Thanks,

Merrilee

At 09:02 PM 7/18/2002 -0400, you wrote:
>Jerome,
>
>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.
>or
>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?
>
>Clay Templeton
>MLS Student
>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
> > >
> >