Re: Possible RDF D-semantic tweak

Hi Pat,

I think it would have been a bit neater as you propose. The modification 
would change the semantics very slightly, like in Antoine's case of:

 rdfs:Resource rdfs:subClassOf xsd:string .

which currently is unsatisfiable due to entailing:

         xsd:string rdf:type xsd:string .

These cases would be satisfiable under the modified RDFS semantics since 
we can just consider the "unicode Herbrand interpretation" where terms 
point to their own unicode representation.

The semantic consequences seem to be limited to such cases, however.


Whether or not it's worth issuing an erratum for it, I am not sure. I 
agree with Antoine that probably it will not affect anything in practice 
(except maybe that you will sleep better having made the change).

Best,
Aidan

On 2020-01-23 5:54, Antoine Zimmermann wrote:
> 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.)
>>
>>
>

Received on Thursday, 23 January 2020 17:11:20 UTC