add entailment rule for datatypes

[pfps]

Fixes #44

The basic issue is that RDF entailment recognizes the rdf:langString and the xsd:string datatypes. This means that the domain of discourse includes all XSD strings and all language-tagged strings. In these interpretations the following triples are true:

_:b rdf:type rdf:langString .
_:c rdf:type xsd:string.

and thus need to be accounted for in the entailment patterns.

---

Preview | Diff

[TallTed]

huh... No PR-Preview on this repo? PR-Preview was delayed. Is there now.

[TallTed]

Is line 1610 (previously 1591) the only "[place] where the RDF rules are used"? If not, #44 should be kept open until all those places are also addressed.

[gkellogg]

PR Preview is enabled for this repo, and is on previous PRs. It’s not perfect, though, and it doesn’t seem to have completed in this case.

[pfps]

Is line 1610 (previously 1591) the only "[place] where the RDF rules are used"? If not, #44 should be kept open until all those places are also addressed.

I believe that the only place the rules are used is in Appendix A, with the reference to them on the new line 1610.

[gkellogg]

Does it need some new tests?

[pfps]

I think so.

A test would be the empty graph entailing
_:y rdf:type xsd:string .
_:z rdf:type rdf:langString .
in RDF entailment.
If there is a new string datatype that is required for RDF entailment then that should be included as well

If there are tests for D-entailment then the empty graph entailing
_:x rdf:type xsd:integer .
in D-entailment recognizing xsd:integer should be included.

[gkellogg]

So as not to loose this maybe best to create an issue referencing #45 (comment) in https://github.com/w3c/rdf-tests, or keep this issue open with a "needs tests" label.

[gkellogg]

Also, this will need an entry in "Changes since ...".

[pfps]

Added entry to changes since RDF 1.1.

[pfps]

How is the WG going to handle changes that need tests? Is the PR going to remain unmerged until the tests are done?

[TallTed]

[@pfps] How is the WG going to handle changes that need tests? Is the PR going to remain unmerged until the tests are done?

I suggest creation of an issue ("need test for PR xxx") such that accepted PRs may be merged more quickly, allowing other work to proceed, while a test PR is pending.

(As @gkellogg also suggested earlier.)

[pfps]

OK, I'll add a test issue when (if?) this PR is merged. As this and other PRs that need tests should have a needs test tag it should be possible to check that each of these PRs have a resolved test issue.

[pchampin]

Alternatively, we can put the needs-test on #44 and keep it open until the test is created?

[pchampin]

Except for the sentence in the change log that needs some clarification, LGTM.

[gkellogg]

Alternatively, we can put the needs-test on #44 and keep it open until the test is created?

Creating a test in rdf-tests that references #44 should be adequate; after all, it's a testing issue not a spec/editorial issue.

[Antoine-Zimmermann]

Like @pchampin, I approve these changes pending the change to the sentence in the change log.

However, I noticed that the algorithm in the Appendix is still incomplete with this rule. I opened issue #46 to discuss this.

[doerthe]

The entailment only holds, if the set of literals is fixed (and contains at least one xsd:string and one rdf:langString), I guess that is the case from our point of view?

[doerthe]

This would thus mean that, if we'd ever allow literals in subject position we would have to add a triple for all possible xsd-literals we can ever construct?

[doerthe]

I don't like the rule (yet?) and would argue that a model normally only works with the iris and literals occurring in the graphs plus a fixed (finite!) set of iris which are a fixed part of the language.

But I am undecided, so please convince me here :)

[pfps]

This would thus mean that, if we'd ever allow literals in subject position we would have to add a triple for all possible xsd-literals we can ever construct?

Yes. It is a consequence of datatype semantics that if l is in the lexical space of d then l rdf:type d . is true in all interpretations recognising d. So the rule GrdfD1 is not complete for generalized RDF.

[pfps]

I don't like the rule (yet?) and would argue that a model normally only works with the iris and literals occurring in the graphs plus a fixed (finite!) set of iris which are a fixed part of the language.

But I am undecided, so please convince me here :)

In the original RDF semantics interpretations were with respect to a vocabulary. For entailment to work correctly the vocabulary had to include all IRIs in both graphs in the entailment. That is, the empty graph did not RDFS-entail :a rdf:type rdfs:Resource . which is weird.

The RDF 1.1 simple semantics requires that all IRIs have a denotation in IR union IP. Then RDF 1.1 interpretations require that all IRIs have a denotation in IR because of the definition of rdf:property. So in the RDFS 1.1 semantics every IRI has a denotation that is in ICEXT(rdf:Resource).

[pfps]

The domain of discourse is not finite in RDF intepretations because of the built-in datatypes. However, there is no requirement that the denotation of different IRIs is different so the non-literal part of the domain of discourse can be finite.

[doerthe]

Yes, and I always assumed that we simply talk about some set of IRIs and some set of literals which is not further specified, so it may or may not be the set of all IRIs and literals which are valid according to the grammar.

I agree that only in the case of literals, taking all possible literals into account makes the domain of discourse infinite.
I was also wondering about the consequences, but so far I could not come up with a problem...

[doerthe]

OK, I thank Peter for saving us from having the discussions from RDF 1.1 again. I understand why we do not want to depend on the vocabulary in this case and also approve.