Re: Seeking consensus on RDF-star

# Necessary Parts

Here is what I think the proposal necessarily involves:

## Concrete Syntaxes:
* New concrete syntax is *just* shorthand, and expands to (something like) RDF 
reification.
** (Defer precise details of the new concrete syntaxes, e.g., "|" should not 
collide with SPARQL.)

## Concepts:
* No change whatsoever to the normative definitions of RDF graphs, triples, etc.
** So no notion of "edge" or "triple occurrence" or "named triple" in the 
normative description of RDF graphs.

## Semantics:
* No changes to the normative parts of the current RDF semantics.

# Options

Here are some options that I see:

## Vocabulary:
* Use the RDF reification vocabulary in toto.
* Use a completely new vocabulary, unrelated to the RDF reification vocabulary.
* Use specializations of (some of) the RDF reification vocabulary.

## Well-formedness:
* Implementations can reject non-well-formed RDF graphs.

## Semantics:
* Modify the section on RDF reification to make it more specific to named triples.

# Implications of the Proposal

Here are some implications of the proposal that I see.

## SPARQL
* No changes to how SPARQL works, so there are five (or four) results from 
SELECT ?p WHERE { ?s ?p ?o . } when querying << :a :b :c >> :d :e .

## RDF Graph Operations
* An RDF graph data structure, even if internally optimized, can be written in 
N-Triples with no extra space and in (quasi-)linear time.
* Creating an optimized RDF graph requires some extra storage.
* Maintaining an optimized RDF graph requires checking whether changed nodes 
are complete reification structures.



peter




On 1/17/24 06:20, Adrian Gschwend wrote:
> 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://json-ld.github.io/json-ld-star/>
> [2] https://www.w3.org/TR/rdf11-semantics/#dfn-semantic-extension 
> <https://www.w3.org/TR/rdf11-semantics/#dfn-semantic-extension>
> [3] https://www.lispworks.com/documentation/HyperSpec/Body/26_glo_e.htm#error 
> <https://www.lispworks.com/documentation/HyperSpec/Body/26_glo_e.htm#error>
> 
> 
> regards,
> 
> Ora, Pierre-Antoine & Adrian
> 
>

Received on Thursday, 18 January 2024 17:46:41 UTC