Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New section about selective referential transparency #209

Merged
merged 18 commits into from
Oct 1, 2021
Merged

New section about selective referential transparency #209

Changes from all commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
45a213c
proposl to address #202
pchampin Sep 17, 2021
fe3319b
renames the title of the new section
hartig Sep 18, 2021
d371350
sketch of an idea to formalize a semantics that allows users to selec…
hartig Sep 18, 2021
ab31494
small fix to remove duplicate IDs
hartig Sep 18, 2021
f1b909a
fix in the T-unstar algorithm: in steps 2 and 3, only unnest quoted t…
hartig Sep 19, 2021
aa7d782
fix in the T-unstar algorithm: in steps 2 and 3, only unnest quoted t…
hartig Sep 19, 2021
3d399da
fix in the T-unstar algorithm: reuse blank nodes in steps 2 and 3
hartig Sep 19, 2021
7e8e8df
refinement of the T-unstar algorithm: direct links to the steps of th…
hartig Sep 19, 2021
ad44450
alternative proposal, based on a new kind of interpretation
pchampin Sep 21, 2021
2781893
some edits in the new part about TEPs and TEP-interpretations
hartig Sep 22, 2021
cefe0f3
Update cg-spec/editors_draft.html
hartig Sep 22, 2021
65751d4
Update cg-spec/editors_draft.html
hartig Sep 22, 2021
50fd13b
Update cg-spec/editors_draft.html
hartig Sep 22, 2021
ceb1add
Update cg-spec/editors_draft.html
hartig Sep 22, 2021
e54d0ed
Update cg-spec/editors_draft.html
hartig Sep 22, 2021
ed6df7a
rename the property ':at' to ':on' as suggested in https://github.com…
hartig Sep 22, 2021
fc71b5d
use the term 'transparency-enabling property' rather than 'transparen…
hartig Sep 22, 2021
875e36d
adds some text to clarify that the transparency-enabling semantics of…
hartig Sep 23, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
117 changes: 105 additions & 12 deletions cg-spec/editors_draft.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -346,6 +346,8 @@ <h2>Overview</h2>
<tr><td>`rdfs:`</td><td>`&lt;http://www.w3.org/2000/01/rdf-schema#&gt;`</td></tr>
<tr><td>`owl:`</td><td>`&lt;http://www.w3.org/2002/07/owl#&gt;`</td></tr>
<tr><td>`prov:`</td><td>`&lt;http://www.w3.org/ns/prov#&gt;`</td></tr>
<tr><td>`dbo:`</td><td>`&lt;http://dbpedia.org/ontology/&gt;`</td></tr>
<tr><td>`dbr:`</td><td>`&lt;http://dbpedia.org/resource/&gt;`</td></tr>
<tr><td>`dc:`</td><td>`&lt;http://purl.org/dc/elements/1.1/&gt;`</td></tr>
<tr><td>`dct:`</td><td>`&lt;http://purl.org/dc/terms/&gt;`</td></tr>
</table>
Expand Down Expand Up @@ -2820,11 +2822,11 @@ <h2>Mapping RDF-star abstract syntax to RDF</h2>

<div class="algorithm">
<ol>
<li>For each <a>IRI</a> |i| in the <a>constituents</a> of |G| starting with `https://w3c.github.io/rdf-star/unstar#`: <ol>
<li id="unstar-replace-unstar-IRIs">For each <a>IRI</a> |i| in the <a>constituents</a> of |G| starting with `https://w3c.github.io/rdf-star/unstar#`: <ol>
<li>Mint a new <a>IRI</a> |j| by appending an underscore (`_`) to |i|.</li>
<li>Replace with |j| all occurrences of |i| in the <a>subject</a>, <a>predicate</a>, or <a>object</a> position of an <a>asserted</a> or <a>quoted</a> triple of |G|.</li>
</ol></li>
<li>While |G| contains <a>quoted triples</a>:<ol>
<li id="unstar-loop">While |G| contains <a>quoted triples</a>:<ol>
<li>Pick an <a>RDF-star triple</a> (|s|, |p|, |o|) in the <a>constituents</a> of |G| such that neither |s| nor |o| is a <a>quoted triple</a>.</li>
<li>Mint a fresh blank node |b| (i.e., such that |b| is not in the <a>constituents</a> of |G|).</li>
<li>Replace with |b| all occurrences of (|s|, |p|, |o|) in the <a>subject</a> or <a>object</a> position of an <a>asserted</a> or <a>quoted</a> triple of |G|.</li>
Expand Down Expand Up @@ -2974,26 +2976,26 @@ <h2>Referential opacity</h2>
<!--
#### under D-entailment

