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

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.

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