[OAI-implementers] points to ponder

[Hussein Suleman]

hi

thanks for all the comments.

to add a few more dimensions and details,

of course the whole reason i am faced with the naming of interfaces 
problem is the feedback i have received so far on the ODL project - 
which is largely that overloading could lead to confusion (as Tim spoke 
about). in contrast, the REST project specifically promotes the use of a 
small set of overloaded "verbs" (supporting Jewel's notion of 
simplicity) and REST has both theoretical backing and a fair amount of 
support in the Web community. so to go with the middle road, i am 
contemplating a suite of interfaces based on a set of fundamental 
names/parameters that are unrelated to OAI (at least namespace-wise).

however, i don't quite see the point of inventing an analogy to 
GetRecord(identifier) just to be different. in fact, in REST terminology 
it would be not RESTful because having n different base protocols means 
n-squared combinations (of course the REST docs explain this much better 
than i am doing here - if you havent read about REST, you should).

Naomi suggested using namespaces and i want to do that since i am a big 
namespace fan :). but i am not sure what would be kosher. i can easily 
use different namespaces for requests - thats not a big deal. but should 
i also use different namespaces for, say, a record format? if i put 
records into a database and then build an OAI-PMH interface over the 
database, this could result in a fair amount of namespace-transferrence 
... i am still thinking this through and if anyone has done something 
similar i would like to hear your ideas ...

[in actuality, i stopped thinking 2 weeks ago and decided to upgrade my 
XML parser to DOM2 so i can manipulate namespaces ... if anyone is 
interested in testing a single-file no-installation-required 
zero-dependency 95%-complete-W3C-API pure-perl DOM2 XML parser, let me know]

it may not be obvious from the type of component/protocol experiments i 
do, but i too support the notion that OAI-PMH should be a simple and 
tightly controlled protocol spec. anything that is not OAI-PMH should be 
appropriately labelled and the idea of extended interfaces which are a 
superset is not something i want to do (i tried it 2 years ago and it 
just didnt taste right :)). also, i find a lot of resistance to ODL came 
from people who assumed that at VT we were proposing a 
production-quality protocol whereas what we were really doing was 
reusing an existing framework to investigate what was ultimately needed 
in a production-quality protocol or suite of protocols. i want to test 
the simplicity/understandability/performance/impact but i always get 
asked "where has this been used in practice" ... is it possible that we 
have so many complex/incomplete/changing network protocols because we 
dont sufficiently experiment/research before we design?

Tim also mentioned harvesting. does any reuse of the interface names 
suggest harvesting? to someone who only knows OAI-PMH, it is quite 
possible. but in a different context, GetRecord does not have to imply 
harvesting. so did we succeed in creating an accidental association 
between general DL concepts and OAI? if so, maybe in future we should 
name these service requests more specifically, e.g. "PMH_GetRecord".

as a bottom-line: on the last page of my dissertation, i hypothesized
that maybe we need an independent protocol parallel to, but informed by, 
OAI-PMH for inter-component communication. this is where i am heading at 
the end of the day ... is it worth the effort? or am i the only one out 
there who would like to easily combine the basic EPrints structure with 
Greenstone's search engine and an advanced peer-review module and have 
it all run off my PDA ? :)

ttfn,
----hussein

-- 
=====================================================================
hussein suleman ~ hussein@cs.uct.ac.za ~ http://www.husseinsspace.com
=====================================================================