navigating record URIs
Godmar Back
should we steal from Microsoft's Live API and adopt their conventions
with respect to how to construct URIs for feeds, items in a feed, and
how to follow referred resources within a feed?
Specifically, look at the table here:
http://dev.live.com/blogs/devlive/archive/2008/03/12/220.aspx
See also the example I gave here:
http://groups.google.com/group/jangle-discuss/msg/901e3ae6f297f815
We could drop the awkward availability?id=... then.
- Godmar
On Mon, Jun 30, 2008 at 5:24 PM, Ross Singer <rossf...@gmail.com> wrote:
>
> HarvestBibliographicRecords:
> Identify: http://dlf-api.jangle.org/openbiblio/OAI/bibliographic?verb=Identify
> ListMetadataFormats:
> http://dlf-api.jangle.org/openbiblio/OAI/bibliographic?verb=ListMetadataFormats
> ListRecords: http://dlf-api.jangle.org/openbiblio/OAI/bibliographic?verb=ListRecords&metadataPrefix=marcxml
>
> GetAvailability:
> http://dlf-api.jangle.org/availability/?id=http://demo.jangle.org/openbiblio/resources/5878+http://demo.jangle.org/openbiblio/items/000006418
>
> GoToBibliographicRequestPage:
> http://dlf-api.jangle.org/goto/?uri=http://demo.jangle.org/openbiblio/resources/5974
>
Ross Singer
idea why they are using them, really.
/Folders(123)/Photos(456)
It just seems like an unorthodox way to write:
/Folders/123/Photos/456
So to describe an item in a feed, why can't you just use the URI for that item?
I have a hard time picturing the use case of needing a URL to identify
the third entry in any given feed.
Now, the metadata thing (/Folders(123)/Photos(456)/$title)... that's slick.
-Ross.
Godmar Back
>
> Personally, I dislike MS's use of parentheses... In fact, I have no
> idea why they are using them, really.
>
I would have preferred [ ], too, but it's needed to distinguish
/Folders(123) from /Folders/123, which has a different meaning.
> I have a hard time picturing the use case of needing a URL to identify
> the third entry in any given feed.
>
The (3) doesn't mean the third entry, it means the entry with id 3.
> Now, the metadata thing (/Folders(123)/Photos(456)/$title)... that's slick.
... and it requires the ability to address individual entries, doesn't it?
- Godmar
Emily Lynema
Ross Singer
So, take http://demo.jangle.org/openbiblio/resources/5974
This is a URI based on the unique ID for that bibliographic record (in
this case, what would be used in the 001).
If the metadata shortcut thing was enabled in Jangle you could do:
http://demo.jangle.org/openbiblio/resources/5974/$title
and it would return:
"The New North"
What I don't understand about MS's implementation is, how do you get a
feed of all the Folders?
-Ross.
Ross Singer
Godmar Back
>
> You can address individual entries anyway. Jangle gives everything a URI.
>
> So, take http://demo.jangle.org/openbiblio/resources/5974
>
> This is a URI based on the unique ID for that bibliographic record (in
> this case, what would be used in the 001).
>
But that's something you would have to know a priori, rather than
something a client could infer.
It relies on Jangle's ids being URIs (or URI suffixes); the MS
proposal allows the creation of a URI if all you have is the Feed URL
and the ID without restricting the nature of the id and without
requiring this a priori knowledge of how to map an id to a URI.
- Godmar
Ross Singer
How did the client get /Folders(123) ? I guess I don't see the
difference between that and /openbiblio/resources/5974
-Ross.
Godmar Back
that is returned by /Folders.
In other words, there's a
<atom:link rel="related" title="123" href="..../Folders/123" />
in the original document.
- Godmar
Godmar Back
- Godmar
Emily Lynema
-emily
Ross Singer
-Ross.
Godmar Back
More seriously though, we had originally considered it a design
requirement that getavailability handle more than one item at once.
That's why they added it, I suppose. And it makes sense for the
"discovery system" frontends.
- Godmar
Ross Singer
reference implementation (which needs a name, Rangle?) allows for
multiple identifiers at once, either comma or semicolon separated.
http://demo.jangle.org/openbiblio/resources/5974,6021 (which actually
gives you a 301 to a new URI
(http://demo.jangle.org/openbiblio/resources/NTk3NCw2MDIx - which
base64s the delimited URIs -- it's a hack around how Sinatra -- the
framework Rangle -- I'm getting used to this -- uses deals with commas
and semi-colons).
Which then also gives you:
http://demo.jangle.org/openbiblio/resources/NTk3NCw2MDIx/items/
I would love a more robust availability format, btw. As soon as the
Code4lib article is done, I'll look into implementing Jakob Voss's
Document Availabity format and see if that A) scales B) provides the
functionality we really need.
-Ross.
Peter Murray
Hash: SHA1
On Jul 15, 2008, at 10:29 PM, Ross Singer wrote:
> Right now the Jangle
> reference implementation (which needs a name, Rangle?)
Given the intense discussion on the jangle-discuss list over the past
few days: "wrangle"[1]?
[1]-http://dictionary.reference.com/search?q=wrangle
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)
iD8DBQFIfiKb4+t4qSfPIHIRArQhAKCILXFLheJqXl8OWu8ClHLxIva0mwCbB++p
N99BL/PFK55IPU9ndFAD+CY=
=n5d0
-----END PGP SIGNATURE-----
Ross Singer
-Ross.
Godmar Back
>
> http://demo.jangle.org/openbiblio/resources/5974,6021 (which actually
Should this be
http://demo.jangle.org/openbiblio/resources(5974,6021)
to avoid confusing it with a related resource "5974"?
If you buy into this idea, you could conceivably also do:
http://demo.jangle.org/openbiblio/resources(5974-5988,6002-6010,6021)
to select subsets of the
http://demo.jangle.org/openbiblio/resources
feed.
- Godmar
Ross Singer
RESTful Web Services book leans toward the syntax I used.
BTW, this: http://demo.jangle.org/openbiblio/resources/5974-5988,6002-6010,6021
works as I think you would expect.
I think I'd want to see some prior art or justification as to why MS
chose this syntax, since it wouldn't be the first time they have gone
off the beaten path with regards to standard practice.
-Ross.
Godmar Back
say: "the next path element is an "id" of an element in the parent",
then you're limiting your ability to refer to child resources --- the
rationale is simply one of name spacing.
This blog entry:
http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx
provides more details.
After skimming the O'Reilly book, it seems very much in line with REST
recommendations --- look past the weird () syntax and realize the
semantic difference between expressing "select a related child
resource with id X" and "select a child resource called X".
If you use the syntax "parent/X" for the former, you won't be able to
express the latter or you end up with namespace clashes because "X"
could denote either an id or the name of a child resource.
If you don't like the (), you could adopt some other symbol (as long
as it can't occur in the name of a child resource.)
It's the same in XPath, btw, a/X expresses parent/child, a[@id=X]
represents a selection by attribute.
- Godmar