Re: [External] : Seeking consensus on RDF-star

Hi Souri,


On 18/01/2024 14:16, Souripriya Das wrote:
> Although I am quite in agreement with the Turtle syntax being 
> suggested for accommodating "edge" or "named occurrence of triple", I 
> think it is important to pay some attention to the N-Triple syntax as 
> well. Specifically, it will be much more practical to extend N-Triple 
> syntax to provide more concise ways of specifying edges than just 
> making use of reification quads.

I'm not sure how to read your comment above.


So, if your comment above is "the abstract syntax (and therefore 
N-Triples) should be more concise than expanding the reification 
triples", then this is exactly the discussion that we are proposing to 
have today.


If your comment above is "OK for the abstract syntax being solely based 
on reification triples, but I would like N-Triples to be more concise 
than that", then it is a separate discussion that I suggest we postpone 
for the moment.


   pa

>
> My suggestion for N-Triple  would be something like the syntax in the 
> following two examples (anything named is an edge, anything unnamed is 
> a triple):
>
> Example 1:
> =========
>         :s :p :o | :e .
>         :e :a :b .
> ... which should be equivalent to the following in extended Turtle:
>         << :e | :s :p :o >> :a :b .
>
> Example 2: (same as Example 1, but uses blank node _:e instead of IRI :e)
> ========
>       :s :p :o | _:e .
>       _:e :a :b .
> ... which should be equivalent to the following in extended Turtle:
>         << [] | :s :p :o >> :a :b .
>
> Thanks,
> Souri.
>
> ------------------------------------------------------------------------
> *From:* Adrian Gschwend <adrian.gschwend@zazuko.com>
> *Sent:* Wednesday, January 17, 2024 6:20 AM
> *To:* public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> *Subject:* [External] : Seeking consensus on RDF-star
> Hi all,
>
> In the interest of making progress, we propose to structure the 
> discussion on our next long meeting around the proposal below. (Best 
> viewed as Markdown)
>
>
> # What we seem to agree on
>
> There seems to be a consensus in the WG to focus on the notion of 
> "edge" or "named occurrence of a triple" (terminology still to be 
> discussed), and away from the notion of "unique triple" that was the 
> main focus of the CG.
>
> There seems also to be consensus consensus about a Turtle syntax for 
> edges:
>
>     << :e | :s :p :o >> :a :b .
>
>   and its variants:
>
>     << :s :p :o >> :a :b . # syntactic sugar for << [] | :s :p :o >> 
> :a :b .
>     :s :p :o {| :e | :a :b |}.  # syntactic sugar for :s :p :o. << :e 
> | :s :p :o >> :a :b .
>     :s :p :o {| :a :b |}.  # syntactic sugar for :s :p :o {| [] | :a 
> :b |}.
>
> Furthermore, the discussion on terminology last Friday made a lot of 
> parallels between this notion of edge and the definitions, in the 
> current specs, of rdf:Statement and reification.
>
>
> # A possible way forward
>
> An approach that has been discussed several times in the past 
> (including in the CG), but seems especially relevant in the current 
> state of the discussion (see above), is to consider the double-pointy 
> brackets as syntactic shortcut for standard reification. In other words,
>
>     << :e | :s :p :o >> :a :b .
>
> would be syntactic sugar for the following triples
>
>     :e a rdf:Statement .
>     :e rdf:subject :s .
>     :e rdf:predicate :p .
>     :e rdf:object :o .
>     :e :a :b .
>
> and the concrete syntax would not need to be extended.
>
> Of course, if we go down that path, we will have to handle the usual 
> criticisms raised against standard reification :
> (a) It is verbose
> (b) It can be inefficient
> (c) It can be messy (nodes with missing or duplicate rdf:subject / 
> rdf:predicate / rdf:object)
>
> Issue (a) is alleviated by the double-pointy bracket syntactic sugar 
> in Turtle, TrIg and SPARQL. This can be extended to other concrete 
> syntaxes (in fact RDF/XML already has some syntactic sugar for 
> reification, and the efforts on JSON-LD-star [1] can also be leveraged).
>
> Issues (b) and (c) could be alleviated by introducing a notion of 
> "well-formed" RDF (again, a better term can maybe be found). Any node 
> that has at least one of the 3 reification properties must have 
> exactly one value for each of them, or be deemed ill-formed. Systems 
> would not be required to detect or reject ill-formed RDF, but they 
> would not be required to accept it either. In other words, ill-formed 
> RDF is not forbidden nor semantically inconsistent, but it has no 
> guarantee in terms of interoperability. Existing systems (which accept 
> ill-formed RDF) would then still be compliant, but new systems could 
> reject ill-formed RDF and use this assumption to optimize storage for 
> reifications. By the way, well-formed-ness could be also defined on 
> `rdf:first/rdf:rest` ladders.
>
> Note that the notion of well-formed-ness already exists in RDF for 
> Semantic Extensions (they are called "syntactic conditions or 
> restrictions") [2]. The proposal here is to extend it to plain RDF. 
> Note also that a similar notion also exists in Common LISP ("is an 
> error") [3].
>
>
> # Seeking consensus
>
> We propose to dedicate the next long meeting to see if we can reach 
> consensus on this plan of action, remembering that consensus is not 
> defined as "everybody's favorite solution", but "a solution everybody 
> can live with".
>
> If nobody objects to that proposal, then we can move forward! If only 
> a few participants object, we can try to adapt that plan to address 
> their objection.
>
>
>
> [1] https://json-ld.github.io/json-ld-star/ 
> <https://urldefense.com/v3/__https://json-ld.github.io/json-ld-star/__;!!ACWV5N9M2RV99hQ!K36qSlUWVCnBS3UxBFQZB8fImJVAXftFQirP-SIEtS9GT-z5IrBZRV2zaRz43DlKzFkayb3pXpt_i8aVPoS_5sSYUcmbVws$>
> [2] https://www.w3.org/TR/rdf11-semantics/#dfn-semantic-extension 
> <https://urldefense.com/v3/__https://www.w3.org/TR/rdf11-semantics/*dfn-semantic-extension__;Iw!!ACWV5N9M2RV99hQ!K36qSlUWVCnBS3UxBFQZB8fImJVAXftFQirP-SIEtS9GT-z5IrBZRV2zaRz43DlKzFkayb3pXpt_i8aVPoS_5sSYF6Aqeg4$>
> [3] 
> https://www.lispworks.com/documentation/HyperSpec/Body/26_glo_e.htm#error 
> <https://urldefense.com/v3/__https://www.lispworks.com/documentation/HyperSpec/Body/26_glo_e.htm*error__;Iw!!ACWV5N9M2RV99hQ!K36qSlUWVCnBS3UxBFQZB8fImJVAXftFQirP-SIEtS9GT-z5IrBZRV2zaRz43DlKzFkayb3pXpt_i8aVPoS_5sSY5OUkw30$>
>
>
> regards,
>
> Ora, Pierre-Antoine & Adrian
>
>