- From: Dave Reynolds <dave.e.reynolds@gmail.com>
- Date: Sat, 24 Mar 2012 17:36:00 +0000
- To: Jonathan A Rees <rees@mumble.net>
- CC: Jeni Tennison <jeni@jenitennison.com>, public-lod community <public-lod@w3.org>
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