- 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
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.
I'd
> 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.
Pat
>
> Richard
--
-----------------------------------
call or text to 850 291 0667
www.ihmc.us/groups/phayes/
www.facebook.com/the.pat.hayes
Received on Tuesday, 6 March 2018 18:17:05 UTC