Exactly,
OAI-PMH does not expose the links. And the links (e.g authorization)
are where we put a lot of our effort. Also, you'll need to re-invent a
lot of HTTP to handle deleted resources, resources that have moved,
etc. I like OAI-PMH, just not for this purpuse.
Example #1 - get RDF/N3 for August Strindberg in LIBRIS, including links
curl --header accept:text/rdf+n3 --location "http://libris.kb.se/resource/auth/94541
"
Example #2 - get the MARCXML for the same record
curl --header accept:application/marcxml+xml --location "http://libris.kb.se/resource/auth/94541
"
/martin
to get a record from LIBRIS in MARCXML
On Mar 18, 2009, at 3:01 PM, Ross Singer wrote:
> OAI-PMH could do this, yes. My personal opinion is to recommend
> against using OAI-PMH, though. It has really only gained traction in
> libraries (doing nothing to help break us from our niche), it's
> limited with regards to expanding the functionality (meaning that to
> do more sophisticated things, libraries will have to support OAI-PMH
> /and/ something else), and I think it would continue to lock us into
> this record-centric approach even longer.
>
> Martin is suggesting linked data. Basically, the same URL you use for
> the catalog record could also produce RDF (or XML or JSON or whatever,
> but usually RDF) based on content negotiation. A web browser, which
> almost always asks for */* would get text/html or
> application/xhtml+xml but if the 'agent' asked for
> 'application/rdf+xml' or 'application/marc' or 'application/json', at
> the same URI, they would get the resources available there. The API
> is the URI, to use Martin's parlance.
>
> Atom (and, yes, I know I am a tiresome, one-trick pony with this)
> could also accomplish the same net result as OAI-PMH. It could bundle
> resources, provide links to HTML versions and is extensible to search
> (OpenSearch), read/write (AtomPub), etc. It also, generally, has a
> lot more legs in the wider web sphere.
>
> -Ross.
>
> On Wed, Mar 18, 2009 at 5:42 AM, Bernhard Eversberg <ev_at_biblio.tu-bs.de
> > wrote:
>> Karen Coyle wrote:
>>>
>>> I'm going to 'fourth' Owen's suggestion, or maybe second-and-a-
>>> half it, by
>>> saying that the bibliographic data must be addressable, and the
>>> address must
>>> return at least one actionable service, such as a copy of the
>>> record in a
>>> standard format or a description of available services/formats. ...
>>
>> Right. The OAI protocol has the verb "GetRecord" to assist
>> downloading
>> of one record addressed by its IdNumber. Every OAI data provider has
>> to implement at least the oai_dc format for that purpose, some of
>> them also offer oai_marc. A Link to a record might then look like
>> this:
>>
>> http://www.biblio.tu-bs.de/db/katalog/oai.php?verb=GetRecord&identifier=573318972
>>
>> and the result ist coded in XML.
>> Might this be the "standard format" catalog users would feel
>> most comfortable with? Or something even simpler? But what?
>> Reference Manager (RIS)? Wrapped in what way, which encoding?
>> It can all be done with not much effort, tweaking the OAI scripts,
>> but I'm afraid there isn't the one or two formats and wrappings that
>> would make a large majority happy and able to use it.
>> And of course, the internal id number is not what the end-user will
>> have available to ask for a record. What else? ISBN doesn't cover
>> everything and isn't reliable enough.
>>
>> What, in other words, would be the basic specs and requirements for
>> this
>> very first step into the linked data scenario?
>>
>> B.Eversberg
>>
Received on Wed Mar 18 2009 - 16:15:27 EDT