putting the proposed semantics in perspective #185
Conversation
|
A problem with this PR is that it touches many parts of the documents (regardless of the false positive changes), for many different purposes (from fix typos in examples to adding whole sections). It is really hard to discuss it as a whole, not to mention approve it. I would recommend that you split it into targeted PRs that can be discussed agreed upon more easily. |
Correction of typos is limited to examples 33 (replacing clark with clarkKent or loisLane to bring the example in line with its established source) and 34 (correctingg the umlaut in Linköping). Sorry for the distraction but I couldn't resist. Apart from that there are no trivial changes. I didn't - willingly - change anything at all in the SPARQL sections.
I fear it has to be discussed as a whole. You can't discuss the tone and general direction of a text in a piece meal fashion. In some paragraphs I only changed a few words and it already changes the tone dramatically, no less than some whole paragraphs that I added. Working on this PR as a whole also is indispensable to avoid repetition and get the contexts right, especially with the intertwined topics of referential transparency/opacity and types/occurrences. Detailed discussions can be split into seperate issues later. I would also be too clumsy with Git to do anything meaningful right now, and until tomorrow's call I have other tasks to attend to. |
|
This PR is opinionated and seeks to chip away at the document to render it useless. I suggest that @rat10 writes a separate "minority opinion" document where he has full control over the tone and content without attribution to the other authors and contributors.
This confuses provenance of what was said (i.e. the utterance) with provenance of claims (the disputable assertion). As discussed before, a proposal that does not cover utterances is missing some use cases. Supporting the (arguable) majority and not the rest at all is weaker.
As previously - in RDF, turning off isn't possible.
Unhelpful language. |
cg-spec/editors_draft.html
Outdated
|
|
||
| </section> | ||
|
|
||
| <section class="informative"> | ||
| <h2>Overview</h2> | ||
|
|
||
| <p>This specification describes RDF-star, an extension of RDF's conceptual data model and concrete syntaxes, providing a more compact form of reification. This model and syntaxes enable the creation of concise triples that reference other triples as subject and object resources. | ||
| Triples that include a triple as a subject or an object are known as <a>RDF-star triples</a>. The following dataset shows the example RDF-star triples from above using the <a href="#turtle-star">Turtle-star</a> syntax, which uses double angle brackets to enclose a triple serving as a subject or object resource:</p> | ||
| <p>This specification describes RDF-star, an extension of RDF's conceptual data model and concrete syntaxes, providing a more compact form of reification. This model and syntaxes enable the creation of concise triples that reference the syntactic representation of other triples as subject and object resources. Triples that include a triple as a subject or an object are known as <a>RDF-star triples</a>. The following dataset shows the example RDF-star triples from above using the <a href="#turtle-star">Turtle-star</a> syntax, which uses double angle brackets to enclose a triple serving as a subject or object resource:</p> |
There was a problem hiding this comment.
This addition is ambiguous and possibly misleaning. By "syntactic representation", do you mean "abstract syntax" or "concrete syntax"?
If you mean "abstract syntax", then this is redundant, because by definition, triples are elements of the abstract syntax.
If you mean "concrete syntax", then this is wrong. "<< :alice a :Person >>" and "<< :alice rdf:type :Person >>" are two different pieces of Turtle (abstract syntax), but represent the same triple (assuming the usual prefix declaration for rdf: of course).
There was a problem hiding this comment.
Redundancy is not necessarily a bad thing. Nothing is harder to read than an overly terse text. Additionally this is the overview section and the first mention of embedded triples (not by that name, but all the same).
That said, can you make a better proposal, instead of "syntactic representation"? I'm certainly not married to that expression but I want to get across an early hint that embedded triples are different from normal triples in the way that later the section on "Referential Opacity" explains in detail.
cg-spec/editors_draft.html
Outdated
| @@ -224,16 +227,16 @@ <h2>Background and Motivation</h2> | |||
|
|
|||
| <p>The RDF data model lets you state facts in three-part subject-predicate-object statements known as triples. For example, with a single RDF triple, you can say that employee38 has a familyName of "Smith". A triple's predicate is a property specified with an IRI (an Internationalized version of a URI), identifying that property in a globally unambiguous way. A triple's subject and object can each be an IRI referencing any entity, and the object can also be a literal value such as "Smith" or data of other types such as dates, numbers, or Boolean values.</p> | |||
|
|
|||
| <p>Sometimes, we want the subject or object of a triple to refer to another triple. For example, the statement "according to employee22, employee38 has a jobTitle of 'Assistant Designer'" can be modeled as a triple with "according to" as its predicate, employee22 as its object, and another triple as its subject, namely the triple "employee38 has a jobTitle of 'Assistant Designer'". This use of a triple as the subject or object resource of another triple so that we can say things about that triple is known as <a href='https://www.w3.org/TR/rdf11-mt/#reification'>reification</a>. | |||
| The concept of reification has always been part of RDF, but expressing it in most RDF concrete syntaxes such as Turtle and N-Triples, as well as processing or querying it with SPARQL, has been verbose and cumbersome [[RDF-STAR-FOUNDATION]].</p> | |||
| <p>Sometimes, we want the subject or object of a triple to refer to another triple. For example, the statement "according to employee22, employee38 has a jobTitle of 'Assistant Designer'" can be modeled as a triple with "according to" as its predicate, employee22 as its object, and another triple as its subject, namely the triple "employee38 has a jobTitle of 'Assistant Designer'". This use of a triple as the subject or object resource of another triple so that we can say things about that triple is known as <a href='https://www.w3.org/TR/rdf11-mt/#reification'>reification</a>. The concept of reification has always been part of RDF, but expressing it in most RDF concrete syntaxes such as Turtle and N-Triples, as well as processing or querying it with SPARQL, has been verbose and cumbersome [[RDF-STAR-FOUNDATION]]. A notable exception is RDF/XML which provides the <a href="https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying">ID</a> attribute as syntactic sugar for the standard reification quadlet <span class=""heavy">[Note: see my <a href="https://github.com/w3c/rdf-star/pull/171#issuecomment-854648532">comment on issue #171</a> for why I think this sentence is important].</span></p> | |||
There was a problem hiding this comment.
I don't see how this addition fits in a section called "background and motivation".
I am not denying that RDF/XML is better equipped than Turtle to handle standard reification, but this adds (or removes) nothing to the value of RDF-star, which addresses the problem in a different way (namely, by extending the abstract syntax rather than just the concrete syntax).
As for the claim that RDF-star "requires extra effort" compared to standard reification, it kinds of contradicts everything that §1.2 aims to demonstrate. This is hardly a "motivation" for the rest of the work...
Finally, the mention of explainable AI, without any further explanation (!) is a bit cryptic...
There was a problem hiding this comment.
rdf:ID can not be said to be standard reification because it is restricted in several ways.
Reification "in the wild" often uses blank nodes for the subject of the reification. rdf:ID can not express this.
RDF/XML rdf:ID used on a property, always asserts the triple.
RDF/XML rdf:ID used on a property or in <rdf:Description> has an implicit assumption of triple grouping by subject (via the uniqueness rule) which Turtle does not.
RDF/XML rdf:ID can not be the object.
The RDF/XML document can not use rdf:ID on a property and also refer to it via <rdf:Description>. It violates the rule "Each (rdf:ID attribute value, base URI) pair has to be unique in an RDF/XML document".
This means the document has to use another way to annotate the triple, which means it must know the base URI in scope (xml:base can vary through the document). It also means it can occur in another document elsewhere (either in time or place).
There was a problem hiding this comment.
I don't see how this addition fits in a section called "background and motivation".
But the other syntaxes mentioned do?
I am not denying that RDF/XML is better equipped than Turtle to handle standard reification, but this adds (or removes) nothing to the value of RDF-star, which addresses the problem in a different way (namely, by extending the abstract syntax rather than just the concrete syntax).
Both have their strengths and weaknesses. They are definitely operating in the same territory and it's good practice to mention related work and help the user make an informed decision. I find mentioning RDF/XML and its ID attribute especially fitting as this is not just a theoretical discussion but part of the use cases and discussions in calls with @JervenBolleman w.r.t. UniProt use case.
As for the claim that RDF-star "requires extra effort" compared to standard reification, it kinds of contradicts everything that §1.2 aims to demonstrate. This is hardly a "motivation" for the rest of the work...
The sentence goes on hinting at new use cases that the proposed semantics enables, which AFAICT is indeed the motivation for the proposed semantics. So I think this sentence is really a worthwhile addition to this section.
I did however make a mistake as "requires extra effort" relates to RDF standard reification which was not my intention. I meant to hint at the extra triples required in RDF-star when modelling occurrences or referentially transparent references. I'll have to re-word.
Finally, the mention of explainable AI, without any further explanation (!) is a bit cryptic...
We could replace that mention by "the Superman problem", but that would be a lot less convincing. Honestly, I'm having trouble of coming up with any other example. But I also added an issue further below where I propose and argue that you add the Explainable AI use case from your Lotico presentation. That would of course then be linked from here.
| </section> | ||
| <p>With this solution RDF-star takes three statements to annotate an occurrence. In contrast to RDF-star's approach RDF standard reification is defined as referring to occurrences. It is however underspecified insofar as it doesn't provide a way to denote the location - some graph, document or other source of a set of triples - in which a statement occurs, as the ":in" property in the example above does. RDF standard reification needs three statements to describe a triple and would need a forth statement to specify its location. Only then a fifth statement would be able to annotate such an occurrence. Note that the ":occurrenceOf" and ":in" properties in the example above serve only illustrative purposes as standardizing a proper vocabulary to denote occurrences is still an <a href="#rdf-star-vocabulary">open issue</a>. By comparison RDF/XML's <a href="https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying">ID</a> attribute implements reification without any deviation from RDF's abstract syntax and semantics and enables statement annotation without the need for any extra statements.</p> | ||
|
|
||
| <p>Referring to a specific occurrence, not to the triple as an abstract entity, is a common use case: provenance annotations on occurrences have until recently been the go-to example for RDF-star, as witnessed by the so-called <a href="#the-seminal-example">seminal example</a>. Attributed relations as in <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#support-wikidata-wikibase-data-model">WikiData</a> or Property Graphs and also n-ary relations commonly refer to occurrences. It is important to be aware that when using RDF-star embedded triples such statement annotations have to provide references to both the occurrence and its containing set or graph or source as extra statements to be correct and complete, thereby putting a certain limit to the perceived simplicity and elegance of the RDF-star approach. Querying in SPARQL consequently also becomes more involved.</p> |
There was a problem hiding this comment.
You should probably refrain from using "correct and complete" here. It has a very precise meaning for logicians and AI researchers, which has not much to do with the way you are using it here.
There was a problem hiding this comment.
Hard to assess for me as I don't understand how exactly a logician might take issue with this wording. Also this is not a normative section about the semantics. Would something like "accurate and comprehensive" be better?
There was a problem hiding this comment.
those terms are used to qualify a reasoning process, so they do not apply here. "accurate and comprehensive" sounds much better.
| </section> | ||
|
|
||
| <section> | ||
| <p class="issue" data-number="">The section <a href="#rdf-star-#semantics">RDF-star Semantics</a> should be moved here, after "Concepts and Abstract Syntax" and before "Concrete Syntaxes ". This better reflects the importance of the consequences that the proposed extension of RDF semantics may have. It also fits better into the flow of the report as right now we have 1. Introduction, 2. RDF, 3. RDF, 4. SPARQL, 5. SPARQL, 6. RDF. It also concentrates the controversial topics in the first 3 sections, making it easier for the reader to follow the discussion. Putting Semantics last risks to hide the important issues involved.</br> |
There was a problem hiding this comment.
I agree that it is strange to have two sections on SPARQL between RDF-related sections. So I am in favor of moving the semantic up.
My intuition, though, is that more people are interested in the concrete syntaxes than in the formal semantics, which was the reason to put the former first, and the latter second.
There was a problem hiding this comment.
I don't want to sound like I'm not willing to compromise. I'd certainly be glad enough if "Semantics" would be moved up before SPARQL. I still think that they should follow directly on the "Concepts and Abstract Syntax" section. People will not be shy to skip them to get to the syntaxes section ;-)
| <p>This is well suited for use-cases where the syntactical form of the annotated statements may be significant (like <a href="../UCR/rdf-star-ucr.html#annotate-statements-from-other-named-graphs-and-datasets">annotating statements from other graphs</a> or <a href="../UCR/rdf-star-ucr.html#annotate-commit-deltas">annotating commit deltas</a>). On the other hand, other use-cases would expect some degree of referential transparency. Consider the case of <a href="../UCR/rdf-star-ucr.html#meta-properties-over-properties">attributed/evidenced triples</a>. The annotation is understood to be about the fact asserted by the triple rather than the triple itself. As illustrated in the example below, one might then expect more inferences than provided by the current semantics.</p> | ||
| <p>This is well suited for use-cases where the syntactical form of the annotated statements may be significant, like <a href="../UCR/rdf-star-ucr.html#annotate-commit-deltas">annotating commit deltas</a> or differentiating the intended usage of terms from what they actually mean (like when documenting different world views or contexts of limited knowledge).</p> | ||
|
|
||
| <p class="issue" data-number="">In the Lotico presentation Pierre-Antoine explained the virtues of referential opacity by a more involved example, also using the Superman problem but extending it to an Explainable AI usecase (<a href="http://www.lotico.com/index.php/Metadata_for_RDF_Statements:_The_RDF-star_Approach">video at 1:08:12</a>, <a href="https://w3c.github.io/rdf-star/presentations/RDF-star_Lotico.pdf">slide 45</a>). I would find it advantageous if that example would also be added to this report as it seems to illustrate nicely what really drives the proposed semantics. It is another question if one thinks this works out as intended - obviously, I don't - but it gives people a much better base to understand and evaluate this proposal than the rather obscure Superman problem alone. Also, the Lotico example resorts to a hack, implementing surrogate N3 formulas via RDF lists of embedded statements, that IMO quite tellingly shows both the direction and the limitation of the proposed semantics. Again, obviously I don't believe in this design but I think readers should be enabled to form their own opinion.</p> |
There was a problem hiding this comment.
If you find both examples equally unconvincing, I don't understand your motivation for changing one for the other...
There was a problem hiding this comment.
This level of commentary/discussion is not suitable for a PR nor a published document. Each of these class="issue" callouts should really refer out to their own issue (or PR, if substantially smaller than this), and not try to bring the whole debate inline in the report.
There was a problem hiding this comment.
If you find both examples equally unconvincing, I don't understand your motivation for changing one for the other...
Well maybe I'm a bit harsh on the Superman problem but it can be hard to abstract away from a Comic scenario to the general problem of documenting world views. OTOH I found the Explainable AI use case quite interesting and also more rich on facets like the listing of embedded terms to emulate formulas. But this may be just me and I was just making a proposal.
This level of commentary/discussion is not suitable for a PR nor a published document. Each of these
class="issue"callouts should really refer out to their own issue (or PR, if substantially smaller than this), and not try to bring the whole debate inline in the report.
I apologize for the inconvinience but sometimes things are messy and it can't really be avoided. I can't discuss the setting and tone of a whole document in atomic PR's. I agree that this is not an optimal place to discuss details but I'm very grateful for the detailed critiques above and below nonetheless. I'll be happy to incorporate them and also split this PR once I have the feeling that we are on the same boat and/or if I see the benefit of smaller PRs to faciltate the discussion.
| @@ -2542,6 +2557,16 @@ <h2>RDF-star Semantics</h2> | |||
| and <dfn data-cite="RDF11-MT#dfn-equivalent" data-lt="equivalent">equivalence</dfn>. | |||
| </p> | |||
|
|
|||
| <section id="motivation-and-caveats"> | |||
There was a problem hiding this comment.
Leaving aside, as much as I can, my personal opinion about the content of this section, I am under the impression that 1) its purpose is redundant with §6.5.4 and §6.5.5 (formerly §6.4.4 and §6.4.5), and 2) commenting in details on things that have not been presented yet.
As such, I would consider it as a proposed replacement for those section rather than an additional introductory section.
There was a problem hiding this comment.
The important issue is that these topics are introduced early, not at the very end off the document. When authoring this PR I did overlook that they would wander upwards with the Semantics section if that section is moved upwards (as we seem to have a rough agreement on, see above).
However I still think that an overview section in the beginning of the semantics section should give a less technical introduction to the specifics of the proposed semantics.
There is most probaby some duplication that can be canceled but I would neither move the examples to the front nor all the discussion to the back of the Semantics section.
tl;dr I'll look into this with a fresh mind soon. What I wrote is most probaby too long. That's almost always the case with my first attempts ;-)
|
|
||
| <p>The downside of this design is that IRIs in embedded triples don't co-denote like they do in the statement that the embedded triple represents. This can have unexpected effects and impairs the ability of embedded triples to reliably model common constructs like attributed relations in property graph style, reification or n-ary relations. It is common on the semantic web that data integration processes replace IRIs by co-denoting terms from other vocabularies, and this ability is indeed essential to the conception of the semantic web as a shared knowledge space without centralized vocabularies. Statements so modified still have the same meaning as only co-denoting terms are exchanged. Embedded triples however, although in most use cases supposed to present the hinge between a statement and its annotations, won't follow suit as they are fixed to their syntactic form. Annotations therefore may loose their connection with the statement they were meant to annotate.</p> | ||
|
|
||
| <p>This approach has been controversial in the Community Group and criticised as being rather unbalanced w.r.t. to actual use cases and indeed risky as it may be too surprising and unintuitive to be followed. Choosing opaque semantics as the default is substantiated by the monotonic nature of the RDF semantics, in which entailments once made can never be taken back by further semantic instructions. The RDF-star semantics consequently starts from an entailment-suppressing syntactic representation, arguing that it's always possible later to derive the entailments on embedded triples that the referentially opaque semantics initially suppresses, thereby re-instantiating e.g. co-denotation, sub-classing and other derived knowledge. The counter argument to this concept is that it is still quite unclear how to initiate such entailments in practice in an efficient and principled way. Proposals brought forward <a href="https://github.com/w3c/rdf-star/issues/170">so far</a> either introduce referential transparency in ad hoc ways per annotating property or annotated triple or rather sweepingly per graph or dataset. The former solution doesn't scale well in situations where the need for referential opacity is not the norm but the exception and isn't constrained to a small set f properties or triples, which is arguably the vast majority of operations on the semantic web. For this reason the latter solution would seem more sensible with per default referentially transparent semantics, switching to referential opacity on demand - per application or per graph or dataset. What is indeed not possible is to switch per property or statement from a default state of referential transparency to a more restricted opaque state as that would require the - non-monotonic and therefore unavailable - ability to take back entailments.</p> |
There was a problem hiding this comment.
The RDF-star semantics consequently starts from an entailment-suppressing syntactic representation
Repeating myself: unless you provide me with a counter-example, I insist that this assertion is plain wrong.
There was a problem hiding this comment.
I can't even find where to begin with this paragraph.
There was a problem hiding this comment.
The RDF-star semantics consequently starts from an entailment-suppressing syntactic representation
Repeating myself: unless you provide me with a counter-example, I insist that this assertion is plain wrong.
There you say "given any two RDF graphs G1 and G2, if G1 entails G2 in simple RDF entailment, then G1 entails G2 in the newly defined RDF-star entailment" but how would simple RDF entailment know what to do with embedded triples?
Example 33 is an example of how RDF-star starts from an entailment-suppressing syntactic representation, which is the whole point of the proposed semantics IIUC. What are we discussing about here? Did I use a wrong technical term? Did you even try to understand what I might want to say?
There was a problem hiding this comment.
There you say "given any two RDF graphs G1 and G2, if G1 entails G2 in simple RDF entailment, then G1 entails G2 in the newly defined RDF-star entailment" but how would simple RDF entailment know what to do with embedded triples?
Indeed, when I write "RDF graph" (as opposed to "RDF-star graph"), I mean a graph that contains no embedded triple. The proposed semantics ensures that, for such graphs, the RDF-star entailment is the same as simple RDF entailment.
As for embedded triples, as you point out, RDF knows nothing about them. And therefore RDF semantics enforces no particular entailment about them. Those entailments that you argue are "suppressed" by the proposed RDF-star semantics were never there in the first place.
There was a problem hiding this comment.
I am not in favor of this PR, overall. However, if any of its pieces are to be merged, then they should have correct punctuation, grammar, etc., so ... here's a bunch of those kinds of corrections, along with some language massage which might make some of the content more palatable for merging.
| @@ -404,11 +407,23 @@ <h2>Triples and occurrences</h2> | |||
| --> | |||
| </pre> | |||
|
|
|||
| </section> | |||
| <p>With this solution RDF-star takes three statements to annotate an occurrence. In contrast to RDF-star's approach RDF standard reification is defined as referring to occurrences. It is however underspecified insofar as it doesn't provide a way to denote the location - some graph, document or other source of a set of triples - in which a statement occurs, as the ":in" property in the example above does. RDF standard reification needs three statements to describe a triple and would need a forth statement to specify its location. Only then a fifth statement would be able to annotate such an occurrence. Note that the ":occurrenceOf" and ":in" properties in the example above serve only illustrative purposes as standardizing a proper vocabulary to denote occurrences is still an <a href="#rdf-star-vocabulary">open issue</a>. By comparison RDF/XML's <a href="https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying">ID</a> attribute implements reification without any deviation from RDF's abstract syntax and semantics and enables statement annotation without the need for any extra statements.</p> | |||
There was a problem hiding this comment.
| <p>With this solution RDF-star takes three statements to annotate an occurrence. In contrast to RDF-star's approach RDF standard reification is defined as referring to occurrences. It is however underspecified insofar as it doesn't provide a way to denote the location - some graph, document or other source of a set of triples - in which a statement occurs, as the ":in" property in the example above does. RDF standard reification needs three statements to describe a triple and would need a forth statement to specify its location. Only then a fifth statement would be able to annotate such an occurrence. Note that the ":occurrenceOf" and ":in" properties in the example above serve only illustrative purposes as standardizing a proper vocabulary to denote occurrences is still an <a href="#rdf-star-vocabulary">open issue</a>. By comparison RDF/XML's <a href="https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying">ID</a> attribute implements reification without any deviation from RDF's abstract syntax and semantics and enables statement annotation without the need for any extra statements.</p> | |
| <p>With this solution, RDF-star takes three statements to annotate an occurrence. In contrast to RDF-star's approach, RDF standard reification is defined as referring to occurrences. It is, however, underspecified insofar as it doesn't provide a way to denote the location &mdadsh; some graph, document, or other source of a set of triples — in which a statement occurs, as the "`:in`" property in the example above does. RDF standard reification needs three statements to describe a triple, and would need a fourth statement to specify its location. Only then would a fifth statement be able to annotate such an occurrence. Note that the "`:occurrenceOf`" and "`:in`" properties in the example above only serve illustrative purposes, as standardizing a proper vocabulary to denote occurrences is still an <a href="#rdf-star-vocabulary">open issue</a>. By comparison, RDF/XML's <a href="https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying">ID</a> attribute implements reification without any deviation from RDF's abstract syntax and semantics, and enables statement annotation without the need for any extra statements.</p> |
There was a problem hiding this comment.
There'll probably be other changes before we can get to punctuation, but thanks!
There was a problem hiding this comment.
There's no reason not to correct punctuation as it stands (which I tend to do to make things more readable for myself, and also because it often matters to what's being said).
There was a problem hiding this comment.
You're right but before committing I'll have to check what language massage you applied.
| </section> | ||
| <p>With this solution RDF-star takes three statements to annotate an occurrence. In contrast to RDF-star's approach RDF standard reification is defined as referring to occurrences. It is however underspecified insofar as it doesn't provide a way to denote the location - some graph, document or other source of a set of triples - in which a statement occurs, as the ":in" property in the example above does. RDF standard reification needs three statements to describe a triple and would need a forth statement to specify its location. Only then a fifth statement would be able to annotate such an occurrence. Note that the ":occurrenceOf" and ":in" properties in the example above serve only illustrative purposes as standardizing a proper vocabulary to denote occurrences is still an <a href="#rdf-star-vocabulary">open issue</a>. By comparison RDF/XML's <a href="https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying">ID</a> attribute implements reification without any deviation from RDF's abstract syntax and semantics and enables statement annotation without the need for any extra statements.</p> | ||
|
|
||
| <p>Referring to a specific occurrence, not to the triple as an abstract entity, is a common use case: provenance annotations on occurrences have until recently been the go-to example for RDF-star, as witnessed by the so-called <a href="#the-seminal-example">seminal example</a>. Attributed relations as in <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#support-wikidata-wikibase-data-model">WikiData</a> or Property Graphs and also n-ary relations commonly refer to occurrences. It is important to be aware that when using RDF-star embedded triples such statement annotations have to provide references to both the occurrence and its containing set or graph or source as extra statements to be correct and complete, thereby putting a certain limit to the perceived simplicity and elegance of the RDF-star approach. Querying in SPARQL consequently also becomes more involved.</p> |
There was a problem hiding this comment.
| <p>Referring to a specific occurrence, not to the triple as an abstract entity, is a common use case: provenance annotations on occurrences have until recently been the go-to example for RDF-star, as witnessed by the so-called <a href="#the-seminal-example">seminal example</a>. Attributed relations as in <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#support-wikidata-wikibase-data-model">WikiData</a> or Property Graphs and also n-ary relations commonly refer to occurrences. It is important to be aware that when using RDF-star embedded triples such statement annotations have to provide references to both the occurrence and its containing set or graph or source as extra statements to be correct and complete, thereby putting a certain limit to the perceived simplicity and elegance of the RDF-star approach. Querying in SPARQL consequently also becomes more involved.</p> | |
| <p>Referring to a specific occurrence, not to the triple as an abstract entity, is a common use case: provenance annotations on occurrences have until recently been the go-to example for RDF-star, as witnessed by the so-called <a href="#the-seminal-example">seminal example</a>. Attributed relations, as in <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#support-wikidata-wikibase-data-model">WikiData</a> or Property Graphs, and also n-ary relations, commonly refer to occurrences. It is important to be aware that when using RDF-star embedded triples, such statement annotations have to provide references to both the occurrence and its containing set or graph or source as extra statements to be correct and complete, thereby putting a certain limit on the perceived simplicity and elegance of the RDF-star approach. Querying in SPARQL consequently also becomes more involved.</p> |
| <section id="motivation-and-caveats"> | ||
| <h2>Motivation and Caveats</h2> | ||
|
|
||
| <p>The RDF-star semantics makes a very unusual design decision: embedded triples are referentially opaque. Therefore IRIs in embedded triples do denote their syntactic representation but not their interpretation like they do everywhere else in RDF. The purpose of this design is to represent statements with the utmost precision, almost as if they were literals (except blank nodes which co-denoten as usual). This supports application-centric use cases like Explainable AI or <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#annotate-commit-deltas">Commit History</a> that would otherwise be much harder or impossible to implement in RDF.</p> |
There was a problem hiding this comment.
This paragraph is very negatively written, even as it seems to be trying to play the "pro" card, before the next paragraph which is even more negatively written, which is somewhat unsurprising as it seems to be trying to play the "con" card, but the negativity reads to me as excessive.
Should we, as the RDF-star CG present both pros and cons in our "Final" Report? Absolutely!
Should those pros and cons be presented in as neutral a tone as possible? Yes!
Are they presented so, here? No!
I've made some tweaks along those lines, but I think this insertion needs a good deal more work to make a balanced presentation.
| <p>The RDF-star semantics makes a very unusual design decision: embedded triples are referentially opaque. Therefore IRIs in embedded triples do denote their syntactic representation but not their interpretation like they do everywhere else in RDF. The purpose of this design is to represent statements with the utmost precision, almost as if they were literals (except blank nodes which co-denoten as usual). This supports application-centric use cases like Explainable AI or <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#annotate-commit-deltas">Commit History</a> that would otherwise be much harder or impossible to implement in RDF.</p> | |
| <p>The RDF-star semantics makes an important design decision: embedded triples may be referentially opaque. IRIs in opaquely embedded, or quoted, triples denote their syntactic representation but not their interpretation. The reason for this design decision is to enable the utmost precision in the representation of quoted triples, almost as if they were literals (except blank nodes which co-denote as usual). Among other things, this supports application-centric use cases like Explainable AI or <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#annotate-commit-deltas">Commit History</a> that would otherwise be much harder or impossible to implement in RDF.</p> |
There was a problem hiding this comment.
This paragraph is very negatively written, eve as it seems to be trying to play the "pro" card, before the next paragraph which is even more negatively written, which is somewhat unsurprising as it seems to be trying to play the "con" card, but the negativity reads to me as excessive.
Should we, as the RDF-star CG present both pros and cons in our "Final" Report? Absolutely!
Should those pros and cons be presented in as neutral a tone as possible? Yes!
Are they presented so, here? No!
I've made some tweaks along those lines, but I think this insertion needs a good deal more work to make a balanced presentation.
Everything else, honestly, would be quite a surprise. I'm not claiming to be free from bias, but so was the draft that I worked on. I'll not comment on all your edits in detail, just the first and the second:
- with the first I can agree in principle, but your proposal doesn't convey the novelty of the approach.
- The second I would say gives a decidely wrong impression as it takes quite some effort to come to referentially transparent embedded triples, by means of a yet to be defined semantic extension. I'm inclined to even regard a wording like "embedded triples are referentially opaque by default" as a misguiding understatement.
So: I'm aware that what I wrote may sound harsh to some here but it's the reality of the proposed semantics. Don't shoot the messenger.
[EDIT: I'm running out of steam but thanks for the changes to improve grammatic, style and flow! They won't be lost.]
|
|
||
| <p>The RDF-star semantics makes a very unusual design decision: embedded triples are referentially opaque. Therefore IRIs in embedded triples do denote their syntactic representation but not their interpretation like they do everywhere else in RDF. The purpose of this design is to represent statements with the utmost precision, almost as if they were literals (except blank nodes which co-denoten as usual). This supports application-centric use cases like Explainable AI or <a href="https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#annotate-commit-deltas">Commit History</a> that would otherwise be much harder or impossible to implement in RDF.</p> | ||
|
|
||
| <p>The downside of this design is that IRIs in embedded triples don't co-denote like they do in the statement that the embedded triple represents. This can have unexpected effects and impairs the ability of embedded triples to reliably model common constructs like attributed relations in property graph style, reification or n-ary relations. It is common on the semantic web that data integration processes replace IRIs by co-denoting terms from other vocabularies, and this ability is indeed essential to the conception of the semantic web as a shared knowledge space without centralized vocabularies. Statements so modified still have the same meaning as only co-denoting terms are exchanged. Embedded triples however, although in most use cases supposed to present the hinge between a statement and its annotations, won't follow suit as they are fixed to their syntactic form. Annotations therefore may loose their connection with the statement they were meant to annotate.</p> |
There was a problem hiding this comment.
| <p>The downside of this design is that IRIs in embedded triples don't co-denote like they do in the statement that the embedded triple represents. This can have unexpected effects and impairs the ability of embedded triples to reliably model common constructs like attributed relations in property graph style, reification or n-ary relations. It is common on the semantic web that data integration processes replace IRIs by co-denoting terms from other vocabularies, and this ability is indeed essential to the conception of the semantic web as a shared knowledge space without centralized vocabularies. Statements so modified still have the same meaning as only co-denoting terms are exchanged. Embedded triples however, although in most use cases supposed to present the hinge between a statement and its annotations, won't follow suit as they are fixed to their syntactic form. Annotations therefore may loose their connection with the statement they were meant to annotate.</p> | |
| <p>One potential downside of this design is that IRIs in quoted, i.e., opaquely embedded, triples don't co-denote like they would in the triple that the quoted triple represents. This can have unexpected effects with incautious use, which can also impair users' ability to use quoted triples to model common constructs like attributed relations in property-graph–style, reification, or n-ary relations. Users must take care to only use asserted, i.e., transparently embedded, triples for such purposes.</p> | |
| <p>Another usage pattern common on the semantic web is data integration processes, whereby IRIs in a graph may be replaced by co-denoting terms from other vocabularies. This ability is indeed essential to the conception of the semantic web as a shared knowledge space without centralized vocabularies. Statements so modified still have the same meaning as only co-denoting terms are exchanged. While asserted (transparently embedded) triples in many use cases serve as the hinge between a statement and its annotations, quoted (opaquely embedded) triples don't follow suit, as they are fixed to their syntactic form. With incautious use of quoted triples, which are not touched by such co-denoting substitutions as described above, annotations therefore may lose their connection with the statement they were meant to annotate, which <em>are</em> touched by co-denoting substitutions.</p> |
There was a problem hiding this comment.
I like the start of your changes. Then IMO you've cut too much. In the end, "Users must take care to only use asserted, i.e., transparently embedded, triples for such purposes." is wrong, as that won't help. But if my text was better aligned with example 35 that would be easier to understand (and probably could be shortened quite a bit).
|
|
||
| <p>The downside of this design is that IRIs in embedded triples don't co-denote like they do in the statement that the embedded triple represents. This can have unexpected effects and impairs the ability of embedded triples to reliably model common constructs like attributed relations in property graph style, reification or n-ary relations. It is common on the semantic web that data integration processes replace IRIs by co-denoting terms from other vocabularies, and this ability is indeed essential to the conception of the semantic web as a shared knowledge space without centralized vocabularies. Statements so modified still have the same meaning as only co-denoting terms are exchanged. Embedded triples however, although in most use cases supposed to present the hinge between a statement and its annotations, won't follow suit as they are fixed to their syntactic form. Annotations therefore may loose their connection with the statement they were meant to annotate.</p> | ||
|
|
||
| <p>This approach has been controversial in the Community Group and criticised as being rather unbalanced w.r.t. to actual use cases and indeed risky as it may be too surprising and unintuitive to be followed. Choosing opaque semantics as the default is substantiated by the monotonic nature of the RDF semantics, in which entailments once made can never be taken back by further semantic instructions. The RDF-star semantics consequently starts from an entailment-suppressing syntactic representation, arguing that it's always possible later to derive the entailments on embedded triples that the referentially opaque semantics initially suppresses, thereby re-instantiating e.g. co-denotation, sub-classing and other derived knowledge. The counter argument to this concept is that it is still quite unclear how to initiate such entailments in practice in an efficient and principled way. Proposals brought forward <a href="https://github.com/w3c/rdf-star/issues/170">so far</a> either introduce referential transparency in ad hoc ways per annotating property or annotated triple or rather sweepingly per graph or dataset. The former solution doesn't scale well in situations where the need for referential opacity is not the norm but the exception and isn't constrained to a small set f properties or triples, which is arguably the vast majority of operations on the semantic web. For this reason the latter solution would seem more sensible with per default referentially transparent semantics, switching to referential opacity on demand - per application or per graph or dataset. What is indeed not possible is to switch per property or statement from a default state of referential transparency to a more restricted opaque state as that would require the - non-monotonic and therefore unavailable - ability to take back entailments.</p> |
There was a problem hiding this comment.
I can't even find where to begin with this paragraph.
| @@ -2680,7 +2705,7 @@ <h2>Referential opacity</h2> | |||
| --> | |||
| </pre> | |||
|
|
|||
| <p>Similarly, in the example below and under <a href="https://www.w3.org/TR/owl2-overview/">OWL entailment</a> [[OWL2-Overview]], while `:superman` and `:clark` are inferred to denote one and the same person (because of the `owl:sameAs` relationship between them), the two embedded triples are not automatically considered to denote the same thing.</p> | |||
| <p>Similarly, in the example below and under <a href="https://www.w3.org/TR/owl2-overview/">OWL entailment</a> [[OWL2-Overview]], while `:superman` and `:clarkKent` are inferred to denote one and the same person (because of the `owl:sameAs` relationship between them), the two embedded triples are not automatically considered to denote the same thing.</p> | |||
There was a problem hiding this comment.
To my mind, the ClarkKentIsSuperman example is more of a demonstration of the need for graph-level if not statement(triple or quad)-level permissions, for all statements, whether asserted, inferred, quoted, or otherwise.
JimmyOlsen, ClarkKent, Superman, Batman, BruceWayne, and a few others might be granted permission to know the truth of { ex:Superman owl:sameAs ex:ClarkKent}, and therefore be permitted to draw inferences from other statements about either of those entities -- but most are not granted that permission, and so should not be permitted to draw such inferences.
It's a important thing to consider -- just like it's important that members of the Rebel Alliance should be able to conceal a statement saying so from members of the Imperial Guard. This may seem silly, but to my thinking, it flows directly from GDPR and similar rules, laws, etc.
(And yes, this is all tangential to RDF vs RDF-star vs RDF-plus-plus-plus -- but it should be a recognized concern throughout.)
There was a problem hiding this comment.
I don't think I agree because visibility and the ability to draw inferences to me seem too different to relate them in teh way you do, but, regardless, isn't this a topic on its own, outside the scope of this PR?
| <p>This is well suited for use-cases where the syntactical form of the annotated statements may be significant (like <a href="../UCR/rdf-star-ucr.html#annotate-statements-from-other-named-graphs-and-datasets">annotating statements from other graphs</a> or <a href="../UCR/rdf-star-ucr.html#annotate-commit-deltas">annotating commit deltas</a>). On the other hand, other use-cases would expect some degree of referential transparency. Consider the case of <a href="../UCR/rdf-star-ucr.html#meta-properties-over-properties">attributed/evidenced triples</a>. The annotation is understood to be about the fact asserted by the triple rather than the triple itself. As illustrated in the example below, one might then expect more inferences than provided by the current semantics.</p> | ||
| <p>This is well suited for use-cases where the syntactical form of the annotated statements may be significant, like <a href="../UCR/rdf-star-ucr.html#annotate-commit-deltas">annotating commit deltas</a> or differentiating the intended usage of terms from what they actually mean (like when documenting different world views or contexts of limited knowledge).</p> | ||
|
|
||
| <p class="issue" data-number="">In the Lotico presentation Pierre-Antoine explained the virtues of referential opacity by a more involved example, also using the Superman problem but extending it to an Explainable AI usecase (<a href="http://www.lotico.com/index.php/Metadata_for_RDF_Statements:_The_RDF-star_Approach">video at 1:08:12</a>, <a href="https://w3c.github.io/rdf-star/presentations/RDF-star_Lotico.pdf">slide 45</a>). I would find it advantageous if that example would also be added to this report as it seems to illustrate nicely what really drives the proposed semantics. It is another question if one thinks this works out as intended - obviously, I don't - but it gives people a much better base to understand and evaluate this proposal than the rather obscure Superman problem alone. Also, the Lotico example resorts to a hack, implementing surrogate N3 formulas via RDF lists of embedded statements, that IMO quite tellingly shows both the direction and the limitation of the proposed semantics. Again, obviously I don't believe in this design but I think readers should be enabled to form their own opinion.</p> |
There was a problem hiding this comment.
This level of commentary/discussion is not suitable for a PR nor a published document. Each of these class="issue" callouts should really refer out to their own issue (or PR, if substantially smaller than this), and not try to bring the whole debate inline in the report.
|
|
||
| </section> | ||
|
|
||
| <section> | ||
| <h2>Alternatives to referential opacity</h2> | ||
|
|
||
| <p>Given the potential drawbacks of the referential opacity provided by the current semantics, as described in the previous section, the group has considered alternative semantics. No clear consensus was reached, however, to decide whether these alternatives should be used as a replacement, or as a <a data-cite="RDF11-MT#dfn-semantic-extension">semantic extension</a>, of the current semantics.</p> | ||
| <p>Given the potential drawbacks of the referential opacity provided by the current semantics, as described in the previous section, the group has considered to provide embedded triples with RDF's standard referentially transparent semantics. No clear consensus was reached, however, to decide whether this alternative should be used as a replacement, or as a yet to be defined <a data-cite="RDF11-MT#dfn-semantic-extension">semantic extension</a>, of the current semantics.</p> |
There was a problem hiding this comment.
| <p>Given the potential drawbacks of the referential opacity provided by the current semantics, as described in the previous section, the group has considered to provide embedded triples with RDF's standard referentially transparent semantics. No clear consensus was reached, however, to decide whether this alternative should be used as a replacement, or as a yet to be defined <a data-cite="RDF11-MT#dfn-semantic-extension">semantic extension</a>, of the current semantics.</p> | |
| <p>Given the potential drawbacks of the referential opacity of quoted triples provided by the current semantics, as described in the previous section, the group has considered alternative semantics, including possibly treating all embedded triples as referentially transparent (i.e., as asserted) wherever they occur. No clear consensus was reached on whether this or any other alternative should be used as a replacement, or as a yet-to-be-defined <a data-cite="RDF11-MT#dfn-semantic-extension">semantic extension</a>, of the current semantics.</p> |
There was a problem hiding this comment.
Referential opacity or transparency of embedded triples has nothing to do with the question if a triple (that the embedded triple represents) is asserted or not. These are orthogonal issues. Maybe check example 35, or our recent discussion in related issues.
| <p>Another alternative would be to make embedded triples referentially opaque for certain graphs or datasets only, reflecting the application centric character of the use cases they cover. The default semantics would then be referentially transparent while additional inferences on embedded triples could be suppressed for specific sets of triples.</p> | ||
|
|
||
| <p>A further option would be to tackle both controversial design choices at once by letting the shorthand syntax default to the main stream use case of <a href="https://github.com/w3c/rdf-star/issues/174">referentially transparent occurrences</a>. Possibly unexpected and complex behaviours would such be limited to the more involved and un-abbreviated syntax for the expert user.</p> |
There was a problem hiding this comment.
| <p>Another alternative would be to make embedded triples referentially opaque for certain graphs or datasets only, reflecting the application centric character of the use cases they cover. The default semantics would then be referentially transparent while additional inferences on embedded triples could be suppressed for specific sets of triples.</p> | |
| <p>A further option would be to tackle both controversial design choices at once by letting the shorthand syntax default to the main stream use case of <a href="https://github.com/w3c/rdf-star/issues/174">referentially transparent occurrences</a>. Possibly unexpected and complex behaviours would such be limited to the more involved and un-abbreviated syntax for the expert user.</p> | |
| <p>Another alternative would be to make embedded triples referentially opaque only for certain graphs or datasets, reflecting the application-centric character of the use cases they cover. The default semantics would then be referentially transparent while additional inferences on embedded triples could be suppressed for specific sets of triples.</p> | |
| <p>A further option would be to tackle both controversial design choices at once by letting the shorthand syntax default to the mainstream use case of <a href="https://github.com/w3c/rdf-star/issues/174">referentially transparent occurrences</a>. Possibly unexpected and complex behaviors would thereby be limited to the more involved and un-abbreviated syntax for the expert user.</p> |
The second paragraph does't seem to differ from the first. #174 isn't a clear anything, neither problem statement nor solution plan nor comparison of options, and citing it here doesn't bring anything to the text. I think the second paragraph should probably just be deleted (though I didn't do so in my suggestion above).
There was a problem hiding this comment.
Thanks for the edits to wording etc. The second paragraph does indeed introduce something new so it shouldn't be deleted. As this discussion is ongoing - we talked about implementing a second shortcut syntax specifically for referentially transparent occurrences, leaving the present shorthand for referentially opaque triples as is - it may of course change in the future.
Setting a different tone is not "chipping away" and it certainly doesn't render the document useless - not to mention the implication that this was my intention.
I missed the point, yes. That may be a valid point. I'll have to think about that more.
Right, and I made that explicit: the proposed semantics has merits and it has downsides. The current draft fails to provide a balanced picture to people that are not well versed in the subtleties involved.
My proposal mentions that (twice I think), doesn't it?
Introducing referential opacity in RDF is certainly unsual but you are welcome to propose a more fitting expression: I'm not a native speaker and subtleties may get lost on me. How about "surprising"? |
remove blank line Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
unintentionally deleted line break Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Another unnecessarily deleted linebreak Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
|
I think s/"surprising"/"possibly surprising"/ would remove most negative connotations, especially if that statement were followed by a number of "concern was addressed thus and not so because basis", and should help avoid the "skimmer's folly" you describe. |
|
This is very much outdated now. |
This PR sets a decidedly different tone w.r.t. the achievements of the proposed semantics and also hints at some problems that (I fear) otherwise only seasoned semanticists would notice.
On a technical note: I created this pull request in main. A seperate branch would probably be more appropriate but I didn't dare as I'm quite clumsy with all things Git. Also: sorry about all the false positive diff's in the SPARQL section (and beyond, possibly). My editor (IntelliJ) kept adding them again and again...
Preview | Diff