- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 23 Sep 2002 14:49:58 +0300
- To: "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, "Dave Beckett" <dave.beckett@bristol.ac.uk>, "RDF Core" <w3c-rdfcore-wg@w3.org>
[Patrick Stickler, Nokia/Finland, (+358 50) 483 9453, patrick.stickler@nokia.com] ----- Original Message ----- From: "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com> To: "Patrick Stickler" <patrick.stickler@nokia.com>; "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>; "Dave Beckett" <dave.beckett@bristol.ac.uk>; "RDF Core" <w3c-rdfcore-wg@w3.org> Sent: 23 September, 2002 14:20 Subject: RE: Proposed N-Triples changes for datatypes & (untidy) literals > > > > > Only parsers need change, so that they give the inline literals > > the needed systemID prefix. > > This fails the old self-entailment test: > > <rdf:Description> > <eg:name>Patrick Stickler</eg:name> > </rdf:Description> > > is neither equal to, not does it entail, > > <rdf:Description> > <eg:name>Patrick Stickler</eg:name> > </rdf:Description> > > A position that was rejected a long time back. Hmmm... but was this old self-entailment test based on a presumption of tidy semantics? It appears it was. And thus, it may now be a broken or invalid test as it does not in fact reflect the new semantics of inline literals. If we are in fact going to presume that 1. Inline literals have untidy semantics 2. Entailments are based on semantics (right?) 3. The meaning of inline literals is unknown in the absence of explicit knowledge of the datatype by which the lexical form is to be interpreted then it is not unreasonable that the above entailment cannot be determined in the absence of an rdfs:range datatyping assertion for the eg:name property, since string-equality of lexical forms does not (necessarily) reflect value-equality. And we cannot infer value-equality by the two triples having both the same property and the same lexical form, since it has been shown that general properties such as rdf:li or similar provide no semantically distinct context as does a datatype (and in such cases, local/explicit datatyping is the only mechanism to make explicit the datatypes of literal objects of such general or collection membership properties). Thus, while it is the case that most properties which take inline literal objects tend to be associated with a datatype and thus appear to provide a semantically distinct context for interpretation, one may not in fact base any tests of equality on the property alone and thus entailments such as above cannot be determined without the datatype. I'm still not convinced, though, that the above could not be made to entail itself in the MT, since the systemID of the implicitly typed literal (the _:x in _:x"foo") acts like a bnode nodeID of a datatype, and can be treated in like manner. I.e., if we are to parse the RDF/XML twice, each instance of the <rdf:Description> element will result in a different bnode. How can the first subject bnode entail the second, both of which have string-unequal labels, yet the first implicitly datatyped lexical form cannot entail the second? Seems like analogous cases to me. I would assert, though, that the following (if allowed) would clearly reflect self entailment of untidy inline literals: <rdf:Description> <eg:name rdf:nodeID="_:x">Patrick Stickler</eg:name> </rdf:Description> entails <rdf:Description> <eg:name rdf:nodeID="_:x">Patrick Stickler</eg:name> </rdf:Description>
Received on Monday, 23 September 2002 07:55:19 UTC