- From: Pierre-Antoine Champin <swlists-040405@champin.net>
- Date: Wed, 27 Jan 2010 10:32:57 +0100
- To: Peter Ansell <ansell.peter@gmail.com>
- CC: Christoph LANGE <ch.lange@jacobs-university.de>, Linked Data community <public-lod@w3.org>
On 27/01/2010 03:45, Peter Ansell wrote: > Disambiguating everything is a pipe dream IMO. I agree with that. Note also that HTTP makes a difference between a *resource* (identified by a URI) and the *entity* retrieved when GETting the URI, which is a mere *representation* of the resource. >From that perspective, retrieving some FOAF data from the URI of a person does *not* mean that "You are your FOAF". Only that "Your FOAF represents you", which is perfectly acceptable. This is not to say that a person's FOAF profile (or their HTML representation, for that matter) does not deserve to be talked about, and must be distinguishable from that person (as in Ian Davis' example reported by Ross Singer). From the publisher's point of view, giving them a URI of their own is a solution, and using the "303 Redirect" patter, is a good way to link the two URIs [1]. But then we only push the problem a step further: what about *today's version* of the FOAF profile (which may be different from yesterday's)... This, in turn, is a URI-less entity about which one may want to talk about (like: "today's version sucks even more than yesteday's"). >From this, I draw two conclusions: 1/ we need a to be able to talk in RDF about *representations* of resources, even when those representations do not have a proper URI. This is addressed by Harry Halpin and Valentina Presutti in [2]. 2/ publishers can not possibly be expected to provide a URI for *everything* one wants to talk about, as adding a URI automatically adds another level of representations. So they should not even be expected to always provide 2 levels with a 303 redirect between them if they don't feel the need for it. pa [1] Another solution would be to reply "200 Ok" with a Content-Location header field, but Content-Location is broken in most browsers, and apparently won't be fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=503078 [2] http://www.springerlink.com/content/m7546274uq301h34/
Received on Wednesday, 27 January 2010 09:33:29 UTC