Re: requesting feeback about urls for a library catalog

Hi Nicolas,

On 6/8/2011 12:30 PM, Nicolas Chauvat wrote:
> Hi,
>
> We are working on publishing as html and rdf a large catalog from a
> public library. I am writing here in the hope that someone will want to
> provide feedback on the way we organized urls and content negotiation.
> I did not cc pedantic-web since the catalog is not online yet and I
> understood pedantic-web focuses on fixing things rather than designing
> them.
>
> 0/ definitions
> ----------------
>
> <data>  is an alias for http://data.thelibrary.com/
>
> <id>  is a unique id for the person, organization or work: the thing
> that used to be a paper card in the catalog before libraries used
> computers.
>
> 1/ uris
> -------
>
> For non-informational ressources:
>
> <data>/<id>#foaf:Person identifies a person
>
> <data>/<id>#foaf:Organization identifies an organization
>
> <data>/<id>#frbr:Work identifies a work
>
> <data>/<id>#skos:Concept identifies the concept associated to the
> work, person or organisation that has id<id>. There is a Concept for
> each Person, Organization and Work.

I wouldn't utilise schema specific fragment identifier. If you would 
like to address related parts of your resource, you may simply make use 
of generic descriptors, e.g., 'person' instead of 'foaf:Person'. One 
will get the specific type via dereferencing the specific URI and start 
a FYN discovery on concrete types that are related to this resource 
description. Please get in mind that you may utilise more specific types 
for person description as well, e.g., mo:MusicArtist.

>
> For informational resources:
>
> <data>/<id>/readable_name is a document describing<id>

I wouldn't recommend to apply a "readable name" part into the URI, 
because it provokes unnecessary interpretations that should be deduced 
from the resource description one should receive by dereferencing the 
concrete URI. The ID part should be enough in the URI.

>
> Examples could be:
>
> http://data.thelibrary.com/1234#foaf:Person
> http://data.thelibrary.com/1234/victor_hugo
>
> 2/ redirection and content-negotiation
> --------------------------------------
>
> <data>/1234 redirects via HTTP 303 to<data>/1234/readable_name
>
> <data>/1234/readable_name redirects via HTTP 301 to<data>/1234/readable_name/
>
> <data>/1234/readable_name/ returns a document with HTTP 200. The exact
> document that is returned depends on the outcome of the
> content-negotiation. In the HTTP response, the content-location is set
> to something like<data>/<id>/readable_name/<lang>.<extension-mime>
>
> Examples of actual content-locations would be:
>
> <data>/1234/victor_hugo/fr.html
> <data>/1234/victor_hugo/en.html
> <data>/1234/victor_hugo/rdf.xml
> <data>/1234/victor_hugo/rdf.n3
> <data>/1234/victor_hugo/fr.pdf
> <data>/1234/victor_hugo/en.pdf

The languages parts are okay. However, I would recommend to exclude the 
"readable name" part (as proposed above).

>
> When an agent asks for some urls that are plausible but do not exist,
> a HTTP 303 redirect is sent to make life easier on users, disregarding
> the content-negotiation mechanism.
>
> a GET on                       is Redirected via 303 to
> <data>/1234/victor_hugo.html<data>/1234/victor_hugo/fr.html
> <data>/1234/victor_hugo.rdf<data>/1234/victor_hugo/rdf.xml
> <data>/1234/victor_hugo.n3<data>/1234/victor_hugo/rdf.n3
> <data>/1234/victor_hugo.pdf<data>/1234/victor_hugo/fr.pdf
>
> The fallback rule is of course HTTP 404 Not Found. That includes:
> <data>/1234/vicktor_ugo
> <data>/1234/victor_hugo.txt
> <data>/1234/victor_hugo/txt
> etc.
>
> Any feedback will be welcome. Thank you in advance.


Generally, I can recommend you to have a look at the URI design patterns 
that are propagated by the BBC developers. They are quite useful and 
interesting. Please have a look at [1] and [2] for further information 
on that issue.

Cheers,


Bob


[1] http://www.slideshare.net/reduxd/beyond-the-polar-bear
[2] http://fantasticlife.posterous.com/a-tedious-post-about-designing-ids

Received on Wednesday, 8 June 2011 17:17:23 UTC