jangle.org

So you have a service that you like to set up a Jangle API for. You look at the spec. You skim the mailing list. Perhaps you check out some of the frameworks from the Google Code site. Unfortunately, despite the Jangle community's best intentions you probably only see this:

1. Find a library-domain application.
2. ???
3. Jangle!!!

As I mentioned previously, the primary use case for Jangle at this stage is discovery systems. Not that it wouldn't be useful for other kinds of applications, but the lack of specification around Create, Update or Delete limit the immediate usefulness in certain situations. Also, the OPAC replacement is not only an immediate need for many libraries, it's also a pretty good demonstration of much of Jangle's functionality.

Now that the Jangle spec has been released, I've been looking for small, simple projects to show off how easy Jangle makes it to incorporate into your applications. The general approach to the projects I have chosen for the proofs-of-concept for Jangle have been to target applications that get the point across but don't require a ton of overhead on my part to either get running or keep running.

On Halloween, I had the privilege of being the guest for the return of Dan Chudnov's podcast series, Library Geeks.

It's long. Really long. And kind of messy.

But it's chock full of Jangle information and Dan leads some very good questions that get at the heart of how Jangle can be used to very easily provide library data integration into local development projects.

Anyway, it was great to be back on Library Geeks and to talk to Dan.

The Jangle Vocabulary is intended to provide unambiguous identifiers and definitions to provide pointers to Jangle implementers and developers to understand what data is being provided by a Jangle service.

Record formats registry (http://jangle.org/vocab/formats#)

Entity registry (http://jangle.org/vocab/Entity#)

Registry of other URIs, for use in categories, etc. (http://jangle.org/vocab/terms#)

This registry is intended to help define authoritative identifiers for negotiating requests for specific metadata types in standards such as Jangle or unAPI.

The identifiers themselves arbitrary; while consistency is helpful, it's not mandated.  Also using a term that makes sense for a given format (such as the explicit mime-type or namespace) will be more intuitive.  The important part is to have agreement on exactly what a given identifier stands for.

HOWTO build a Jangle connector

Note, everything here is negotiable.  If you have a better idea for anything, please provide comments!

All GET requests should return a JSON object with the following keys:

time, string
UTC timestamp of request

request, string
returns the path and query string of the incoming request,

data, array
an array of objects,

While the simpler of the two architectural components (core and connector), the Jangle core has the distinction of being public face of Jangle and therefore the only part of Jangle that most people should ever have to see.

The core, in essence, is an Atom Publishing Protocol proxy to the registered backend connectors. It routes the HTTP requests to the connectors, and serializes the JSON responses to Atom feeds.