Re: Possible RDF D-semantic tweak

This fix would not have problematic consequences in terms of tool 
support and inferences, but it would not solve much either. Also, people 
could be confused by the weird distinction between "identifies" and 
"denotes" (aren't people already confused by parts of RDF semantics?)

To me, having datatype IRIs denote the corresponding datatypes makes 
perfect semantic sense too.

The D-entailment cases we are discussing in this thread should be seen 
as intellectual games rather than test cases for reasoners. Reasoners 
are more likely to support D* entailment rather than D entailment in any 
case.

Perhaps the next revision of RDF semantics, if it ever happens, should 
make explicit that reasoners MAY disregard some of the constraints on 
datatypes and still be considered conformant.

But even without such explicit text, it has never prevented people from 
disregarding parts of standards that are awkward to implement.

--AZ


Le 23/01/2020 à 01:42, Patrick J Hayes a écrit :
> 
> 
>> On Jan 21, 2020, at 2:48 AM, Antoine Zimmermann <antoine.zimmermann@emse.fr> wrote:
>>
>> ...
>> In D-entailment, the IRIs in D have to be interpreted as the datatype they are associated to. For instance, in RDFS semantics, xsd:string has to be interpreted as the datatype (LS,VS,L2V) where LS -- the lexical space of xsd:string -- is the set of valid XML schema strings, VS -- the value space of string -- is the same as LS, and L2V -- the lexical-to-value mapping -- is iedentity. So, the universe of all RDFS interpretations has to contain the triple (LS,VS,L2V). This triple is clearly not a sequence of UNICODE character itself.
> 
> True. With hindsight, given that we were careful to say “identifies” rather than “denotes” for datatype IRIs, it would probably have been better to have simply omitted the ‘...I(aaa) is the datatype...’ clause in the semantics for datatype literals, especially as it does not actually have any functional purpose. It also has the pernicious effect of ruling out Herbrand-style D-interpretations.
> 
> This may be worth recording as an erratum to be corrected in possible future changes, in fact. Do you (or anyone reading this) have any insight into whether this would cause any unforseen problems?
> 
> The suggested change is to replace the text in the second text box in the table 'Semantic conditions for datatyped literals.’ in section 7.1. by this:
> 
> For every other IRI aaa in D, and for every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(ddd)(sss), where ddd is the datatype identified by aaa.
> 
> which does not refer at all to I(aaa). The idea is to leave open what the datatype IRI denotes (as opposed to what it identifies), but retain the condition that when used as a class name it refers to the value space, which is imposed later in the document. As far as I can see, the actual referent of the datatype IRI (as opposed to its class and property extensions) is irrelevant to RDF(S). So a Herbrand-style interpretation could have a datatype IRI like ‘xsd:string’ denoting, say, itself, provided that it were given appropriate class and property extensions by the IEXT and ICEXT maps. I think this would remove some of the worst D-semantic ratholes; and it is just better style, anyway, to not directly impose conditions on denotation mappings.
> 
> To retain coherence, two more downstream editorial changes are needed. In the text immediately following that table, replace
> 
> 'the L2V(I(aaa)) mapping’
> by
> ’the L2V(ddd) mapping’
> 
> and in the table of RDFS semantic conditions, first text box, replace
> 
> 'for every other IRI aaa in D, ICEXT(I(aaa)) is the value space of I(aaa)’
> by
> 'for every other IRI aaa in D, ICEXT(I(aaa)) is the value space of the datatype identified by aaa’
> 
> Note that the referent of the datatype IRI is still playing the ‘role’ of the datatype in class reasoning, but is no longer required to actually /be/ the datatype. One might say it is acting as an avatar for the datatype. This avoids forcing the RDF universe to contain such awkward entities as datatypes.
>   
>> But the statement:
>>
>> rdfs:Resource rdfs:subClassOf xsd:string .
>>
>> in RDFS means that all resources (all things in the universe) must belong to the extension of the class denoted by xsd:string. In turn, D-entailment says that all datatypes in D are classes whose extension is exactly their value space (crucially, this last constraint is removed by ter Horst in his D*-entailment [1]).
> 
> But I would still keep this, which makes such perfect semantic sense even if it does make most reasoners incomplete :-)
> 
> Pat
> 
> (CCing PFPS, for obvious reasons.)
> 
> 

-- 
Antoine Zimmermann
Institut Henri Fayol
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://www.emse.fr/~zimmermann/
Member of team Connected Intelligence, Laboratoire Hubert Curien

Received on Thursday, 23 January 2020 08:55:03 UTC