Re: An outline of RDFn -- RDF with (auto- and custom-) names

> On Nov 26, 2023, at 7:08 PM, Souripriya Das <SOURIPRIYA.DAS@oracle.com> wrote:
> 
> Since I did not hear any comments on RDFn during the first half of our last meeting that I was able to attend (except, maybe, Gregg might have said something right at the beginning but I had audio issues on my side), I thought it may be helpful to mention below a few high-level points about RDFn and how it is related to RDF-star concepts and syntax: ("statement" here simply means "a triple or quad"):

I did bring it up, at least conceptually, in that it defined a syntax similar to triple terms, where those triples can be identified individually. This, of course, is not RDFn, but it triggered my thoughts.

When looking at graph term solutions, there was the notion that graphs may also need to be identified (when distinct from named graphs), to distinguish one graph with a set of triples from another. In this sense, both the graph terms and triple terms could be considered to be tokens, rather than types, given the potential for different identifiers. In the case of graph terms, the thought was that a graph may have an internal identifier (similar to a blank node identifier) that allowed the same graph to be referred to elsewhere within a given serialization. The identifiers would have no meaning at the layer of the abstract syntax. My reasoning was that a triple might also have an identifier for use within a given serialization, but would not have one in the abstract syntax. I’ve suggested a hypothetical syntax for this, and it would seem to be necessary for N-Triples/Quads in the case of graph terms.


> On Nov 27, 2023, at 4:40 AM, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> How do you know that RDFn is about tokens? I have not seen Souri making
> any explicit statements in this direction.
> 
> Also, it is not correct to say that "both approaches add a fifth
> element to the subject, predicate, object and graph that we already
> have."  RDF-star does not add a fifth element. Strictly speaking, RDF-
> star does not even have "graph" as a fourth element--there is no notion
> of a quad in the abstract syntax of RDF-star (and neither is there any
> such notion in the abstract syntax of RDF). Instead, RDF-star is about
> i) triples (which may be nested),
> ii) graphs as sets of such triples, and
> iii) datasets as collections of (IRI/bnode, graph) pairs, with an
> additional graph called the default graph.
> That is all there is in RDF-star. Adding "a fifth element" (as RDFn
> seems to do) requires extending the abstract syntax with additional
> concepts, and that's why "RDFn = RDF-star" is not true.

I think adding a graph component to a tuple does set RDFn apart, and it’s not something that I’ve seen a proper motivation for in use cases. It’s certainly not something we’ve discussed adequately as a group, and I haven’t seen other proposals that would motivate this, other than potentially Thomas’s “Nested Graphs”. But, in my mind, the nesting comes from triples in a graph referring to another graph by sharing subject or object with the graph name, rather than some new terminology in the abstract syntax. I don’t think this warrants a quintuple concept, though.

For my part, though, I think we’re lost in examining multiple “solutions” and we’ll never converge at the rate we’re going. I think the time has some to the minimum requirements of a system we can agree on and move forward; we can come back later (time and energy available) to layer on my components such as triple terms or graph terms in the abstract syntax. I think that means taking a straw poll to see who could live with RDF 1.1 reification plus syntactic sugar in N-Triples/Quads/Turtle/TriG. I’d love to explore solutions that involve graph terms/tokens, but we should probably do first things first.

Gregg