W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: Semantics issues

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Tue, 21 Jan 2003 09:06:54 -0500 (EST)
Message-Id: <20030121.090654.101257705.pfps@research.bell-labs.com>
To: phayes@ai.uwf.edu
Cc: bwm@hplb.hpl.hp.com, www-rdf-comments@w3.org

From: pat hayes <phayes@ai.uwf.edu>
Subject: Semantics issues (was:Re: email problems)
Date: Mon, 20 Jan 2003 10:46:02 -0800

> >If the current version of the Semantics document is the one pointed to from
> >the RDF Core WG home page as the LCC, then there are still lots of errors,
> >many significant.
> >
> >
> >From: pat hayes <phayes@ai.uwf.edu>
> >Subject: Re: email problems
> >Date: Sun, 19 Jan 2003 21:13:56 -0800
> >
> >[...]
> >
> >>  >It appears to me that RDF(S) literals are now broken.  (I'm working from
> >>  >the LCC candidate at 
> >>http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/)
> >>  >
> >>  >The only semantic constraints that mention rdfs:Literal are
> >>  >1/ I(rdfs:Literal) is a member of IC
> >>  >2/ rdfs:comment rdfs:range rdfs:Literal.
> >>  >3/ rdfs:label rdfs:range rdfs:Literal.
> >>
> >>  Now in addition we have that ICEXT(I(rdfs:Literal) ) is a subset of
> >>  LV. Also in datatyped interpretations, all datatype classes are
> >>  subclasses ofICEXT(I rdfs:Literal)). So I think that this covers your
> >>  problems, except as noted below.
> >
> >No.  Now typed literals are handled somewhat better, but untyped literals
> >are still rather strange, because the denotation of "a" is not necessarily
> >in CEXT(I(rdfs:Literal)).
> 
> True, it is not necessarily in that class extension. Why does that 
> bother you? There is no way in any piece of RDF syntax to assert that 
> it (or any other particular literal) is or is not in that class, so 
> to impose a semantic condition which cannot be expressed 
> axiomatically would serve no purpose other than to guarantee 
> incompleteness of any inference system. 

Well, so what?  Is this any different than the situation with respect to
RDF datatypes?  How is this any different from the situation with respect
to rdf:XMLLiteral?  It seems to me that if you can handle rdf:XMLLiteral
you should be able to handle untyped literals being in
CEXT(I(rdfs:Literal)).

> If you want OWL to have that 
> extra condition (eg that ICEXT(I(rdfs:Literal)) = LV, say) then OWL 
> is free to add that as an extra condition. Until RDF syntax provides 
> some way to have literals as ubjects, however, I would recommend 
> against it. (IF RDF did have literals as subjects I would have had 
> the class rdfs:Literal tightly defined from the very start.)
> 
> ....

Right now the situation is very unusual with respect to literals in RDF.
In RDFS, the following is not valid

	ex:john ex:foo "a" .

entails

	ex:john ex:foo :_a .
	:_a rdf:type rdfs:Literal .

but any datatype entailment that includes a datatype that has the string
"a" in its value space (even if the lexical-to-value mapping does not map
the syntactic construct "a" to this string) the entailment follows.  


> >[...]
> >
> >In the LCC document, datatypes are still broken.  For starters, the
> >document is inconsistent with respect to just what is a datatype; sometimes
> >it is a member of the domain, sometimes it is a URIref.
> 
> I have not detected that inconsistency, can you point me at where it 
> occurs? The document uses datatype urirefs to refer to datatypes, 
> which seems consistent to me.
> 
> The intent is that recognized datatypes are always members of the domain.

Then how do you justify 

     The set of recognized datatypes always includes rdf:XMLLiteral

in Section 3.4?  

> >The treatment of
> >rdf:XMLLiteral is very suspect, for example what happens to "a"^^ex:foo if
> >I(rdf:XMLLiteral) = I(ex:foo)?
> 
> If that identity holds (which would be rather extraordinary) then 
> ex:foo would in fact be rdf:XMLLiteral, ie
> 
> owl:sameIndividualAs ex:foo rdf:XMLLiteral .
> 
> would be true. So in that case indeed, the typed literal you have 
> written would have the same value as "a"^^rdf:XMLLiteral in that 
> interpretation.

Not according to the RDF model theory.  In this model theory rdf:XMLLiteral
is handled very differently than other datatypes.  rdf:XMLLiteral is
handled (in Section 3.1) by

	if xxx is a well-formed XML document, 
	then IL("xxx"^^rdf:XMLLiteral) is the XML canonical form of xxx
	...

Other datatypes are (very awkwardly) handled in Section 3.4, by

	... satisfies the following extra conditions on all datatypes other
	than the built-in datatype:
	...
	For any typed literal "sss"^ddd or "sss"@ttt^^ddd, if I(ddd) is in
	D and 'sss' is a valid lexical form for I(ddd) then IL("sss"^^ddd)
	= L2V(ddd)(sss)

(By the way, this appears to imply that the only lexical forms that matter
are ones that start and stop with a single quote.  Also, this is missing
the interpretation of "sss"@ttt^^ddd.)

So "a"^^ex:foo falls through the cracks.  It doesn't match the conditions
in Section 3.1 because it has the wrong URI ref and it doesn't match the
conditions in Section 3.4 because they don't hold for I(rdf:XMLLiteral).

> Of course, there is no way in RDF(S) or even OWL-DL to establish such 
> an identity, so the question only makes sense in OWL-Full.  I have no 
> problems with this, myself.
> 
> >The translation into Lbase is still broken with respect to rdf:XMLLiteral.
> 
> Can you be more specific?

TR("sss"@ttt^^rdf:XMLLiteral) = L2V(TR["sss"],TR[ddd])
which incorrectly ignores the language tag

I have pointed this out at least one before in a message to w3c-rdfcore-wg

> Pat

Peter F. Patel-Schneider
Bell Labs Research
Lucent Technologies
Received on Tuesday, 21 January 2003 09:07:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:31 GMT