Suppose two archives want to share records. One archive has a
policy that dictates that a creator and ipowner be specified as
agents in every document that is archived. The other archive has a
similar policy but allows and distinction between
copyright and trademark holders in indicating owners of intellectual
property. They do so using the "OTHERROLE" attribute.
Now suppose the first archive runs software that notifies the owner of
intellectual property rights of any change to the METS document. It would
be useful to be able to map from the de facto schema of the original
archive to that of the recieving archive. Obviously there mapping in the
other direction would be less straightforward - but might also be
On Fri, 19 Jul 2002, Merrilee Proffitt wrote:
> 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.
> At 09:02 PM 7/18/2002 -0400, you wrote:
> >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?
> >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
> > > >
> > >