Re: RDF-ISSUE-84 (d-entailment-typed-literals): "Bug" in D-entailment with literals in non-canonical form [RDF Semantics]

I don't read this in the same way.

Here is the text:

"If D is a datatype map, a D-interpretation of a vocabulary V is any 
rdfs-interpretation I of V union {aaa: < aaa, x > in D for some x } 
which satisfies the following extra conditions for every pair < aaa, x > 
in D:"


So the interpretation interprets the things in V (whatever V is) and it 
interprets the datatype URIs. It does not necessarily interpret all the 
literals in the lexical space of all datatypes in D.

and the condition on literals say (I emphasize *in V*):

"if <aaa,x> is in D then for any typed literal "sss"^^ddd ***in V*** 
with I(ddd) = x ,
    if sss is in the lexical space of x then IL("sss"^^ddd) = 
L2V(x)(sss), otherwise IL("sss"^^ddd) is not in LV"


My suggestion is to simply say that:

"If D is a datatype map, a D-interpretation of a vocabulary V is any 
rdfs-interpretation I of V union {aaa: < aaa, x > in D for some x } 
union {"lit"^^aaa: lit in LS(d) for some <aaa, d> in D } which satisfies 
the following extra conditions for every pair < aaa, x > in D:"

and we add the following condition:

"if <aaa,x> is in D then for any typed literal "sss"^^ddd such that sss 
in LS(x),
    IL("sss"^^ddd) = L2V(x)(sss)"


That is, we force interpretations to interpret all literals in datatypes 
of D. It's probably what was initially assumed but it's better to make 
it explicit.



AZ


Le 24/02/2012 16:23, Pat Hayes a écrit :
>
> On Feb 24, 2012, at 12:43 AM, RDF Working Group Issue Tracker wrote:
>
>> RDF-ISSUE-84 (d-entailment-typed-literals): "Bug" in D-entailment with literals in non-canonical form [RDF Semantics]
>>
>> http://www.w3.org/2011/rdf-wg/track/issues/84
>>
>> Raised by: Antoine Zimmermann
>> On product: RDF Semantics
>>
>> With the current spec, we have the following situation for D-entailment, when the datatype map contains xsd:decimal (for instance):
>>
>> :foo :bar "2"^^xsd:decimal .
>>
>> *does not* D-entail:
>>
>> :foo :bar "2.0"^^xsd:decimal .
>>
>> This is because an interpretation is defined relatively to a vocabulary V, so that only the names in V are interpreted.
>
> Yes, but the definition of D-entailment requires the interpretations to interpret the vocabulary of literals which are meaningful under the datatype mappings in question. See http://www.w3.org/TR/rdf-mt/#defDinterp
>
>
>> If a triple contains a name that is not present in V, then the triple is necessarily unsatisfied.  This is made very explicit in the RDF Semantics document:
>>
>> "If the vocabulary of an RDF graph contains names that are not in the vocabulary of an interpretation I - that is, if I simply does not give a semantic value to some name that is used in the graph - then these truth-conditions will always yield the value false for some triple in the graph, and hence for the graph itself."
>>
>> Since "2"^^xsd:decimal and "2.0"^^xsd:decimal are two different names (although denoting the same thing), the first triple can be satisfied by a D-interpretation that does not interpret "2.0"^^xsd:decimal,
>
> No, because this would not be a D-interpretation. It is not defined on the required vocabulary.
>
> Pat
>
>> thus the second triple does not follow from the first one.
>
>>
>> This is probably not in line with how implementations work and the problem seem to be present in OWL 2 RDF-based semantics as well.
>>
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>

-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 83 36
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Friday, 24 February 2012 15:52:24 UTC