Re: Next weeks discussions and decision-making for RDF Star WG

I think it’s great to focus on resolving this fundamental issue. Below are the outlined suggestions with some additional thoughts:

1) Do nothing beyond RDF 1.1, there’s already a reification vocabulary with native support in RDF/XML

1.1) Same as above, but add syntactic sugar to Turtle/TriG/SPARQL for expressing reified statements. This would most naturally involve using a blank node subject, rather than a fragment identifier. Something based on the current quotedTriple syntax ‘<<‘ qtSubject predicate qtObject ‘>>’ could be syntactic sugar for [ a rdf:Statement; rdf:subject qtSubject; rdf:predicate predicate; rdf:object qtObject ]. (Stable identification can be addressed via indirection such as <#frag> rdfx:instanceOf <:a :b :c >).

2) Declare victory using the current tripleTerm resource. Triples are types, and something like rdfx:instanceOf can be used to derive tokens.

3) Leverage RDF 1.1 named graphs with the provision that a blank node graph name used elsewhere as a subject or object “identifies" that graph so named (with some work on what “identifies” means in this context). This is effectively how JSON-LD is used in Verifiable Credentials and elsewhere. A graph inclusion hierarchy, if required, can be derived by following the path from subject/object to graph name/graph.

4) Create a graphTerm resource where graphTerms are first-class terms and are distinct from named graphs. This is probably closest to how Notation3 uses graphs. This is arguably the purist from a logic point of view, but may be more difficult to express in abstract and concrete syntaxes.

Frankly, I think any of the single triple use cases can be expressed using either of these paradigms; collections of triples require one of the graph-based solutions. The main issue that gets in the way of settling on this is the Type/Token debate. I think this can be resolved in other ways. This doesn’t attempt to consider transparency/opacity; for blank nodes, I think opacity can be solved at the syntax level, by using identifiers that don’t overlap.

Consider the URL http://xmlns.com/foaf/0.1/Person. It could be considered to denote an RDF document containing a vocabulary definition for foaf:Person. It can be considered to be both a type and a token, depending on how it is used. In the context of the vocabulary definition, it is a token against which other properties can be defined:

foaf:Person a rdfs:Class; rdfs:label “Person”; …

In another context, it is a type:

<http://rdfweb.org/people/danbri> a foaf:Person; foaf:name "Dan Brickley” ...

Similarly, a graphTerm could be considered to be a type or a token, depending on the context in which it is used. Something like {:a :b :c} a rdf:Graph has the characteristic of a type, while {:a :b :c} ex:containedIn <http://example.com/foo> has the characteristic of a token. We can leverage rdfs:range/domain and explicit type declarations to clarify the intended meaning.

Perhaps we can use other explicit or implicit typing to clarify the use cases about when we are identifying a specific statement within a graphTerm or the graph itself as a collection of statements.

Regarding the different possibilities outlined above: RDF is a system for describing graphs/datasets composed of triples/statements. IMHO, the fundamental building block should be a graph, so I favor either leveraging named graphs or adding a top-level graphTerm (options 3 and 4 above). I think the impact on implementations, such as quad stores, favors reusing and refining the RDF 1.1 concept of named graphs, but with nuance given to graphs named by blank nodes. This also works as is with N-Quads. Representing graphTerms natively requires some form of syntactic extension (either embedded graphs, or a new space for graph identifiers) as well as defining a graphTerm similar to how we’ve already defined a tripleTerm in the abstract algebra.

If the WG is not able to take on the work for describing such use of named graphs, then I would favor doing something more like 1.1: reuse the existing reification vocabulary with syntactic sugar from the quotedTriple production of Turtle/TriG and SPARQL rather than adding a new tripleTerm which could interfere with future groups to take on the work of better describing the use of graphs as resources. But, I’m happy to go along with the consensus of the group whatever we decide.

Gregg Kellogg
gregg@greggkellogg.net

> On Nov 10, 2023, at 8:42 PM, Adrian Gschwend <adrian.gschwend@zazuko.com> wrote:
> 
> Dear all,
> 
> Following our last meeting and discussions on the various proposals, it has become clear that we need to focus our efforts on choosing a specific direction for our next steps. To facilitate our decision-making process, we are asking all members to review the proposals in detail and consider which one they currently favor. This preliminary decision will help to make the discussion at our next meetings more structured and productive.
> 
> The next meeting is on November 16, as discussed for once we start at the normal time but stay one hour longer. Please see the calendar for details, the event is updated.
> 
> regards
> 
> Ora & Adrian
> -- 
> Adrian Gschwend
> CEO Zazuko GmbH, Biel, Switzerland
> 
> Phone +41 32 510 60 31
> Email adrian.gschwend@zazuko.com
>