Re: Change Proposal for HttpRange-14

On 24/03/12 13:57, Jonathan A Rees wrote:
> On Sat, Mar 24, 2012 at 7:17 AM, Jeni Tennison<jeni@jenitennison.com>  wrote:
>
>> Where well-behaved sites will have to make a decision is whether to continue to use a 303 or switch to using a 200 and including a 'describedby' relationship. For example, we at legislation.gov.uk might be seriously tempted to switch to returning 200s from /id/ URIs. Currently, anyone requesting an /id/ places a load on our origin server because the CDN can't cache the 303 response, so we try to avoid using them in links on our site even where we could (and really should). Consequently people referring to legislation don't use the /id/ URIs when what they are referring to is the legislation item, not a particular version of it. If we switched to a 200, we wouldn't have to avoid those URIs, which would in turn help us embed RDFa in our pages, because instead of having a reference in a footnote contain something like: [...]
>
> Sorry to be a broken record here, I must be really not be hearing what
> everyone is saying, but why don't you just use hash URIs? (Using the
> #it or #_ indirection pattern if necessary.) This is the received
> wisdom from the original semweb design, and they don't have any of the
> problems that 303s or 200s do.

I can't speak for legislation.data.gov.uk.

However, as a long-time advocate of the "just use hash URIs" school then 
there are a couple of problems that convince me they are not convenient 
for all cases.

In the case where your data is, or could reasonably be, organized as a 
manageable bunch of documents then hash URIs are perfect. Small to 
moderately size ontologies are a canonical example of this.

In more complex situations they are less perfect.

Problem 1: fragility of default fragment assumption

In many systems we wish to serve up linked data from a triple store. A 
request for information on U comes in, we return DESCRIBE <U>. However, 
if U is a hash URI U'#F then, of course, all we see is U' and we need to 
reconstruct the F. For data totally under our own control we can adopt 
some standard fragment like 'it' and respond to U' with the result of 
DESCRIBE <U'#it>. However, the data is not always under our complete 
control and there is no universal agreement on what default fragment to 
use. Leaving us either having to maintain mapping tables or try multiple 
probes ("when asked for U try <U> then try <U#id> then try ..."). Not a 
fatal problem but certainly an inconvenience when managing large and 
complex stores.

Problem 2: serialization

With a convention of a single standard fragment then prefix notation in 
Turtle and qname notation in RDF/XML become unusable. You would have to 
have a separate prefix/namespace for each resource. In turtle you can 
just write out all URIs in full, inconvenient for not fatal. In RDF/XML 
you can do that for subjects/objects but not for properties (and not for 
classes if you want to use abbreviated syntax). Having to declare a new 
prefix for every property, and maybe every class, in a large ontology 
just so it can be serialized is a non-starter.

Dave

Received on Saturday, 24 March 2012 17:36:31 UTC