Drafting of draft spec happening on jangle.org
Ross Singer
I just wanted to let you that I'm writing the draft spec docs on the
Jangle site. I hope to have them done by Wednesday, but if you want
to follow the progress, check out:
http://jangle.org/drupal/1_0rev1spec
Btw, Tod, the answer to your question about the difference between
Items and Resources is here:
http://jangle.org/drupal/1_0rev1spec/entities_and_uris
If that *doesn't* help you out, let me know, so I can rewrite that
page in some more understandable way.
-Ross.
Tod Matola
3) I think you may need examples of collections.
Ross Singer
On Tue, Sep 30, 2008 at 12:26 AM, Tod Matola <todm...@gmail.com> wrote:
> Hmm. Well I guess I see what you want but not sure that gets it.
> Couple questions:
> 1) How would you indicate multiple copies of single item. Or multiple
> editions of the same items.
Well, again, this is the relationship between Resources and Items. So
you would never have multiple copies of a single items. They would
all be distinct items associated with a single resource.
Multiple editions of the same resource could only be expressed if that
association exists in the underlying data. Which, as we know, is very
seldomly the case with library data.
Ultimately, *this* is what Jangle does. Expose the data, but not
really *enhance* it. The role of adapters is to be able to take the
data and make the more sophisticated relationships between things.
> 2) What is the classification scheme of id's of items (or maybe resources)?
> For example: ISSN, ISBN, LC, OCLC, local, jangle, dewey?
This is a local decision: the URI is build from some sort of local
identifier. In the OpenBiblio connector it's based on the barcode, in
the TalisLMS it's based on the ItemID. In theory, you could search
on the other identifier types.
> 3) I think you may need examples of collections.
Yeah, good point.
> BTW this is a pretty hard problem, people have debated this stuff for years,
> keep plugg'n
Thanks :) Again, it's difficult to explain Jangle's purpose and
scope. I think people are so desperate for a universal API that they
are going to be underwhelmed by what Jangle is designed to do, which
is merely to make your data readable/writable in the simplest way
possible.
The idea is that once we have consistent access to the data, we can
begin making more sophisticated interfaces.
-Ross.
Tod Matola
Ah, yes. Some of these are out of scope for Jangle. Comments inline:
Well, again, this is the relationship between Resources and Items. So
On Tue, Sep 30, 2008 at 12:26 AM, Tod Matola <todm...@gmail.com> wrote:
> Hmm. Well I guess I see what you want but not sure that gets it.
> Couple questions:
> 1) How would you indicate multiple copies of single item. Or multiple
> editions of the same items.
you would never have multiple copies of a single items. They would
all be distinct items associated with a single resource.
Multiple editions of the same resource could only be expressed if that
association exists in the underlying data. Which, as we know, is very
seldomly the case with library data.
Ultimately, *this* is what Jangle does. Expose the data, but not
really *enhance* it. The role of adapters is to be able to take the
data and make the more sophisticated relationships between things.
This is a local decision: the URI is build from some sort of local
> 2) What is the classification scheme of id's of items (or maybe resources)?
> For example: ISSN, ISBN, LC, OCLC, local, jangle, dewey?
identifier. In the OpenBiblio connector it's based on the barcode, in
the TalisLMS it's based on the ItemID. In theory, you could search
on the other identifier types.
Yeah, good point.
> 3) I think you may need examples of collections.
> BTW this is a pretty hard problem, people have debated this stuff for years,Thanks :) Again, it's difficult to explain Jangle's purpose and
> keep plugg'n
scope. I think people are so desperate for a universal API that they
are going to be underwhelmed by what Jangle is designed to do, which
is merely to make your data readable/writable in the simplest way
possible.
The idea is that once we have consistent access to the data, we can
begin making more sophisticated interfaces.
Tod Matola
http://litablog.org/2007/12/07/another-iso-standard-bibliographic-data-element-directory/
and
http://iso8459.oclc.org/
More grist for the mill.
Cheers Tod.
Ross Singer
> Let's keep going I think I'm getting closer. See inline
> Cheers Tod.
>
> On Tue, Sep 30, 2008 at 7:12 AM, Ross Singer <rossf...@gmail.com> wrote:
>>
>> Ah, yes. Some of these are out of scope for Jangle. Comments inline:
>
> By out of scope you mean the domain of the adapter?
Possibly, yes. It's also plausible that it's in the domain of Jangle,
but I think I'd need to see an example.
>
>>
>> On Tue, Sep 30, 2008 at 12:26 AM, Tod Matola <todm...@gmail.com> wrote:
>> > Hmm. Well I guess I see what you want but not sure that gets it.
>> > Couple questions:
>> > 1) How would you indicate multiple copies of single item. Or multiple
>> > editions of the same items.
>>
>> Well, again, this is the relationship between Resources and Items. So
>> you would never have multiple copies of a single items. They would
>> all be distinct items associated with a single resource.
>>
>> Multiple editions of the same resource could only be expressed if that
>> association exists in the underlying data. Which, as we know, is very
>> seldomly the case with library data.
>>
>> Ultimately, *this* is what Jangle does. Expose the data, but not
>> really *enhance* it. The role of adapters is to be able to take the
>> data and make the more sophisticated relationships between things.
>
> I think you said this, but in your doc you may want to be specific (or maybe
> it was me that tried to draw the linkage). The resource is more a kin to the
> Bibliographic citation (e.g., the MARC representation) or is it a higher
> level construct. Typically the BIB details and circulation info
> are separate records and modeled together like in the Z39.50 OPAC record
> syntax. Is a resource a blur on both models?
Well, you're right. Resource would be a MARC record.
Item, in OPAC syntax breaks down the data model a bit. This is true
of almost every metadata format I've found that contains item
information: ISO20775, NCIP, OPAC, etc.
So, realistically, this means an OPAC record or an ISO20775 document
could really only be created through an adapter (I guess), although I
guess there's hacking around that could be done:
1) You could make the claim that if you are requesting an Item in OPAC
format (or, conversely, a Resource) it would inherently include the
bib or item information in the response because that's what the
metadata format call for. This breaks down the Entity model, but I
don't feel like I need to cling to it dogmatically.
2) You could send as much of the respective metadata formats as you
have and leave it to the client to figure out how to merge them. So
for an NCIP document,
http://example.org/service/items/01234?format=ncip would send just the
elements that pertain to Item level information in an NCIP response
and links to the Resource and Actor that are relevant to the request.
Requests to each of these would provide the rest of the elements.
This, of course, seems a little like madness. However, one way this
*could* work is by providing a stylesheet that basically does this
work for the client, so the stylesheet has the URIs of the actor and
the resource and could build an appropriately validating XML document
from the various resources. The URI is still really only providing
data about resource explicitly requested, though.
3) Jangle (or, rather, a side-effort of people trying to either make
Jangle more useful or are engaged in other Jangle like initiatives
that could use a similar outcome) could create (or adopt) schemas that
symbolize the superset of everything that is embodied in a given
entity (for a particular community profile) and output and allow
clients to transform *that* into something standard or useful to them.
This idea was originally part of Jangle (sort of 'platonic
responses'), but it seemed a sure fire way to get nothing accomplished
fast. For one thing, getting agreement on what the superset might be
would difficult (and, really, is what's wrong with formats like NCIP).
If this route is chosen, it makes more sense to figure out what the
cowpath is first, rather than build a model according to how we think
people might want to use it. At least, that's my opinion.
Of these options, I actually think I might like #2 the best.
>
>>
>> > 2) What is the classification scheme of id's of items (or maybe
>> > resources)?
>> > For example: ISSN, ISBN, LC, OCLC, local, jangle, dewey?
>> This is a local decision: the URI is build from some sort of local
>> identifier. In the OpenBiblio connector it's based on the barcode, in
>> the TalisLMS it's based on the ItemID. In theory, you could search
>> on the other identifier types.
>
> In practice this a requirement (searching on other identifiers). I think all
> the big API (Google Books, Amazon,...) take multiple classifications and
> gravitate to the ones that get the largest coverage.
> IMHO support for at least ISSN/ISBN should be a first class citizen in the
> spec. Well unless you expect that to be a job of the consumer to know where
> in the resource to dereference multiple identifiers.
>
> This is a real problem if you are trying to aggregate resources (as in
> jangle) from multiple sources if they don't have a consistent identifier
> (comparison/equality would be impossible).
I don't disagree with this and completely open to suggestion here.
The reason it *doesn't* support this is that:
1) ISSNs and ISBNs, etc. don't necessarily equate to an individual
resource. It's *quite* likely that two records might have the same
ISSN (since many libraries have different records for print and
electronic journals).
2) I have a hard time wrapping my head around what the URIs for this
functionality would look like
3) It seems achievable by
http://example.org/service/resources/search?query=bath.issn=1234-5678
or http://example.org/service/resources/search?query=dc.identifier=1234-5678
or to be completely unambiguous (although color me shocked if anybody
does this): http://example.org/service/resources/search?query=dc.identifier=/bib.identifierAuthority=issn
1234-5678
I tend to lean towards the last point as the answer to this, but like
I said, I'm open to anything.
-Ross.