Closed pchampin closed 3 years ago
It turns things upside down to call reinstantiating referential transparency of embedded triples a 'semantic extension'.
It turns things upside down to call reinstantiating referential transparency of embedded triples a 'semantic extension'.
@rat10 care to elaborate more on this statement?
It turns things upside down to call reinstantiating referential transparency of embedded triples a 'semantic extension'.
@rat10 care to elaborate more on this statement? All of RDF operates on the level of interpretation, only embedded triples per the proposed semantics are treated as syntactic entities. This prevents entailments that would otherwise be normal. So the proposed semantics should rather be called a "semantic reduction" than the re-instatement of referential transparency a semantic extension.
@rat10 The text in 6.4.5 is considering two options:
IF option B is chosen, THEN TE is a semantic extension of OE, per the definition of 'semantic extension' in the spec.
You might consider B to be a bad idea, but that does not make the implication above false, does it?
PS: Maybe your argument was not so much about the definition of 'semantic extension' than about the connotation it may carry. However, the fact that the term links to its definition makes it clear, I think, that it is to be understood as meaning no more and no less than said definition. There is no judgement value in the the word "extension".
@pchampin The spec you cite speaks of semantic extensions as vocabularies that when applied may make a given RDF graph "support more extensive entailments than are sanctioned by the basic RDF semantics". Neither is RDF-star a vocabulary nor does it lead to more entailments, rather to the contrary. Your interpretation of the text would define RDF-star as the new normal and RDF an extension. Even if you don't fully buy into this argument you have to consider that a spec, this spec, should be as unambiguous as possible. Using the term semantic extension in such creative ways is not helping. The connotations a text invoke are indeed important: the subject is complicated enough, no need to further burden the reader with questionable analogies.
@pchampin The spec you cite speaks of semantic extensions as vocabularies
Does it? I read "A particular such set of semantic assumptions is called a semantic extension." In which dictionnary is "vocabulary" synonymous with "a set of semantic assumptions"??
Interpreting spec text in such creative ways is not helping either.
that when applied may make a given RDF graph "support more extensive entailments than are sanctioned by the basic RDF semantics". Neither is RDF-star a vocabulary nor does it lead to more entailments, rather to the contrary.
If by "the contrary" you mean "it leads to less entailments", then this is simply wrong. Any entailment that is true in RDF is also true RDF-star.
But apart from that, what are you trying to demonstrate here? That RDF-star can not be called a semantic extension of RDF? Very well, I agree with that, and I don't see what in this PR can be interpreted as making that claim. What the text says is that the alternative (ref. transparent) semantics could be defined as a semantic extension of the current (ref. opaque) semantics.
Yes, connotations and subtext are important. But the text is important too!
@pchampin The spec you cite speaks of semantic extensions as vocabularies
Does it? I read "A particular such set of semantic assumptions is called a semantic extension." In which dictionnary is "vocabulary" synonymous with "a set of semantic assumptions"??
I read before that: "Also, particular IRI vocabularies may be given meanings by other specifications or conventions. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more entailments follow from those assumptions." So particular vocabularies can be given extra meanings and assuming those extra meanings leads to a semantic extension.
Interpreting spec text in such creative ways is not helping either.
So I was imprecise but not very creative.
that when applied may make a given RDF graph "support more extensive entailments than are sanctioned by the basic RDF semantics". Neither is RDF-star a vocabulary nor does it lead to more entailments, rather to the contrary.
Yes, here I was clearly tangling things up: RDF-star is neither a vocabulary nor a semantic extension.
If by "the contrary" you mean "it leads to less entailments", then this is simply wrong. Any entailment that is true in RDF is also true RDF-star.
And here I beg to differ. How this argument turns out depends very much on how one defines the setting. If one defines RDF-star as the new normal then of course adding more entailments by interpreting embedded triples as referentially transparent extends the set of possible entailments. If that is controlled through some vocabulary then it is a semantic extension. If one however looks at RDF before and after the introduction of referential opacity for embedded triples, one sees that embedded triples don't drive entailments as one would expect them to - given the firm foundation of RDF semantics in referential transparency (and that not only as a mere side effect or coincidence but as an important and fundamental design decision). In this perspective RDF-star is very much restricting entailments in RDF. The propsed semantics restricts possible entailments from embedded triples in ways that are very surprising even to seasoned semanticists because such restrictions (or "prudence" as you prefer to call it) AFAICT are applied nowhere else in RDF except in Notation 3 formulas.
But apart from that, what are you trying to demonstrate here? That RDF-star can not be called a semantic extension of RDF? Very well, I agree with that, and I don't see what in this PR can be interpreted as making that claim. What the text says is that the alternative (ref. transparent) semantics could be defined as a semantic extension of the current (ref. opaque) semantics.
Yes, connotations and subtext are important. But the text is important too!
The report IMO needs to be extended by a self-contained discussion of the merits and shortcomings of referential opacity of embedded triples - before it becomes "final" for the first time. A better place might however be a section 2.2. That would concentrate discussions of the semantics on a more fundamental level in one place and technical details like how to get from opaque to transparent semantics wouldn't need to set the scene again. Maybe make that a new issue?
This was discussed during yesterday's call: https://w3c.github.io/rdf-star/Minutes/2021-06-04.html#t04
@rat10
The report IMO needs to be extended by a self-contained discussion of the merits and shortcomings of referential opacity of embedded triples
That's indeed the purpose of this PR, and the role that §6.4.4 and §6.4.5 aim to play. As agreed during the last call, feel free to propose changes if you feel that they don't play that role appropriately.
Any entailment that is true in RDF is also true RDF-star.
How this argument turns out depends very much on how one defines the setting.
Every term in my claim above has a precise definition, either in the RDF spec or in our CG report. So the setting seems pretty unambiguous to me.
And here I beg to differ.
Let me rephrase the assertion above: 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. I think this trivially follows from the way RDF-star entailment is defined. Or do you have a counter example?
(...) embedded triples don't drive entailments as one would expect them to.
RDF does not have any notion of embedded triples. As such, any expectation one might have, based on the RDF standard, about embedded triples, is an extrapolation, and as such, partly subjective. You are absolutely entitled to make such extrapolations, but you should not make them sound like they are necessarily shared by everyone, or like they are an integral part of the RDF standard.
@pchampin
@rat10
The report IMO needs to be extended by a self-contained discussion of the merits and shortcomings of referential opacity of embedded triples
That's indeed the purpose of this PR, and the role that §6.4.4 and §6.4.5 aim to play. As agreed during the last call, feel free to propose changes if you feel that they don't play that role appropriately.
Working on it...
Any entailment that is true in RDF is also true RDF-star.
How this argument turns out depends very much on how one defines the setting.
Every term in my claim above has a precise definition, either in the RDF spec or in our CG report. So the setting seems pretty unambiguous to me.
Your setting is unambiguous, but its not the only relevant one. Maybe you fail to imagine a setting where RDF-star is not yet proposed and in which referential transparency is the norm? That is the world we live in and in that world, or setting, the proposed semantics for RDF-star suppresses entailments in a surprising way.
And here I beg to differ.
Let me rephrase the assertion above: 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. I think this trivially follows from the way RDF-star entailment is defined. Or do you have a counter example?
(...) embedded triples don't drive entailments as one would expect them to.
RDF does not have any notion of embedded triples. As such, any expectation one might have, based on the RDF standard, about embedded triples, is an extrapolation, and as such, partly subjective. You are absolutely entitled to make such extrapolations, but you should not make them sound like they are necessarily shared by everyone, or like they are an integral part of the RDF standard.
AFIACT the concept of referential opacity is not part of the RDF 1.1 semantics. The closest thing to RDF-star in RDF, standard reification, is explicitly referentially transparent and RDF-star not long ago was advertized as being syntactic sugar for RDF standard reification. The ID attribute in RDF/XML as the only standardized syntactic sugar for referring to other statements in RDF is based on standard reification in RDF and therefore referentially transparent. Whoever stopped following the development of RDF-star last automn would be perfectly excused for expecting a referentially transparent semantics. So please explain to me what is so overly subjective about my "extrapolation".
To the contrary the proposed semantics is optimized to enable use cases that have so far not been possible at all in RDF - explainable AI, to the letter accurate representations of statements - and also not on any popular wish list that I'm aware of (or do you e.g. find them in the Easier RDF wiki?). To achieve that goal it suppresses co-denotations and entailments that everywhere on the semantic web are taken for granted and sometimes even essential. How can that semantics be called anything less than unexpected?
addresses #166
Preview | Diff