I've been a little quiet here, but it's not for a lack of attention
being paid to Jangle.
If you haven't seen the content added to http://jangle.org/ go on over
and check it out. I've put up a bunch of strawman documents for the
connector APIs (as well as some general Jangle prose). I also
proposed the concept of a "format registry", which goes beyond the
needs of Jangle.
Essentially it'd be like a SKOS classification to agree on kinds of
data formats we would be requesting and serving. This would be also
useful for unAPI, for example, since it's at the discretion of the
unAPI server how to say that a particular resource is available as
dublin core or marcxml or whatever. Jangle also has this need,
because there needs to be some way to request specific record formats
to return in the atom feeds.
In fact, instead of being *like* a SKOS classification, perhaps it
should just be one.
Also, I've been completely overhauling the existing openbiblio jangle
connector and refactoring it into a more generic connector framework
(still in Ruby, natch) with an OpenBiblio-specific "module". The goal
here is to make it easier to:
1. Let Equinox quickly make a simple Jangle connector once their Ruby
bindings to OpenSRF are done
2. Easily shoehorn Bill Dueber's JSON REST API for Aleph into Jangle
3. Make it easier for me to write a simple Jangle connector for Alto
with what's already there.
Again, this isn't meant to be Ruby specific... it's just what I write fastest :)
I have set a goal for myself to get to level 2 functionality for the
DLF ILS API (and preferably level 3) by the end of the month using the
existing Jangle stack. If there are Evergreen, Alto and Aleph
connectors (even if completely rudimentary) that gives us 4 ILSes that
meet some level of DLF compliance (I'm including OpenBiblio in there),
which is good for all parties involved.
One last point. I submitted an article proposal on Jangle to the
Code4lib journal today. If it's accepted, I would love to have some
collaborators on that.
Thanks!
-Ross.