[OAI-implementers] points to ponder

[Tim Cole]

Hussein-

I would hesitate to reuse existing OAI-PMH verbs for new or extended
purposes. In programming languages, I prefer languages where new
functionality means new semantics and syntax, rather than revision of
existing semantics and syntax. Generally this better preserves backward
compatibility and avoids confusion.

Of course some examples are worse than others.

Tolerable, in terms of backwards compatibility at least, would be
'overloading' an existing OAI verb, i.e., situations where you extended
the functional capability of an OAI-PMH verb by allowing additional
optional arguments, but retain all existing optional arguments and keep
required arguments and the return semantics and syntax essentially the
same (except, perhaps, in response to an overloaded request). A
conforming OAI-PMH 2.0 harvester could then query a provider that
understood such extensions without any compatibility issues (the OAI-PMH
2.0 harvester simply wouldn't know how to exploit the added features).
Of course a harvester wanting to exploit new extensions would get an
error response from a conforming 2.0 OAI-PMH provider, but such a
harvester could easily handle this situation gracefully. I have some
philosophical concerns about even this approach, but at least it
wouldn't be hugely disruptive to the base of installed OAI-PMH providers
and harvesters.

Much less desirable would be extensions to existing OAI-PMH 2.0 verbs
that changed required arguments, deprecated existing optional arguments,
or changed return semantics and syntax in ways that conforming OAI-PMH
2.0 harvesters couldn't handle. Such protocol extensions would greatly
degrade potential for interoperability between systems using the new
extensions and those still conforming to OAI-PMH 2.0. It would also lead
to confusions such as are currently being seen in the RSS community
(where they can't even agree on what RSS stands for). I think such
changes would be a huge mistake, and we could find ourselves in a world
of dueling OAI protocol versions. Much preferable in my mind for such
situations would be to create entirely new verbs, even if those verbs
subsumed functions of an existing OAI-PMH 2.0 verb (though even this
approach still runs some risk of parallel, incompatible enhancements,
such as has been encountered in the RSS world). Some duplicative
functionality across verbs (i.e., an ability to fetch a record in a
couple of different ways) would be acceptable, I think.

The other issue implicit in your question is whether OAI should evolve
into a suite of related but distinct individual protocol pieces.
(Perhaps kept track of, as Naomi suggests, by using namespaces -- though
unfortunately OAI-PMH 2.0 didn't contemplate a way to associate verbs in
an OAI request with namespaces. Another reason to look at a SOAP version
of OAI?) A family of protocols approach would allow a continuum of
interoperability protocol development while still maintaining
distinctions and allowing implementers to implement only the levels of
protocol complexity they needed. Philosophically I see this as better
than trying to develop a single protocol that does everything for
everyone (much as has been tried with Z39.50). I think this would be the
best way to go if support and resources for the kind of community
consensus building used to create OAI-PMH can be found to facilitate
work on new, supplemental protocols (e.g., the OAI Static Repository
protocol now being considered), I'm just not sure such support is in the
cards near-term for OAI now that initial funding from CNI and DLF is
gone.

Just my opinion (and of course I don't know what kinds of copyright or
other IP protections Carl and Herbert may have had the foresight to
place on OAI-PMH vocabularies).

Tim Cole
University of Illinois at UC

----- Original Message ----- 
From: "Hussein Suleman" <hussein@cs.uct.ac.za>
To: "OAI-implementers" <OAI-implementers@oaisrv.nsdl.cornell.edu>
Sent: Tuesday, May 13, 2003 11:20 AM
Subject: [OAI-implementers] points to ponder


> hi
>
> i am sitting here looking out the window wondering why OAI people are
so
> wedded to the idea that we should not use parts of the protocol in any
> way for other purposes ... on the board behind me i have a matrix of
> protocol requirements and i need to name and parametrise the
individual
> interfaces ... and i dont want to create new names just to be
different
> but past experience says that if i do not, it will be an uphill battle
> against people who believe OAI is not to be tampered with ...
>
> should i use a completely new vocabulary for random access to a
> repository/database/component or are words like "GetRecord" and
> "ListRecords" ok? can the parameters be the same or are "identifier"
and
> "set" reserved for OAI-PMH? is the record format strictly for OAI-PMH
only?
>
> obviously OAI did not invent remote access to records - all it did was
> popularise and standardise a way of doing it. is it not time we
realised
> that the OAI-PMH specifies so much more in terms of DL practices than
> just a harvesting protocol?
>
> precisely where is the line between metadata harvesting and DL
practices?
>
> i remember some 3 years ago, when OAIv1.0 was being designed we
referred
> to Z39.50 as the "800-pound gorilla" - the protocol that everyone
> supported and you did not openly challenge. is OAI-PMH the new
800-pound
> gorilla?
>
> anyway, just thought i would throw this out for discussion. it seems
the
> general forum is announcement-only so this is the only place for
discussion.
>
> ttfn,
> ----hussein
>
> -- 
> =====================================================================
> hussein suleman ~ hussein@cs.uct.ac.za ~ http://www.husseinsspace.com
> =====================================================================
>
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>