W3C home > Mailing lists > Public > public-rdf-star@w3.org > March 2021

Adaptation of the semantics

From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
Date: Fri, 5 Mar 2021 19:00:53 +0100
To: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
Message-ID: <828395cf-d9e4-cad3-c051-c5ba88d27366@ercim.eu>
Hi all,

I just pushed a pull-request adapting the semantics:

https://github.com/w3c/rdf-star/pull/127

I believe it has some advantages over the current version:

  * it does not rely anymore on "hidden" predicates (see issue #101
    <https://github.com/w3c/rdf-star/issues/101>)
  * it does not have the "merging" issue warned about in ยง6.3.1
    <https://w3c.github.io/rdf-star/cg-spec/2021-02-18.html#combining-rdf-star-graphs>
  * I think that it allows us to align SPARQL query semantics with
    simple entailment (as newly defined)
  * I think that it allows the Interpolation Lemma
    <https://www.w3.org/TR/rdf11-mt/#dfn-interpolation> to extend to
    RDF-star

(I didn't formally prove the last two items, hence "I think"...)

The trick is that we do not map anymore RDF-star graphs to a single, 
semantically equivalent RDF graph.
Instead, we map it to a pair of RDF graphs, which can be thought of as a 
"lower and upper bound" of the RDF-star graph, in terms of entailment. 
The semantics of the RDF-star graph is defined through the semantics of 
its "bounds", reusing RDF semantics as is (as we currently do).

In this new semantics, a strict RDF-star graph (i.e. one that contains 
embedded triples) has no exactly equivalent RDF graph, so it still can 
not be conveyed exactly using RDF syntaxes (but we do not rely anymore 
on hidden predicates for that). However, either of the two "bounds" can 
be used to approximate the RDF-star graph in legacy RDF. The "lower 
bound" will produce correct but incomplete inferences. The "upper bound" 
will produce complete inferences, with a few spurious (but generally 
harmless) ones.

I am curious to get some feedback on this.



Received on Friday, 5 March 2021 18:00:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 5 March 2021 18:01:00 UTC