Re: multiple kinds of transparency; simplicity over complexity

> On 18. Feb 2023, at 23:39, Andy Seaborne <andy@apache.org> wrote:
> 
> 
> 
> On 17/02/2023 13:14, Vladimir Alexiev wrote:
>> I thought (or Pierre-Antoine made me to believe as he got me into this ;-) that given the CG work,
>> the WG "only" has to update a bunch of specs treating the CG work as a "delta".
> . . .
>> - Over a year ago I posted a "reasoning" use case https://github.com/w3c/rdf-star/issues/200 that I now see is very naive.
>>   - Pierre-Antoine countered with examples that <<X :connectedTo Y>> cannot be transparent wrt SymmetricProperty reasoning,
>>     because consider " <<X :connectedTo Y>> :elevationGainInM 15 "
>>   - Last night I thought of the Hinterstoisser traverse (see https://en.wikipedia.org/wiki/1936_Eiger_climbing_disaster):
>>     4 people were able to cross this difficult place from right to left, 
>>     and the belief they would not need (or would be able to) cross in the opposite direction cost them their lives.
>>     So if X and Y are the two ends of this traverse, then "X :connectedTo Y" was not symmetric in 1936, 
>>     and all the way until a permanent rope was fixed on that traverse
>>   - But please understand my concern: given an inference regime, new triples are inferred.
>>     If SOME rdf-star annotations are not carried over to those triples, doesn't then rdf-star go against reasoning?
> 
> It's a good example. 
> 
> As well, suppose the quoted triple of interest is some other graph. 
> The local inference regime does not apply in the remote graph.
> 
> It might be wrong to infer new triples if the app wishes to say exactly which triple it is referring to remotely:
>    <<:s :p :o>> ex:source <http://host/graph1234>
>  .
> 
> The CG noted that while it possible to "turn on" inference (TEP), it is not possible to "turn off" inference.
> 
> Quoted triples are a building block, not a complete solution for all use cases.


tl;dr 
We can’t have too many different building blocks, so the art is to design them in the right way. And don’t forget that we have two building blocks already: quoted triples and the shortcut syntax. The latter could very well have a more "main path" semantics, like: already refer to a referentially transparent occurrence (which is of course asserted).

---

The problem is that the 'quoted triple term' building block is designed in a way that requires almost any use case to take extra steps to be sound, for reasons that almost every user will struggle to grasp. Consequently there will be so very few correct and sound uses of RDF-star in practice that the whole concept of a shared semantics falls apart. 

This is an argument that I’ve been making a lot of times already and that the architects of the proposed semantics haven’t countered with much more than handwaving (let’s wait for implementation reports, lets be optimistic, lets add more layers of complexity, lets double the number of property types (multiple times), lets educate users etc). So let’s look at the problem space again.

Quoted triples make three non-trivial fixing arrangements that target specific use cases but run against common intuitions and practices at large:

1) they refer to the type, not an occurrence
2) they are not asserted
3) they do not co-denote (i.e. they are referentially transparent)

The first arrangement was implicit in the original RDF* proposal, but not immediatly clear as the standard example suggested otherwise. The second and third arrangement were added by the CG report.

RDF standard reification is based on a different arrangement, Named Graphs per Carroll et al 2005 on yet another arrangement. They all make different sets of choices:

            type  occ |   transp. opaque | un - asserted
RDF reif.          x         x              x
NG 2005            x                 x            x
RDF-star     x                       x      x

All these proposals try to add something more or something different to "pure" statement annotation: RDF standard reification tries to provide a multi-set surrogate and evade possible issues with monotonicity, Named Graphs 2005 formalizes speech acts, RDF-star caters for cases that require syntactic fidelity. The middle-of-the-road use case however is to annotate a standard RDF triple with another standard RDF triple. 'Standard' obviously means that they are referentially transparent (vulgo: co-denoting) and asserted. Not so obviously it also means that they are concerned about occurrences, not the types themselves.

            type  occ |   transp. opaque | un - asserted
standard           x         x                    x
RDF*               x *       x                    x
Stardog            ? **      x                    x
SinglProp          x         x                    x
RDFn               x         x                    x

*   Not actually, but in impression+perception
**  I’m not sure about this one

The RDF-star shortcut syntax is again a mixture:
            x                        x            x

The distinction between types and occurrences (and what the intuitive standard approach is) probably needs more discussion, but even without a consens on that issue I hope it becomes clear that a "main path" semantics would be quite different from the proposed one. The proposed RDF-star semantics has one thing going for it: of all options it most consequently chooses the more involved, the more out-of-line ones. That does indeed enable it to cover very specific use cases that no other proposal so far could realize. The cost to all other use cases however is very high - so high indeed that it IMO it is prohibitive and robs the approach of any chance to survive "in the wild".


I’ve been proposing compromise solutions - compromises that grant the standard use cases free passage and instead require the involved use cases to make the extra (but manageable) effort. Such a compromise can be implemented in two ways:
- either (at least) define the shortcut syntax as syntactic sugar for an actually asserted referentially transparent occurrence,
- or (IMO much better) add an RDF graph literal datatype that provides all the syntactic fidelity one can wish for - for triples, graphs and maybe even individual terms [0].

We don’t have to choose between a solely mainstream solution or a solution that enables some very specific use cases, we can have both. But as long as the proponents of the CG proposal don’t let go from their maximalist position we are sure to get nothing in the end.
Because how many users will:
- state a statement in addition to quoting it
- additionally define an occurrence of the quote in an extra statement
- and define a TEP in yet another statement (not to mention the unresolved issues with the approach [1])
just to get an everyday statement annotation task done in compliance with the standard. Any perceived elegance of RDF* (not that I ever bought into that) is certainly gone. Even RDF standard reification doesn’t look bad in comparison.


Best,
Thomas


[0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Feb/0002.html
[1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Feb/0048.html

>     Andy
> 
> https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#selective-ref-transparency
>

Received on Wednesday, 22 February 2023 13:53:49 UTC