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

Re: decision time: semantics of non-datatyped literals

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Wed, 18 Sep 2002 11:35:53 +0100
Message-Id: <>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>

My perception is this:  M&S is not clear, so neither choice is a *change* 
to M&S.

Value based semantics:
   corresponds to the readings of M&S by those doing "information design"
   (e.g. CC/PP, DC, etc.)

String based semantics:
   corresponds to the readings of M&S by those doing software implementations
   (e.g. cwm, Jena, etc.)

Thus, whatever choice me make, it will break *someone's* code and/or data.

I favour value-based semantics, because I think this more closely matches 
the intuitions that are invoked when populating the semantic web, which I 
think will, in the longer run, be the biggest task.

But (given datatyped literals) I think either approach can work.


At 12:48 PM 9/16/02 +0100, Brian McBride wrote:

>I indicated last week my intention that the WG should decide on the 
>semantics of non-datatyped, i.e. old style, literals, at this weeks 
>telecon.  I ask for the WG's support in keeping to that schedule.
>The decision we have to make is to choose whether literals of the form:
>   <rdf:Description>
>     <foo:age>10</foo:age>
>   </rdf:Description>
>have tidy or untidy semantics, or indeed whether we are not saying one way 
>or the other.  Note: I like the terms introduced by Patrick, "value based 
>semantics" and "string based semantics".
>This debate has raged for many months, with committed proponents of each 
>position arguing at length and failing to convince each other.  After all 
>this, I think we have to conclude that we have failed to find a decisive 
>flaw or advantage in either approach.  We have, in fact, to assume that we 
>have two self consistent positions and we must make a choice between them, 
>or choose not to decide.
>I think it is the role of the chair to assist the WG to reach a 
>decision.  We have been stuck on this for ages.  In the light of this, I 
>am going to introduce a bias in the way I frame the decision.
>I note that all of the implementations of RDF with which I am familiar 
>have implemented M&S with the assumption that literals have string 
>semantics, i.e. literal("foo").equals(literal("foo")).
>Our charter is to clarify M&S, not to go rewriting it.  We have in the 
>past allowed ourselves some leeway in this regard, but we have set the bar 
>higher for justifying a "change" than for more straight forward clarifications.
>If we are going to ask implementations to change to remain conformant, I 
>suggest the WG has a duty to justify that decision.  There must be a 
>strong and clear benefit from such a change and it must be one we can 
>clearly articulate to the developer community and expect them to support.
>The issue here is not whether the developer community is willing to 
>change.  I expect the Jena team will implement what the WG decides as no 
>doubt will others.  But if the WG are going to ask folks to spend time and 
>money making these changes, it ought to have a good reason for doing so.
>I am suggesting therefore that the default decision is that non-datatyped 
>literals have string based semantics (tidy) unless there is good reason to 
>change.  I invite those who advocate value based semantics (untidy) to 
>advance a rationale for such a change and we will determine at Fridays 
>telecon whether this convinces the WG.
>I suggest that we have debated this issue to death and that further debate 
>is pointless.  We are at the stage where we need to summarize the argument 
>and have the WG decide whether it finds it convincing.  As chair, I could 
>try that summary myself, but I have decided that it would be best done by 
>the advocates themselves, though I'll try to help out if it looks like 
>that would be useful.
>ps: summaries are short and clear

Graham Klyne
Received on Wednesday, 18 September 2002 06:13:53 UTC

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