W3C home > Mailing lists > Public > semantic-web@w3.org > March 2018

Re: rdfs:subClassOf and XSD derivation by restriction

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 6 Mar 2018 12:16:28 -0600
To: Richard Smith <richard@ex-parrot.com>, Andreas Harth <andreas@harth.org>
Cc: semantic-web@w3.org
Message-ID: <03fd4508-289d-60a0-fbb0-0b0f3204d90b@ihmc.us>
On 3/6/18 10:43 AM, Richard Smith wrote:
 > Andreas Harth wrote:
 >>> The examples in §7.2.1 of RDF 1.1 Semantics tells us that any
 >>> valid statement of the form
 >>> ex:a ex:p "sss"^^xsd:decimal .
 >>> D-entails
 >>> ex:a ex:p "sss"^^xsd:integer .
 > [These, of course, are the wrong way round.  But I hope my
 > meaning was clear, all the same.]
 >> The RDF 1.1 semantics spec gives that example and implicitely
 >> derives that entailment from the XSD specification (I think).
 > Having thought about this in some more detail, I think I now
 > understand it.
 > So far as I can tell, none of the RDF specs formally defines the
 > lexical-to-value mapping of the RDF-compatible XSD types.

Indeed, they do not. This was (not) done deliberately in order to 
avoid an 'external' re-statement of an existing specification.

 > expect it to be defined in §5.1 of RDF 1.1 Concepts but it is not
 > said explictly.  Nevertheless, I'm sure it's intended that the
 > lexical space, value space and lexical-to-value mapping of these
 > types for the purpose of RDF is the same as their lexical space,
 > value space and lexical mapping as defined in XSD.

Yes. The RDF 1.1 semantics is explicit about this. If you 
recognize these datatypes, they must be used in exact conformity 
with the XSD specs.

  Taking that
 > as read, it follows that
 >    L2V(I(xsd:integer)) ⊆ L2V(I(xsd:decimal))
 > For a string "sss" in the lexical space of xsd:integer,
 >    I("sss"^^xsd:integer) = IL("sss"^^xsd:integer)
 >                          = L2V(I(xsd:integer))(sss)
 >                          = L2V(I(xsd:decimal))(sss)
 >                          = I("sss"^^xsd:decimal)
 > Given the triple
 >    ex:a ex:p "sss"^^xsd:integer .
 > we know
 >    < I(ex:a), I("sss"^^xsd:integer) > ∈ IEXT(I(ex:p))
 > and, using the result above,
 >    < I(ex:a), I("sss"^^xsd:decimal) > ∈ IEXT(I(ex:p))
 > Therefore that triple entails the following triple:
 >    ex:a ex:p "sss"^^xsd:decimal .
 > This is pure D-entailment.

When D (which is a parameter, remember) contains those two 
datatypes, yes.

However, it still does not follow that one datatype is an RDFS 
subclass of the other, since RDFS classes are not required to be 
extensionally defined (ie not all subsets need be subclasses).

 >> But given that RDF, RDFS (and OWL) entailment is layered on top
 >> of D-entailment, datatypes have to be correctly handled even if
 >> the RDF processor does not know about RDF, RDFS and OWL
 >> entailment.

True, but (as far as RDF/S is concerned), a 'correct handling' of 
literals typed by those datatypes is to treat them simply as 
opaque names, without referring to the datatype specs at all. 
More sophisticated (OWL, D- for larger D's) entailment engines 
might be able to do more, of course.

 > This is a pertinent comment, as it seems to me that D entailment
 > is the least well understood entailment regime. It's easy enough
 > in the simple case where the only recognised datatypes are
 > xsd:string and rdfs:langString which are the only two required
 > ones, but as soon as other types come in, it gets hairy rapidly.

Indeed. This is why OWL-DL keeps all literal/datatype issues in a 
separate box with very strict rules on how it can interact with 
general class reasoning.


 > Richard
call or text to 850 291 0667
Received on Tuesday, 6 March 2018 18:17:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 March 2018 18:17:15 UTC