What are the differences between a quoted triple and its singleton set?

Dear all,

Given that RDF Semantics (both in 1.1 [1] and 1.2 [2]) state:

    A triple is identified with the singleton set containing it, so
that each triple in a graph is considered to be a subgraph.

Why, then, isn't a quoted triple, say:

    prefix dc: <http://purl.org/dc/terms/>
    prefix : <http://example.org/ns/>

    << <http://example.net/s> :p "o" >> dc:date "2023" .

simply identical to:

    <data:application/n-triples,:%3Chttp%3A//example.net/s%3E%20%3Chttp%3A//example.org/ns/p%3E%20%22o%22%20.>
dc:date "2023" .
    graph <data:application/n-triples,:%3Chttp%3A//example.net/s%3E%20%3Chttp%3A//example.org/ns/p%3E%20%22o%22%20.>
{
        <http://example.net/s> :p "o" .
    }

The one difference I can make is that it is not *explicit* that the
singleton set above is not asserted. Rather, due to [3], it appears
undefined, or user/application dependent(?). That might be amended by
using reification, like:

    <data:application/n-triples,:%3Chttp%3A//example.net/s%3E%20%3Chttp%3A//example.org/ns/p%3E%20%22o%22%20.>
dct:date "2023" .
    <data:application/n-triples,:%3Chttp%3A//example.net/s%3E%20%3Chttp%3A//example.org/ns/p%3E%20%22o%22%20.>
{
        <data:application/n-triples,:%3Chttp%3A//example.net/s%3E%20%3Chttp%3A//example.org/ns/p%3E%20%22o%22%20.>
a rdf:Statement ;
            rdf:subject <s> ;
            rdf:predicate :p ;
            rdf:object "o" .
    }

Or, perhaps better, it could be solved by defining a symbol for
stating that a particular graph is not asserted, e.g.
`blogic:NeutralGraph` (inspired by [4] and [5]), like:

    <data:application/n-triples,:%3Chttp%3A//example.net/s%3E%20%3Chttp%3A//example.org/ns/p%3E%20%22o%22%20.>
a blogic:NeutralGraph .

I've tried to follow the history and ongoing work of RDF-star, and
while I suspect the options above have been considered and rejected, I
fail to grasp exactly why. Is it that since *just* singleton graphs
are insufficient for the criteria of quoted triples, elaborating on it
was not considered worthwhile? Or is it because of how quad stores
work in practise? Perhaps, hidden behind this from the community
report [6]:

    RDF-star describes quoted triples, which are not necessarily
present in any named graph, or within the default graph.

lies a set of unresolved practical problems? E.g. that a graph
containing quoted triples would have to relate to lots of singleton
sets (graphs identified by a triple), and that these sets would need
to be treated differently depending on their type and/or
relationships? I may miss something obvious here, because to me,
introducing a new kind of RDF "atom" just sidesteps that, instead of
working to make more sense of the existing practises for named graphs,
and in the process eliminating unnecessary differences (the divergence
of quotation and named graphs), as well as illuminating, existing
necessary ones (such as how named graphs can be used together in
different ways).

Instead, RDF is being extended with the notion of a recursively
defined "complex triple" (and might even have "levels of compliance"
[7] with ensuing new differences [8]). This is quite a departure from
what RDF has been for over 20 years, where hitherto everything has
been possible to reduce to a simple, *flat* substrate of quads. I'm
trying to understand why this is irrevocably necessary.

While I see many use cases for quoted triples (and for quotation in
general), from my point of view they are *closely* related to the
current practises of named graphs. I fail to see harmony with that in
the evolving semantics. I don't see the necessary difference.

Best regards,
Niklas

[1]: https://www.w3.org/TR/rdf11-mt/#notation-and-terminology
[2]: https://w3c.github.io/rdf-semantics/spec/#notation
[3]: https://www.w3.org/TR/rdf11-datasets/#each-named-graph-defines-its-own-context
[4]: https://www.w3.org/2009/07/NamedGraph.html#named-graphs
[5]: https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk
[6]: https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#trig-star
[7]: https://github.com/w3c/rdf-star-wg/issues/19
[8]: https://github.com/w3c/rdf-star-wg/issues/33

Received on Saturday, 27 May 2023 12:35:15 UTC