If I may be permitted a second reply :)
I must admit that I was thinking in terms of
"structure that won't be utilized in the near future" in raising the
my concern about the agent role. The example of need for interoperability
that I gave in my last posting was invented in response to your question,
it didn't motivate mine. I did not originally consider whether the roles
currently enumerated in the agent element were sufficient at present. I
simply assumed that eventually they might not be, and that even now an
archive could be found somewhere for which they were not.
I think an obstacle to understanding here might be that I am not aware of
some assumptions (tacit or otherwise?) concerning METS
development - in this case, that it should be motivated by current "real life
needs and applications". If this is in fact something that is agreed
upon, then clearly the agent element is fine the way it is, or else would
be fine with some additions/elaborations. However, if long term stability
is a goal, it might be advisable to explore more flexible options.
As to interoperability, I must conceed that it does not now appear to me
that providing space for extensions - i.e. flexibility - necessarily
leads to interoperability, and could in fact do just the
opposite. However, it seems like room for extentions would keep
the interoperability problem outside of METS and in the
extensions. Whether this is good or bad is quite debatable.
I do not have a particular problem with the metsHeader the way it is
now. In fact, I think the entire standard is great - that's why I
choose to work with it and joined this group. I'm sorry if I came across
a little critical in my first email on the subject of the header.
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
> > > >
> > >