Jangle approval poll
Ross Singer
I wanted to touch base with the 'state of the project' and see how
people feel about the direction Jangle is going in. Reply to the
items with the usual "+1", "0", "-1".
First off, we've basically given up the ROGUE '05 method. If
maintaining the spec schedule is important to people, we can revisit
it, but it's been set aside for the time being in the effort to get
things done.
To date, I've just been making design decisions as needs arise without
consulting the group as a whole. The idea was to get a strawman API
out there to then look at, see what works, what could be done better
and what's downright wrong.
The alternative would be to run design decisions by the Google Group
and get a quorum of yeas, nos or abstentions before making a decision.
So what we have basically is a choice between and democracy. Since
this is a *very* important attribute for defining a community, I'm
very interested in what people want the Jangle community to be.
Good intentions aside, putting a strawman out shapes the debate; it's
more effort to change an existing proposal (since perceptions will
have been colored with the prejudices and opinions put forth in the
proposal) than to have a dialogue with a clean slate. On the flip
side, cooperative decision making will inherently make the development
time longer.
An assumption to date has been that Jangle does not care about the
data it exposes and makes no mandates on record formats or even the
kind of data that might appear in a given entity. For example, an
ILS, for the Resources entity, could return bib records, reserves
records and authorities.
Instead, these would be handled via a system of community profiles or
best practices. And ILS implementation, for example, may have
different definitions and expectations than an interlibrary loan
system.
The Collections entities have no inherent meaning. They are just
groups of things. In the above scenario (where an ILS exposes bib
records and authorities at /resources/), an option would be to create
a collection of bib records and you could then publish that URI to
retrieve your bib records (for, say, an OAI-PMH provider). Ditto for
authorities.
So far, the Event entity is being ignored as too complicated.
A SKOS vocabulary (or something similar) should be created to help
define and agree upon terms, esp. the token used to request specific
record formats or specialized jargon such as "hold", "recall", etc.
The latter would probably be more important when we move beyond mere
GET requests.
The JSON serialization from the connector to the core is almost a 1:1
JSON serialization of the Atom feed. A few other keys are sent as
well, such as the mime-type the Jangle core should send.
Right now only REST is supported for the Jangle connectors. Other
recommendations welcome (including a machine actionable way for the
Jangle core to know how to communicate with the connector for each
action).
I'll leave it at that for now and see how the public opinion stands.
Thanks, everybody.
-Ross.
Peter Murray
Hash: SHA1
On Jul 11, 2008, at 10:27 AM, Ross Singer wrote:
> First off, we've basically given up the ROGUE '05 method.
+1 -- okay by me at this point. I can't devote enough brain cycles in
concentrated blocks at this point to effectively help with a 30-day
deadline.
> To date, I've just been making design decisions as needs arise without
> consulting the group as a whole. The idea was to get a strawman API
> out there to then look at, see what works, what could be done better
> and what's downright wrong.
+1
> The alternative would be to run design decisions by the Google Group
> and get a quorum of yeas, nos or abstentions before making a decision.
- -1 -- see first comment.
> An assumption to date has been that Jangle does not care about the
> data it exposes and makes no mandates on record formats or even the
> kind of data that might appear in a given entity.
0 -- I'm finding the current discussion about what gets put into an
atom:entry very interesting, and I hope it continues. In general, I'm
leaning towards XML-only in an atom:entry, but the notion of putting
other stuff there is intriguing.
> A SKOS vocabulary (or something similar) should be created to help
> define and agree upon terms, esp. the token used to request specific
> record formats or specialized jargon such as "hold", "recall", etc.
> The latter would probably be more important when we move beyond mere
> GET requests.
+1
> I'll leave it at that for now and see how the public opinion stands.
All other questions and issues are "0" with no additional commentary
due to previously mentioned lack of brain cycles.
Peter
- --
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, New Service Development tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFId3bP4+t4qSfPIHIRAvmLAJ4oFS0Zz2woqtF3gSiRYd3iA0B48ACfT7gb
NUhOQWVs33p48V/fHY4jBl4=
=AKjI
-----END PGP SIGNATURE-----
Godmar Back
On Fri, Jul 11, 2008 at 10:27 AM, Ross Singer <rossf...@gmail.com> wrote:
>
> An assumption to date has been that Jangle does not care about the
> data it exposes and makes no mandates on record formats or even the
> kind of data that might appear in a given entity. For example, an
> ILS, for the Resources entity, could return bib records, reserves
> records and authorities.
>
I think it should care more, and it should set explicitly a standard
for what a system like it should return for specific operations, both
in terms of
- query form and syntax
- transport/container format for records
- individual records.
BTW, don't confuse "setting a standard" with "must mandate" or even
"limit" -- mandate minimum functionality, and mandate that data is
returned in at least one standardized format. Obviously, it can
return more.
If you're agnostic about what you're returning, you're essentially
meaningless. That's why unapi didn't take off, and that's why Z39.50
(for all its shortcomings) is in actual use.
- Godmar
Ross Singer
> If you're agnostic about what you're returning, you're essentially
> meaningless. That's why unapi didn't take off, and that's why Z39.50
> (for all its shortcomings) is in actual use.
>
What does Z39.50 specify that must be returned?
It can return anything.
-Ross.
Godmar Back
I don't know what it specifies as per the actual standard - so I
opened my mouth too wide here, probably - but in practice, for
instance, I set up Endnote to point at any Z39.50 server (or yazproxy,
for that matter), and requests records in (what I believe is) MARC
format. And I appear to get those records with the information I need.
This wouldn't work were it not for agreements or conventions about
what a typical library's Z39.50 server returns.
- Godmar
Ross Singer
The reason why you can get marc (although, of course, that MARC may
vary from systems to system: MARC8, MARC21, DAN-MARC, FIN-MARC, etc.)
from library catalogs, is because your asking library catalogs for
data.
If you were asking citation databases, you'd find it to be very
different. There's some MARC. There's some SUTRS. GRS-1. OPAC.
Some have other stuff (Summary records). You never really know what
you might get. There's GIS data in some Z39.50 servers.
But, because we want ILSes to behave similarly, they generally produce MARC.
And that's where my community profile suggestion comes in. ILSes
share the same community profile. ERMS might have another. Link
resolvers perhaps another. There will probably be overlaps. But I
don't think every shaped peg can fit in a round hole.
So I don't think Jangle should try to make them. Just like Z39.50
doesn't (SRU doesn't either), or OpenURL.
So, yes, I agree that there should be some guidelines to how Jangle is
used on types of services, but "Jangle" isn't setting it. The
community profile is. It may be a little pedantic, but I think
there's a difference. If the community profile is detached from
Jangle, it can applied to non-Jangle things (like the ILS-DI, for
example).
-Ross.
Godmar Back
>
> So, yes, I agree that there should be some guidelines to how Jangle is
> used on types of services, but "Jangle" isn't setting it. The
> community profile is. It may be a little pedantic, but I think
> there's a difference. If the community profile is detached from
> Jangle, it can applied to non-Jangle things (like the ILS-DI, for
> example).
>
In my view, let's get task 1 done, which is provide a standard service
for extracting ILS data. ILS-DI have made a good start with their
spec; let Jangle fill in the missing details and implement it, let
others implement it.
Later, somebody - may the ILS-DI people - can think up a name. Maybe
they'll call it the Jangle community profile.
- Godmar
Ross Singer
make sure is real.
*Is* task 1 getting data out of an ILS? Or is task one designing an
API that allows us to disintegrate the ILS a bit?
Why would developing a community profile for ILSes, concurrently with
the development of Jangle, be a problem?
My nightmare scenario is reading somewhere "Jangle is that project by
Ross Singer of Talis to get data out of ILSes."
-Ross.
On 7/11/08, Godmar Back <god...@gmail.com> wrote:
>
Godmar Back
and implement a more general framework at all, as long as there's
progress towards more concrete goals along the way.
- Godmar
Ross Singer
to be useless, either. So if it's going to be an extensible
framework, working constraints need to be considered as we're building
the spec.
Can we get some +1s, 0s or -1s to a draft of expected behavior for an ILS?
I, for one, throw in a +1.