One of the points I made in my Jangle presentation was the necessity
to create some Jangle connectors *outside* the ILS/OPAC to demonstrate
how the entities might be used completely differently in a different
context.

I chose to try this in Reserves Direct
(http://www.reservesdirect.org/) for a couple of reasons:
1. A project I'm involved with at Talis is fairly similar to it and
could benefit from design decisions made for modeling course reserves
2. Reserves Direct is fairly mature and open source (although with its
own OSS license, seemingly); I can run it locally and hack on it
3. The internal data model is fairly consistent with other products in
the domain
4. Course reserves are probably one of the more important "library
integration" services for external applications, like courseware.
5. I helped write the original version and participated in the design
of the current version, so am pretty familiar with it

This, like all of the other connectors to date, is written primarily
as a proof-of-concept to get a grip on the data model.  It could
probably work as a production service (with slight modification), but
that's more of an exercise of a Reserves Direct user, I think.

Anyway, on to how Jangle applies to this.

First off, a rough sketch of how "reserves" are modeled in Reserves Direct:

There are two critical relationships in Reserves Direct:
1. How reserved items relate to courses
2. How courses relate to people

Internally, RD has a lot of granularity around the notion of 'courses'
(since there are crosslistings and aliases and sections of the same
'course', etc.), which Jangle is sort of hand-waving around at the
moment, but for simplicity's sake, RD breaks course reserves into:
1. Users - this includes instructors, teaching assistants, students, staff, etc.
2. Course names, crossreferences and aliases
3. Specific instantiations of a course (i.e. HISTORY 100 -
Introduction to Western Civilization section 4 taught by Joe Schmoe -
Spring Semester 2009)
4. Roles of users to a specific course - user X is an instructor,
users A, B and C are students, etc.
5. Departments that courses fall under
6. Libraries that serve departments
7. Items, section headings and notes about items
8. Association of items and headings to specific course instances

With slight variations, I think the same could generally be said of
Syrup, ERes, ARes and Talis's Aspire (which is, technically speaking,
a 'reading list manager', but I think the argument could be made that
it shares pretty much all of the above attributes).

Jangle, for the uninitiated, divides any given service into four
distinct resource 'types' or 'entities':
1. Actors
2. Collections
3. Items
4. Resources

Where 'Resources' are the primary 'asset' of the given service,
'Items' are specific manifestations of things, 'Actors' are users or
account holders of a given system and 'Collections' are aggregations
of other entities.  It then provides an API to these resources using
the Atom Publishing Protocol.  Jangle also has a 'connector API' that
translates the business logic of a particular system as JSON objects
for a Jangle core to serialize as Atom documents.

A straw proposal I'm making for how to map those to reserves is this:

Actors are Users (this is pretty uncontroversial, I hope).  "Role" can
be expressed through Atom categories.
Atom:
http://demo.jangle.org/reserves/actors/
http://demo.jangle.org/reserves/actors/-/student/
The connector responses:
http://reservesdirect.jangle.org/jangle/actors/
http://reservesdirect.jangle.org/jangle/actors/-/student/

Collections are academic departments.  In the RD prototype, I have
included a category for 'library that is serving the department'.
Atom:
http://demo.jangle.org/reserves/collections/
http://demo.jangle.org/reserves/collections/-/LC/
The connector responses:
http://reservesdirect.jangle.org/jangle/collections/
http://reservesdirect.jangle.org/jangle/collections/-/LC/

Resources are 'course instances' -- i.e. actually scheduled courses.
Atom:
http://demo.jangle.org/reserves/resources/
http://demo.jangle.org/reserves/resources/-/111th_2009/
The connector responses:
http://reservesdirect.jangle.org/jangle/resources/
http://reservesdirect.jangle.org/jangle/resources/-/111th_2009/

Items are the actual reserves or headings themselves:
Atom:
http://demo.jangle.org/reserves/items/
http://demo.jangle.org/reserves/items/-/ITEM/
The connector responses:
http://reservesdirect.jangle.org/jangle/items/
http://reservesdirect.jangle.org/jangle/items/-/ITEM/

What's significant about this data model is that the actual 'things'
themselves (a scanned book chapter, link to Proquest, copy held at
reserves desk, etc.) are not represented except via a link
relationship with the Item entity.  My personal opinion is that this
is a more versatile approach since the 'holdings' of a reserves system
are generally widely distributed among some sort of PDF archive, web
links and circulating copies of things.  There is no reason why the
link relationship couldn't be to another Jangled system.

The relationship between entities are like this:
Actors have and belong to many Resources (and the role is expressed as
an Atom category):
http://demo.jangle.org/reserves/actors/317/resources
http://reservesdirect.jangle.org/jangle/actors/317/resources
The inverse is also true:
http://demo.jangle.org/reserves/resources/7/actors
http://reservesdirect.jangle.org/jangle/resources/7/actors

Actors may also have many Items (this would be, say, a faculty member
putting their personal copy of something on reserve):
http://demo.jangle.org/reserves/actors/317/items
http://reservesdirect.jangle.org/jangle/actors/317/items

Conversely, an Item may belong to one Actor:
http://demo.jangle.org/reserves/items/92/actors
http://reservesdirect.jangle.org/jangle/items/92/actors

Collections (departments) can have many Resources (courses):
http://demo.jangle.org/collections/15/resources
http://reservesdirect.jangle.org/jangle/collections/15/resources

and Resources can belong to one Collection:
http://demo.jangle.org/resources/66/collection
http://reservesdirect.jangle.org/jangle/resources/66/collection

Resources and Items are a has and belongs to many relationship:
http://demo.jangle.org/reserves/resources/7/items
http://reservesdirect.jangle.org/jangle/resources/7/items

http://demo.jangle.org/reserves/items/22/resources/
http://reservesdirect.jangle.org/jangle/items/22/resources/

Anyway, I realize that's a lot to look at.  I CC'ed in the people that
are working on these reserves system to get their take on the
translation of the data model to Jangle.  I'd be interested in any
feedback, and, "uh... what?" is a perfectly reasonable response.