Re: On the semantics of RDF*

On 27/01/2021 16:43, thomas lörtsch wrote:
> (...)
> In this semantics the embedded triple, defaulting to point to an occurrence in the local graph, would itself be syntactic sugar for an embedded quad
>     << :a :b :c <> >>
> the fourth element explicitly pointing to the local graph.
> There could then be other variants that address an occurrence in another graph
>     << :a :b :c :g >>
> or even the WikiData usecase of multiple occurrences in one graph, local or otherwise
>     << :a :b :c <>#1 >>
> or somewhere else
>     << :a :b :c :g#1 >>
> etc,
> but also the triple type, e.g.
>     << :a :b :c () >>
> and the literal like triple of the proposed RDF* semantics, e.g.
>     << :a :b :c "" >>

This would require significant changes, in the semantics of course 
(that's the point, IIUC), but also in

* the definitions in the abstract syntax,

* the grammar of the concrete syntax Turtle* (and now N-Triples* and 
N-Quads*),

* the grammar and execution semantics of SPARQL*.


To summarize, this proposal is /very/ different from the original RDF* 
proposal.

/My belief/ is that this is not what most people involved in the CG 
report signed up for (regardless of the inherent interest of your 
proposal, by the way).

I may be wrong, of course; and if there is a general agreement to go for 
such significant changes, I'll happily comply.

>
> (...)
>
>
> We had discussions about how representations with different semantics can be constructed from the base embedded triple. Pierre-Antoine made a proposal for occurrences along the following lines (not verbatim, sorry):
>     _:b1 :occurrenceOf << :a :b :c >> ;
>          :inGraph :g ;
>          a rdf:Statement .
> (...)
>
> But more importanty, the bottom line is: it is possible to derive occurrences and triples from embedded triples but at a considerable cost.

There are different kinds of "cost", depending which part of the 
complexity we put in the data, and which part we put in the language itself.

1) plain RDF with standard reification puts all the complexity in the data

2) RDF* (as initially proposed) puts some of it in the language (adding 
a new kind of terms), but the rest still needs to be put in the data

3) your proposal puts even more of it in the language (even more kinds 
of terms).

Not everyone will agree on which trade-off is the most costly. Some 
people, for example, argue that (1) is less costly because you don't 
need to develop new tools.

   pa