Hi all,

Last Thursday in Corvallis, OR, at the Code4Lib conference, we held a
breakout session on making OpenURL libraries for various languages to
help enable broader adoption in future developments.

It was inspired by work Ed Summers and I have been doing on writing a
Ruby OpenURL library -- we wanted to touch base with a larger crowd,
make sure our foundations had a basis in sanity and what to do with
certain aspects of the spec that are "less well documented".

The meeting started off rather rockily (I had some problems conveying
the purpose of the session), but eventually it gathered some momentum
and (I think, anyway) some useful dialogue.

Since these two lists are the most likely early adopters of any
libraries and that we ran out of time before much could get done, I'm
opening the discussion up so we can actually create something useful for
a variety of languages.

First, the foundation of the libraries:

Our current design has two completely independent classes for
ContextObject and Transport.  Neither requires the other, although
Transports can contain ContextObjects.

ContextObjects have Entities as subclasses.

The first discussion that came up involved the use of foreign keys.  Are
they part of the ContextObject?  Or the Transport?  The example used was
"sfx.ignore_date_threshold=1".  For me, an SFX user, it is critical to
be able to use foreign keys (especially /this/ foreign key) to make any
development I do worthwhile, but what part of the OpenURL does this
belong to?

Both Jeff Young and I had initially placed foreign keys in the
ContextObject (in our respective libraries), but after the discussion,
the consensus leaned towards placing them in the Transport.  The reasons
were that foreign keys are specific to a particular service and have
unpredictable results if sent to another server.

I think that could be discussed a bit more on the lists.

The next item discussed regarded what exactly could be contained in the
"metadata" of an Entity.

I asked a question about why (in SAP2 documents, at any rate) Referents
and ReferringEntities contained nested elements (see "journal" below),
but this didn't appear anywhere else.

For instance:
    <ctx:referent>
       <rft:metadata-by-val>
          <rft:metadata>
             <rft:journal>
                <rft:issn></rft:issn>
                ...
             </rft:journal>
etc.
while other entities didn't nest anything.

I learned (although it may be obvious to everyone else) that in the
metadata-by-val/metadata node you can have (basically) anything and in
this case, "journal" is, in fact, another document.  It could just as
easily be a MODS document or DC or vCard.

While this shows the versatility of OpenURL, it also proves how
difficult it is to make a useful library when really "anything" can be
passed as metadata (which, truthfully, is the probably the most
desirable part of the ContextObject in the first place).  Any ideas on
how to make this workable are welcome.

Based on Jeff Young's suggestion, the libraries should be based around a
DOM-type model for OpenURL.  Current working title is "OpenURL Object
Model" (OOM).  The libraries can then focus on methods to help simplify
the creation of OOM Documents.

The last item we got to Thursday was how to deal with the new CQL
ContextSet for OpenURL.  CQL is only dealing with the Referent, since
that is really all that is being searched for.  There was agreement,
however, that the other entities were indeed valuable (i.e. if rfr_id is
Pubmed, don't show results from Pubmed or show results based on criteria
about the Requester, etc.).  Rob Sanderson proposed that these should be
represented as an extension to SRW (rather than CQL) since they pertain
more to the "search" rather than the "item being searched".

There was also agreement on finding ways to simplify adoption for
non-scholarly materials.  OCLC uses OpenURL in this manner for WikiD and
the idea of using OpenURL to "resolve" MP3s was raised.

It appeared that there was agreement around the value of having a bunch
of libraries in different languages (independent of a resolver) that
behaved similarly.

Current libraries that we know of (please include others if you know them):

OCLC's Java Classes:
http://www.oclc.org/research/software/openurl/default.htm

Perl:
http://search.cpan.org/~timbrody/URI-OpenURL-0.4.6/lib/URI/OpenURL.pm

Ruby:
http://www.textualize.com/trac/browser/ropenurl/

And Thom Hickey has written a skeleton for Python:
http://outgoing.typepad.com/outgoing/2005/07/openurl_10.html

Thanks!
-Ross.