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.