- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Thu, 19 Jun 2003 08:50:13 -0400 (EDT)
- To: GK@ninebynine.org
- Cc: www-rdf-comments@w3.org
From: Graham Klyne <GK@ninebynine.org> Subject: Re: dealing with strings in RDF Date: Thu, 19 Jun 2003 11:10:58 +0100 > At 14:50 18/06/03 -0400, Peter F. Patel-Schneider wrote: > > >Hi: > > > >Does > > > > <http://foo.ex/a#b> <http://foo.ex/a#b> "aa" . > > > >rdf-entail > > > > <http://foo.ex/a#b> <http://foo.ex/a#b> > > "aa"^^http://www.w3.org/2001/XMLSchema#string . > > > >I believe that it is up to the RDF Core working group to provide an answer > >to this question. > > Not speaking for RDFcore, but as I think this is an important point to > clarify in some way, my view is this: > > No, this is not an rdf-entailment. Yes, of course. In my drive to be more precise, I changed entail to rdf-entail, forgetting that this needs XSD-entailment (or, at least, some datatype entailment that includes xsd:string. Silly me. > But there's a related question: is it an rdfd {xsd:string}-entailment? > > In this case I think the answer is yes. And vice versa. But if a language > tag is on the plain literal, then the entailment is off. I wholeheartedly agree. However, the current editor's draft of RDF Semantics contains, in Section 1.2: The semantics described here is deliberately agnostic on the question of whether or not the values of xsd:string are idential to character strings. > My rationale for this is that both xsd:string values and plain literals > (without lang tags) are defined to denote UNIcode character sequences > derived straightforwardly from the literal content. I think the above > conclusions follow from the abstract syntax and semantics as given (but I > don't have proof of this). I agree with this reasoning, which is why I think that the wording I quoted above should be removed. > #g > > > ------------------- > Graham Klyne > <GK@NineByNine.org> > PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E Peter F. Patel-Schneider Bell Labs Research Lucent Technologies
Received on Thursday, 19 June 2003 08:50:24 UTC