Re: naive question: why prefer absolute URIs to # URIs for linked data?

Hi,

On 2 September 2011 17:44, Jonathan Rees <jar@creativecommons.org> wrote:
>> 2) Fragments are not sent to the server when they are dereferenced which
>> means the server has to guess what information to send. If you're storing
>> data for that URI in a database you have to key it against the hashless
>> version of the URI along with all other URIs that share that hashless part.
>> Also the server can't log accesses to the full URI which means you don't get
>> accurate analytics.
>
> OK, this makes perfect sense when there is more than one hash URI per
> hashless URI. But again, one could easily work around this. So the
> question is, why do publishers need to create more than one hash URI
> per hashless URI? Is this a matter of aesthetics, or is there some
> other reason?

I have a use case where publishing some data results in having
multiple #'s per document.

It is fairly common for someone to publish Linked Data from an
existing application, e.g. by adding new templates. Most frameworks
support multiple output formats & content negotiation.

Much, if not all, of the BBC linked data is published in this way. For
BBC Music and BBC Programmes both use # URIs, and for those
applications only a single # is required per document.

The plan was to take the same approach with BBC Wildlife. E.g:

http://www.bbc.co.uk/nature/species/Lion <-- The page
http://www.bbc.co.uk/nature/species/Lion#species <- The species

However whilst developing the model, and wanting to ensure that it was
accurate, I found that we needed an additional resource:

http://www.bbc.co.uk/nature/species/Lion#name <- The taxonomic name of
the species

A Taxonomic Name is distinct from the concept of a species. This is
common in other taxonomic models and was introduced to help support
linking and integration across datasets.

If we'd kept to the "1 URL + 1 # approach" we would have had to add
more URLs to the BBC Wildlife website. These would not have been used
or accessible to ordinary users, nor deliver any additional value for
the application. The cost of adding and maintaining those URIs would
have been more than just amending a template. So the "path of least
resistance" in that case was to simply add an additional resource with
a #.

Hopefully that's a useful, simple example of where adding an
additional # was practically useful, rather than just being
aesthetics.

Cheers,

L.

-- 
Leigh Dodds
Product Lead, Kasabi
Mobile: 07850 928381
http://kasabi.com
http://talis.com

Talis Systems Ltd
43 Temple Row
Birmingham
B2 5LS

Received on Wednesday, 14 September 2011 13:55:49 UTC