:linköping :population "0104232"^^xsd::integer
{| :source <https://en.wikipedia.org/wiki/Link%C3%B6ping> |}.
dbr:Linköping dbo:populationTotal "104232"^^xsd::nonNegativeInteger
{| :source <https://dbpedia.org/data/Linköping> |}.

#### does NOT entail

:linköping :population "104232"^^xsd::integer
{| :source <https://en.wikipedia.org/wiki/Link%C3%B6ping> |}.
dbr:Linköping dbo:populationTotal "0104232"^^xsd::nonNegativeInteger
{| :source <https://dbpedia.org/data/Linköping> |}.

#### more precisely, it DOES entail

:linköping :population "104232"^^xsd::integer.
dbr:Linköping dbo:populationTotal "0104232"^^xsd::nonNegativeInteger.

#### but it does NOT entail

<< :linköping :population "104232"^^xsd::integer >>
source <https://en.wikipedia.org/wiki/Link%C3%B6ping> .
<< dbr:Linköping dbo:populationTotal "0104232"^^xsd::nonNegativeInteger >>
:source <https://dbpedia.org/data/Linköping>.
-->
</pre>

<p>Note that the current semantics does not forbid the additional inferences to be drawn. However, they would require additional knowledge and an appropriate <a data-cite="RDF11-MT#dfn-semantic-extension">semantic extension</a>, not specified in this document. This makes RDF-star less readily usable for (but not incompatible with) that latter kind of use-cases.</p>
<p>Note that the current semantics does not forbid the additional inferences to be drawn. However, they would require additional knowledge and an appropriate <a data-cite="RDF11-MT#dfn-semantic-extension">semantic extension</a> (such as the one discussed in <a href="#selective-ref-transparency"></a>). This makes RDF-star less readily usable for (but not incompatible with) that latter kind of use-cases.</p>

</section>

Expand Down Expand Up @@ -3031,11 +3033,102 @@ <h2>Alternatives to referential opacity</h2>
</li>
</ul>

<div class=note>Other design choices for the semantics have also been discussed by the community group; these have been <a href="https://github.com/w3c/rdf-star/issues/95">summarized in a Github issue</a>.</div>

</section>

</section>
<section id="selective-ref-transparency">
<h2>Selective referential transparency</h2>

<p>Since the needs for referential opacity and transparency are use-case dependent (as discussed <a href="#ref-opacity">above</a>), it may make sense for different predicates to have different behaviors. Consider the following example.</p>

<pre id="selective-ref-opacity"
data-transform="updateExample"
data-content-type="text/turtle"
class="nohighlight example"
>
<!--
<< dbr:Linköping dbo:populationTotal "104232"^^xsd::nonNegativeInteger >>
:on "2010-12-31"^^xsd:date ;
:source <https://dbpedia.org/data/Linköping.ttl> .

### Candidate entailment #1

<< dbr:Linköping dbo:populationTotal "0104232"^^xsd::nonNegativeInteger >>
:on "2010-12-31"^^xsd:date .

### Candidate entailment #2

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

<p>One could argue that the candidate entailment #1 is desirable because the property `:on` is understood to be about the <em>statement</em> made by the subject triple (that statement was true on the given date, regardless of its RDF expression). On the other hand, the candidate entailment #2 may be considered not desirable because the predicate `:source` is about the triple itself (that specific triple was parsed from the given Turtle file).</p>

<div class=note>Other design choices for the semantics have also been discussed by the community group; these have been <a href="https://github.com/w3c/rdf-star/issues/95">summarized in a Github issue</a>.</div>
<p>Subclasses of `rdf:Property` could therefore be defined to identify properties that imply referential transparency on their subject triple, on their object triple, or on both. Note, however, that the group has not reached consensus on the definition or usefulness of such a vocabulary.</p>

<p>Here is a sketch of how to extend the semantics in a way that it can work with such a property, which we call a <dfn data-lt="TEP">transparency-enabling property (TEP)</dfn>. The basis of the idea is that each such property&nbsp;|p| is identified by adding to the RDF-star graph a triple of the form (|p|, `rdf:type`, `rdf-star:TransparencyEnablingProperty`); i.e., for the previous example, this triple would be (`:on`, `rdf:type`, `rdf-star:TransparencyEnablingProperty`). Notice that enabling referential transparency based on such TEPs is only local to the RDF-star graph(s) in which the TEP is stated to be a TEP (or where this statement can be inferred as per the entailment regime considered); in other words, for every graph&nbsp;|G| in which a property is <em>not</em> stated to be transparency enabling, all quoted triples within triples in |G| that have the property as predicate are considered as referentially opaque, even if there may exist some other graph in which the property is stated to be transparency enabling.
The semantics of such TEPs can be captured for the different <a data-cite="RDF11-MT#dfn-entailment-regime">entailment regimes</a> by extending the corresponding notion of <a data-cite="RDF11-MT#dfn-interpretation">interpretation</a> as exemplified in the following for the <a data-cite="RDF11-MT#simple-interpretations">simple interpretation</a> of the <a data-cite="RDF11-MT#simpleentailment">simple entailment regime</a>.</p>

<p>A <dfn>simple TEP-interpretation</dfn> is a <a data-cite="RDF11-MT#simple-interpretations">simple interpretation</a> |I| that satisfies the following two additional conditions:</p>

<ol>
<li><em>Ensure that, for all quoted triples in this interpretation, all "equivalent" triples also exist in the interpretation.</em>
<ul>
<li>For all |t|, |s|, |p|, |o| in the domain IR such that<ul>
<li>(|t|, |s|) ∈ IEXT(`unstar:subject`),
<li>(|t|, |p|) ∈ IEXT(`unstar:predicate`),
<li>(|t|, |o|) ∈ IEXT(`unstar:object`),
</ul>
<li>and for all terms |s|', |p|', and |o|' such that <ul>
<li>|I|(|s|') = |s|,
<li>|I|(|p|') = |p|,
<li>|I|(|o|') = |o|,
</ul>
<li>there must exist |t|' in IR such that<ul>
<li>(|t|', |s|) ∈ IEXT(`unstar:subject`),
<li>(|t|', |p|) ∈ IEXT(`unstar:predicate`),
<li>(|t|', |o|) ∈ IEXT(`unstar:object`),
<li>(|t|', |I|(L(|s|'))) ∈ IEXT(`unstar:subjectLexical`),
<li>(|t|', |I|(L(|p|'))) ∈ IEXT(`unstar:predicateLexical`), and
<li>(|t|', |I|(L(|o|'))) ∈ IEXT(`unstar:objectLexical`).
</ul>
</ul>

<li><em>Ensure that TEPs that hold for a triple also hold for all "equivalent" triples.</em>
<div>For every |p| such that (|p|,IS(`rdf-star:TransparencyEnablingProperty`)) ∈ IEXT(IS(`rdf:type`))</div><ul>
<li>|p| must be an element of IP
<li>For all |t|, |u|, |s|', |p|', |o|', |t|' in IR such that<ul>
<li>(|t|, |u|) ∈ IEXT(`p`)
<li>(|t|, |s|') ∈ IEXT(`unstar:subject`),
<li>(|t|, |p|') ∈ IEXT(`unstar:predicate`),
<li>(|t|, |o|') ∈ IEXT(`unstar:object`),
<li>(|t|', |s|') ∈ IEXT(`unstar:subject`),
<li>(|t|', |p|') ∈ IEXT(`unstar:predicate`),
<li>(|t|', |o|') ∈ IEXT(`unstar:object`)
</ul>
then (|t|', |u|) must also be an element of IEXT(|p|).
<li>For all |t|, |u|, |s|', |p|', |o|', |t|' in IR such that<ul>
<li>(|u|, |t|) ∈ IEXT(`p`)
<li>(|t|, |s|') ∈ IEXT(`unstar:subject`),
<li>(|t|, |p|') ∈ IEXT(`unstar:predicate`),
<li>(|t|, |o|') ∈ IEXT(`unstar:object`),
<li>(|t|', |s|') ∈ IEXT(`unstar:subject`),
<li>(|t|', |p|') ∈ IEXT(`unstar:predicate`),
<li>(|t|', |o|') ∈ IEXT(`unstar:object`)
</ul>
then (|u|, |t|') must also be an element of IEXT(|p|).
</ul>
</ol>

<p>Given two <a>RDF-star graphs</a> |G| and |H|, and following standard terminology, we say that a simple TEP-interpretation |I| satisfies |G| if |I|(|G|) = true, and that |G| is (simply) TEP-satisfiable if a simple TEP-interpretation exists that satisfies |G|; otherwise, |G| is (simply) TEP-unsatisfiable. We say that |G| simply TEP-entails |H| if every simple TEP-interpretation that satisfies |G| also satisfies |H|. If |G| and |H| each TEP-entail the other, they are TEP-equivalent.</p>

<p>TEP-entailment is defined here as an extension of <a data-cite="RDF11-MT#simpleentailment">simple entailment</a>, but other entailment regimes (such as <a data-cite="RDF11-MT#rdf-entailment">RDF entailment</a> or <a data-cite="RDF11-MT#rdfs-entailment">RDFS entailment</a>) can be extended in the exact same way (i.e., by extending their respective notion of interpretation with the aforementioned two conditions).</p>

</section>

</section>

</section>

Expand Down