W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: email straw poll: literal semantics proposals

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 10 Oct 2002 11:44:28 +0300
Message-ID: <004201c27039$3eeb25c0$544516ac@NOE.Nokia.com>
To: "ext Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>, "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]

----- Original Message ----- 
From: "ext Jos De_Roo" <jos.deroo.jd@belgium.agfa.com>
To: "Brian McBride <bwm" <bwm@hplb.hpl.hp.com>
Cc: "RDF Core" <w3c-rdfcore-wg@w3.org>; <w3c-rdfcore-wg-request@w3.org>
Sent: 10 October, 2002 00:58
Subject: Re: email straw poll: literal semantics proposals

> [sorry to be late, but I had no access in Bristol to my mailbox]
> B 5 (for rdf:format xsd:... there are canonical lexical forms)

Option B, as I understand it, does not (and IMO cannot) presume
or require any use of canonical lexical forms. The machinery
simply does not exist to do that, and it's not RDF's place to
define it.

> F 0 i.e. I do not want to loose the the entailment
>       :I :love _:x.
>       :You :love _:x.
>     given *nothing* but
>       :I :love "RDF".
>       :You :love "RDF".
>     (ref. meaningful derivation requirement)

You are using ambiguous local names as if they are global
constants. That's what URIrefs are for. I understand that
there is a certain degree of convenience in being able
to use short, simple names to denote resources, but your
usage is presuming a consistency of meaning that non-URIref
strings simply *cannot* be guarunteed to have globally.

And is the above supposed to be saying that you and I both 
love the string "RDF" or that we both love the specification? 
Or  perhaps "RDF" means something different in each cate and 
we don't love the same thing at all! (see below)

If you adopt anything but option F, you cannot be saying anything
about the actual specification, but only about the simple string
"RDF". Is that what you really want to say? That we both love
the string "RDF"? And if it is, why is it not possible, taking
the F proposal, to say

   :I :love xsd:string"RDF" .


   :I :love "RDF" .
   :love rdfs:range xsd:string .


If you're really talking about the specification and not the string,
then you're going to have to use a URIref or similar naming convention
and not just a simple local name.

And surely you don't presume that the acronym "RDF" always means the
Resource Description Framework?! C.f.


This is why inlined literals do *not* have globally consistent meaning
and *cannot* serve as global constants, even if they might work as local 
constants for a particular system that itself constrains the meaning
over and above the RDF MT.

RDF is *global* in scope yet folks seem to keep thinking in terms of
closed systems. I.e. ..."RDF" always means the same thing in my system so
why shouldn't it mean the same thing for the entire universe?...
Well, because it *doesn't* and if you want to communicate what you mean
and avoid introducing ambiguity into the mix, you'd better not presume
that everyone is going to interpret your own local names the way you
do. That's why URIrefs and XML Namespaces were created, for crying out
loud, to avoid ambiguity and conflict in the interpretation of local names.


The inline literal "RDF" is *ambiguous* and string equality for inlined
literals is not the same as equality of meaning.

Surely the above set of interpretations of "RDF" makes this clear! Eh?

The reality may very well be that you love the 'Resource Description
Framework', but I actually love 'Radio Direction Finding' (which actually,
I do) and any query engine that equates the meaning of "RDF" in the
above statements is simply *wrong*. We don't love the same thing!

If folks just want to do syntactic matching, go use XQuery. 

Option F is the only sane option if we are going to have a solution
for the *global* interchange of knowledge between *arbitrary* systems.

All the other options are just data markup and do not serve the goals
and vision of the semantic web.

Received on Thursday, 10 October 2002 06:06:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC