Rough proof-of-concept Jangle Connector for Reserves Direct
Ross Singer
important to you, you might just want to skip it.
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.
Thanks!
-Ross.
Emily Lynema
-emily
Ross Singer
strictly limited to the reserves domain (although I think this is the
first compelling example of it).
The only current barrier to this sort of request is that the
frameworks don't have the capacity to respond to it.
What, exactly, is the intended response from this? All the reserves
associated with any course associated with an actor? i.e.
/actors/1234/resources/items ?
Or is there the expectation that a particular course ID would be
included in the mix?
/actors/1234/resources/4321/items ?
The former is going to require a lot of rethinking of how routes work
in Jangle. This throws some variance in the URL patterns that will
make processing them somewhat more complicated (since at any resource
you could be requesting an ID, IDs, category or, with this,
relationship).
The latter is certainly doable. In the case of ResDirect (and
Aspire), it obviously gives the connector the option of adding a
"hidden" category, as well.
I'm not sure I have any objections to this on the surface, and, of
course, this sort of request is completely at the discretion of the
connector developer.
The questions I have at this point, I guess, are:
* What jangle:relationship URIs are returned from /actors/1234/resources/4321?
or, for that matter:
* What relationship URIs are returned from /actors/1234/resources/ ?
Do we need URIs to both the possibly filtered or adulterated
actors-related resources (and items) and the original?
* /actors/1234/resources/4321, /actors/1234/resources/4322, etc.
and
* /resources/4321, /resources/4322 # This being the way Jangle currently works
Perhaps the recent link rel="canonical" relationship would work here?
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
This isn't a valid relation in Atom, so we'd have to mint a rel URI
like we do for alternate formats, something like
http://jangle.org/vocab/rel#canonical
What do people think? Like I mentioned earlier, this has value
outside of the course reserves context.
Do we want to include this functionality in 1.1?
-Ross.
artr...@uwindsor.ca
>What, exactly, is the intended response from this? All the reserves
>associated with any course associated with an actor? i.e.
>/actors/1234/resources/items ?
>
>Or is there the expectation that a particular course ID would be
>included in the mix?
>
>/actors/1234/resources/4321/items ?
In Ontario, folks can get really touchy about displaying IDs that map to a student. Would it be out of line to use a URI like "actors/student/resources/4321/items" and have an authentication layer sort out identity?
Castor, an xml framework that long ago fell out of the limelight, used to have this wonderful slogan that it's purpose was to be "the shortest path from here to there". It's very cool how Jangle seems to follow this philosophy so well.
art
Ross Singer
> In Ontario, folks can get really touchy about displaying IDs that map to a
> student. Would it be out of line to use a URI like
> "actors/student/resources/4321/items" and have an authentication layer sort
> out identity?
This seems inordinately complicated to me. Besides, at some point
you're going to need systems that are able to authoritatively
correlate user accounts between systems, won't you? How would, say,
courseware be able to present to an instructor, the current roll of
his or her class?
No matter what, I think there needs to be a stub of an ID there.
There are a couple ways, I guess, this could work. One possibility
would be to contrive a 'dummy' identifier, something like:
/actors/____/ (or any string that you're not afraid of namespace
collisions) that sets off the authentication mechanism.
Another possibility would be a mechanism to set up a salt between the
client and server and hash the IDs. I'm not sure how complicated this
is, though, or if it just moves the same problem to a different
location.
To get a better understanding here, the danger is exposing that actor
X is enrolled in course Y?
So it seems like /actors/1234/resources is "ok", but
/actors/1234/resources/4321/items is "not ok", is that right?
The problems with the authentication method that I can see are:
1) how does a 'authorized' third party (such as an internal harvester
for another application or something) manage this?
2) how do you request multiple actors: /actors/1234,1235/resources/4321?
These are good ideas, though, keep 'em coming.
>
> Castor, an xml framework that long ago fell out of the limelight, used to
Well, thanks Art, I think we now have Jangle's new slogan:
"Jangle, like an xml framework that long ago fell out of the limelight"
-Ross.
artr...@uwindsor.ca
> To get a better understanding here, the danger is exposing that actor
> X is enrolled in course Y?
> "Jangle, like an xml framework that long ago fell out of the limelight"
art
Graham Fawcett
On Tue, Mar 17, 2009 at 4:50 PM, <artr...@uwindsor.ca> wrote:
>
>> To get a better understanding here, the danger is exposing that actor
>> X is enrolled in course Y?
>
> Yes, but I am no expert on our new privacy laws and I might be wrong about
> this.
I'm not an expert either, but I would agree that publishing 'X is
enrolled in Y' would be a concern, at least at our institution.
From the little I've read about Jangle, it's just Atom, and so it
seems to me that protection can happen at the HTTP layer: Simply
forbid access (403) to anyone who shouldn't have access to the 'X in
Y' information. Upgrade sensitive URLs to TLS to add some extra
tinfoil (if that doesn't cause an interop nightmare). So,
/actors/NNN(.*) and /resources/NNN/actors could be on a
need-to-resolve basis: you can know the URL but not the contents.
Isn't all of this stuff need-to-know anyway? For reserves, wouldn't an
institution be more interested in interop between reserves and, say,
an LMS or a portal? Would you really share these data with everyone?
(I'm new here, be patient if that's short-sighted. :-)
Re: salting and hashing userids -- I get the idea, but don't see the
specific application. The URLs themselves don't appear to contain
userids, rather you have numeric identifiers for users. Presumably
there's a search facility that could resolve userids to /actors/NNN/
URLs? And that facility could be protected at the HTTP level? If my
identifier in the Jangle interface is my /actors/NNN/ URL, I can't
imagine the privacy police being too upset (as long as the wrong
people couldn't resolve it and get at my personal details).
But maybe I'm reading too much into the example. Were you planning on
/actors/<userid>/ and using numbers as examples of userids?
(Either way, salting/hashing smells like security at the wrong level,
IMHO. Use the transport protocol, Luke.)
Oh, one other thing. In Syrup, we've allowed for nested headings of
arbitrary depth. I'm not sure we're going to keep them, but if we do,
it would be nice to be able to model this properly in a Jangle
connector.
>> "Jangle, like an xml framework that long ago fell out of the limelight"
I sort of like it, actually. Makes me wonder what it fell *into*. :-)
best,
Graham
Walker, David
> fell out of the limelight"
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: jangle-...@googlegroups.com [jangle-...@googlegroups.com] On Behalf Of Graham Fawcett [graham....@gmail.com]
Sent: Tuesday, March 17, 2009 4:40 PM
To: jangle-...@googlegroups.com
Cc: chris....@talis.com; Graham Fawcett; Jason White; Mauric...@ncsu.edu; Nadeem...@talis.com; Art Rhyno; rossf...@gmail.com
Subject: [jangle-discuss] Re: Rough proof-of-concept Jangle Connector for Reserves Direct
Ross Singer
"/actors/1234" is an arbitrary identifier, local to, say, Syrup. So
the primary key that identifies gfaw...@windsor.ca in Syrup's users
and user_profiles tables would be the identifier here. There would
probably be a search mechanism to be able to find this identifier,
but, yes, it makes sense to protect this with auth/authz.
This is how the connector for Talis Alto (our ILS) works. If you
request /actors/ or any subdirectory of /actors/ you'll get a 401.
The options are to pass an administrative account to get 'anything' or
your personal credentials where you can only get you. If you request
/actors/ there will only be one result. If you request an ID that
isn't you, you'll get a 403.
I suppose the danger here is an unauthorized caching and reuse of
legitimate client requests.
I am in the course management system, I request my reserves (and other
things) which starts the process by resolving who I am (which grabs my
personal information in a vcard or a foaf).
Since, I, the user, is not interacting with Jangle directly, there is
a level of trust that the agent isn't doing something untoward with
this data. At this point we *do* have a URI that associates a person
to their identity.
My preference is to still leave this *out of the spec* (e.g. leave it
as an exercise of the implementer). I think hashing out a way to
reconcile this issue and including this solution in the reference
implementations (as well as documenting it explicitly) is imperative,
however.
Basically, I don't want to see Jangle fall out of favor because some
early implementations exposed delicate data insecurely and it was
easier to abandon it than solve the problem.
I want Jangle to fall out of favor because it closely resembles some
Java XML parser that nobody uses anymore.
-Ross.
Graham Fawcett
On Tue, Mar 17, 2009 at 11:11 PM, Ross Singer <rossf...@gmail.com> wrote:
> Graham, you're right on target when it comes to Jangle's use of URIs.
> "/actors/1234" is an arbitrary identifier, local to, say, Syrup. So
> the primary key that identifies gfaw...@windsor.ca in Syrup's users
> and user_profiles tables would be the identifier here. There would
> probably be a search mechanism to be able to find this identifier,
> but, yes, it makes sense to protect this with auth/authz.
>
> This is how the connector for Talis Alto (our ILS) works. If you
> request /actors/ or any subdirectory of /actors/ you'll get a 401.
> The options are to pass an administrative account to get 'anything' or
> your personal credentials where you can only get you. If you request
> /actors/ there will only be one result. If you request an ID that
> isn't you, you'll get a 403.
Great -- no wheel-reinvention here. :-)
> I suppose the danger here is an unauthorized caching and reuse of
> legitimate client requests.
> I am in the course management system, I request my reserves (and other
> things) which starts the process by resolving who I am (which grabs my
> personal information in a vcard or a foaf).
Side note: vCard or FOAF? Is there a reason not to pick one? I'm just
curious why you'd spec out the transfer protocol, but not the
payload. Separation of concerns is all good, but if I was writing
a Jangle stack I'd hope for clear answers from top to bottom, if
you know what I mean.
In our case (Syrup), we really don't have much user information
to share anyway -- in some cases, it might be just (userid,
given, surname, email) or even just (userid) in the pathological
case!
> Since, I, the user, is not interacting with Jangle directly, there is
> a level of trust that the agent isn't doing something untoward with
> this data. At this point we *do* have a URI that associates a person
> to their identity.
That's fair, I think. That's a level of trust that the LMS would
uphold with several other data-sources (its own database, notably,
which is a hodgepodge of other people's sensitive stuff). I don't
think Jangle would need to be held to a higher standard.
> My preference is to still leave this *out of the spec* (e.g. leave
> it as an exercise of the implementer). I think hashing out a way to
> reconcile this issue and including this solution in the reference
> implementations (as well as documenting it explicitly) is
> imperative, however.
In the Reserves context, are you thinking of exporting "content" from
Reserves (e.g. PDFs and other documents) through APP? Or just
publishing URLs pointing to those documents in the Reserves system? I'm
thinking you mean the former, and that's why the security concerns are
important, right?. (In contrast, a list-of-links doesn't seem worth
protecting, really.)
Is there any notion in Jangle of a "lease" or a "guest pass"? E.g.,
here's a URL for my course-items, it has "full-read" access, and
expires in thirteen weeks? The read-permissions are confined to the
single course, and don't allow a user to 'escalate' access in other
sites? The point is that part of the authorization-decision could be
made by the Reserves user, inside the reserves system. A "lease"
doesn't map directly onto any of the APP components, though it could
be concieved as a sort-of course-like thing.
> Basically, I don't want to see Jangle fall out of favor because some
> early implementations exposed delicate data insecurely and it was
> easier to abandon it than solve the problem. I want Jangle to fall
> out of favor because it closely resembles some Java XML parser that
> nobody uses anymore.
Aim for the stars. ;-)
Best,
Graham