- From: Hamish Harvey <david.harvey@bristol.ac.uk>
- Date: Tue, 21 Sep 2004 17:37:02 +0100
- To: "RDFInterest" <www-rdf-interest@w3.org>
On Tue, 21 Sep 2004 16:59:21 +0100, "Chris Purcell" <cjp39@cam.ac.uk> said: > > It is here that the need for this distinction seems clearest. Witness: > > > > <http://www.paris.org/Monuments/Eiffel> ex:resultOfDereferencing > > <http://www.paris.org/Monuments/Eiffel> . > > > > at which point meaning disappears up its own anus. It isn't clear that > > there is anything in the world of the web that can be the result of > > dereferencing itself. > > One could accuse you of excess pedantry here. ex:resultOfDereferencing My word. I'm shocked! You want excess pedantry? Pedantry is by definition excessive! Ahem. Sorry. Couldn't resist. I am, er, known for pedantry. > as a predicate can mean "the subject is the result of shoving the URI > of the object through any known, applicable de-referencing mechanism". > This is quite clear, and will confuse neither generic RDF engine nor > any software which understands the predicate. > > Many existing RDF applications have the implicit assumption: > > for all x that can be de-referenced, <x ex:resultOfDerefencing x> > holds How is my software to know what any given x can be dereferenced, without trying it? And if, upon trying it, my software finds that it can be dereferenced, I still can't distinguish between the case where the result is that which is indicated by the URI, and the case where the result describes to a human reader what it is that is indicated by the URI. > and that this assumption violates the statement in the RDF Primer: > > RDF uses URIrefs only to identify things, while browsers also use > URIrefs to retrieve things It also violates the right of the URI coiner to decide what their URI indicates, does it not? > However, we don't need to conform to this requirement in the definition > of ex:resultOfDereferencing. Why not (besides that the Primer is non-normative)? One man's pedantry is another's clarity? In this case it seems to me that the options are a) to create properties which instruct software to treat their object URIs in a non-standard way (that is, to treat them as (URI qua retrieval path)s), introducing special cases where the object URI indicates, instead of what the URI indicates, the URI itself, or b) to use the already available mechanism for distinguishing (URI qua symbol)s from (URI qua retrieval path)s: use typed literals for the latter. There's even the anyURI datatype there ready and waiting for case b. Cheers, Hamish
Received on Tuesday, 21 September 2004 16:37:09 UTC