Progress report
Ross Singer
Ok, my connectivity woes should be mostly resolved. Thankfully, since
my development can occur on localhost, I've been able to really start
refining a proof-of-concept for how Jangle might work.
Keep in mind that I'm not prescribing or even recommending anything
that's about to follow. I've just been trying to get *something* to
work and working out the pitfalls and making some off-the-cuff
decisions on how to circumnavigate them. I'm open to any and all
suggestions, changes and criticism :)
In my radio silence, I've migrated the OpenBiblio connector from the
Camping microframework [1] to the Sinatra framework [2]. Sinatra is
much better at both handling REST as well as more sophisticated
resource routing based on request URIs. My camping script was
starting to confuse even myself, and Sinatra will make a much more
sane application.
For the time being, the Jangle core in SVN is still using the Merb
framework [3], but it's quite possible I may migrate that to Sinatra,
as well, since I think it will do everything core needs to do in a
much easier to parse package (after all, this is intended to be
something that somebody looks at and says, "Aha! I see what they're
doing." and not get bogged in the semantics of a framework, like Peter
already pointed out [4]).
So, some things I've included in the new versions:
1. Paging. This was pretty important since it wouldn't be unusual
for a large academic library to have several million "resource",
"actor" or "item" resources. It's using RFC 5005 [5] and is currently
utilizing what the spec calls "paged feeds", although I think
"archived feeds" might be a wiser long-term option, if only for how it
would make implementing most of OAI-PMH pretty simple.
Here's an example:
http://dilettantes.code4lib.org:6767/openbiblio/resources/
page 2: http://dilettantes.code4lib.org:6767/openbiblio/resources/?page=2
last page: http://dilettantes.code4lib.org:6767/openbiblio/resources/?page=60
(if you view the above in Firefox, you might have to view source to
see anything -- not sure why)
And here's how it looks from the connector:
http://dilettantes.code4lib.org:4567/resources/
page 2: http://dilettantes.code4lib.org:4567/resources/?page=2
last page: http://dilettantes.code4lib.org:4567/resources/?page=60
One thing you might notice from the connector output is that it's
returning relative URIs for things that should link back to Jangle.
It's quite probable that the connector will have no idea what its
absolute URIs should be (I suppose it's even possible that the
connector could be the target of multiple Jangle cores, and,
subsequently, have different absolute URIs), so it's important that
the Jangle core be able to turn these into appropriate Jangle absolute
URIs.
2. Links to alternate feeds. Here I'm throwing some spaghetti to the
wall and we'll see what sticks. If, from the above Atom feed links,
you look at an "entry" elements, you'll see:
<link rel="alternate" type="application/atom+xml"
href="http://localhost:4000/openbiblio/resources/701?record_format=dc"
/>
<link rel="alternate" type="application/atom+xml"
href="http://localhost:4000/openbiblio/resources/701?record_format=marc"
/>
<link rel="alternate" type="text/html"
href="http://dilettantes.code4lib.org/openbiblio/shared/biblio_view.php?bibid=701&tab=opac"
/>
<link rel="http://jangle.org/rel/alternate#http://purl.org/dc/elements/1.1/"
type="application/atom+xml"
href="http://localhost:4000/openbiblio/resources/701?record_format=dc"
/>
<link rel="http://jangle.org/rel/alternate#application/marc21"
type="application/atom+xml"
href="http://localhost:4000/openbiblio/resources/701?record_format=marc"
/>
or something similar. While the first three probably make sense (show
me this entry with DC, marc21 or html, although more on the html in a
minute), it's the last two that I'd like to run by the group. One of
the problems with Atom is that there's no standardized way to
explicitly request what kind of data you want the server to return in
the <content> tag. Content negotiation won't work for this, since
you're really requesting an application/atom+xml document. Of course,
it wouldn't work, anyway, because most library metadata standards
don't have unique mime types.
For any of you that were involved with the development of the unAPI
spec [6], this was the same criticism I had with it (basically, how do
you consistently label the fact that you have dublin core or marcxml
outputs?).
What the Atom spec allows is for you to set a URI for the rel
attribute on link tags [7], so I'm proposing the idea of a syntax
registry/vocabulary. It would borrow the semantics from Atom, the
first part of the namespace would be: http://jangle.org/rel/alternate
(or http://jangle.org/rel/related or http://jangle.org/rel/enclosure
or whatever) and then a defined identifier for a particular metadata
format. I don't personally care what it is (for instance, in the
above example, I've used a mime-type for marc21 and a namespace for
dublin core) as long as it's unique and well defined for an
implementor to know what it is and what to do with it.
I'm really interested in feedback/alternatives to this approach. Note
that I also duplicated these links as standard "alternate" links for
broader compatibility with Atom clients.
I still need to add these at the feed level.
3. Links to HTML representation. These don't actually resolve since
I'm only running the OpenBiblio database (and not the web UI) on my
server, but I think this solves the DLF API recommendation for
GoToBibliographicRequestPage (8.3.1) [8]
I don't currently have any holdings data in my "library" (since I've
just loaded the Gutenberg records), so my next goal is to do that and
begin fleshing out items and how they relate to resources and actors.
Also, I've ignored authentication thus far.
Anyway, those are some changes. I look forward to anything anybody
has to say on any of this.
Thanks!
-Ross.
[1] http://camping.rubyforge.org/
[2] http://www.sinatrarb.com/
[3] http://merbivore.com/
[4] http://groups.google.com/group/jangle-discuss/browse_thread/thread/d25fac2d4cdf6b2a#msg_7f99afce927a0c38
[5] http://www.ietf.org/rfc/rfc5005.txt
[6] http://unapi.info/
[7] http://atomenabled.org/developers/syndication/#link
[8] http://project.library.upenn.edu/confluence/download/attachments/5963787/DLF_ILS_Discovery-April08_draft.pdf