Possible RDF D-semantic tweak (was:Re: is rdf a regular logic? RIF? was: Coherent Logic (a.k.a Geometric Logic) and RDF?)

> 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 00:42:27 UTC