Referential opacity entailment examples

[RickMoynihan]

Hi,

I'm somewhat confused by referential opacity in RDF-star and I'm wondering if the example used is correct; but equally perhaps I don't fully understand D-entailment.

In particular it strikes me that the example might be backwards, i.e. under D-entailment of pure RDF (not RDF-star) would one really say?

dbr:Linköping dbo:populationTotal "104232"^^xsd::nonNegativeInteger entails dbr:Linköping dbo:populationTotal "000104232"^^xsd::nonNegativeInteger?

Is it not more intuitive to say the reverse, thatdbr:Linköping dbo:populationTotal "000104232"^^xsd::nonNegativeInteger entails dbr:Linköping dbo:populationTotal "104232"^^xsd::nonNegativeInteger. i.e. the lexical space of0000104232 is canonicalised to the representation 104232?

I struggle with the wording, because it appears to imply to me that an infinite set of lexical representations e.g. 0104232, 00104232, 000104232, 0000104232 ... are entailed; rather than condensing an infinite set of representations into a canonical one.

If so would the examples not be better stated the other way around? I understand that because of canonicalisation (d-entailment) they're equivalent; but would it not be clearer to change these examples to something like this:

#### under D-entailment

<< dbr:Linköping dbo:populationTotal "000104232"^^xsd::nonNegativeInteger >>
    :source <https://dbpedia.org/data/Linköping>.

#### does NOT entail

<< dbr:Linköping dbo:populationTotal "104232"^^xsd::nonNegativeInteger >>
    :source <https://dbpedia.org/data/Linköping>.

# (notice the leading zeros in the literal)

Or perhaps to also explain this in terms of how the triples lexical space forms its identity under annotation?

Or am I missing something?

[TallTed]

Some inadvertent complication seems to have snuck into your attempt to explain your question. Please note that regardless of whether or not

{ dbr:Linköping dbo:populationTotal "000104232"^^xsd::nonNegativeInteger }

entails

{ dbr:Linköping dbo:populationTotal "104232"^^xsd::nonNegativeInteger }

or vice versa, it is absolutely inaccurate to say

<< dbr:Linköping dbo:populationTotal "000104232"^^xsd::nonNegativeInteger >> 
     :source <https://dbpedia.org/data/Linköping> .

because when you look to that :source, you will find only

dbo:populationTotal "104232"^^xsd::nonNegativeInteger

[RickMoynihan]

Thanks for the prompt response @TallTed. Just to check that I'm following properly...

I think you're saying my example exasperates the confusion because by flipping the direction of entailment it no longer corresponds to what is currently hosted in the remote resource?

Regarding whether or not it is inaccurate to say this, the example makes no claim about when the source was proported to say this. It could have been true at some point in the past. Similarly the absoluteness of any inaccuracy solely hinges on the semantics of :source, also <https://dbpedia.org/data/Linköping> is at the RDF level just an opaque identifier; the fact that it is also a place where those triples came from is just an adhoc convention and expectation, not a guarantee.

Personally I prefer to be unambiguous about URLs and URI's... i.e. I more correct (unambiguous modelling) would in my mind be.

<< dbr:Linköping dbo:populationTotal "000104232"^^xsd::nonNegativeInteger >> 
     :source <https://dbpedia.org/data/Linköping> .

<https://dbpedia.org/data/Linköping> dcat:accessURL "https://dbpedia.org/data/Linköping"^^xsd:anyURI . 

(It actually frustrates me that dcat permits this distinction; but that the dcat examples frequently make this category error too).

Regardless though, I certainly think your point is a good one and that it would be clearer to avoid issues like this in the examples!