Why quoted triples, when we already have named graphs?

[lars-hellstrom]

This is not meant to suggest that RDF shouldn't have quoted triples, but rather to point out that this is likely an objection that some people will raise, and the specification should have some answer. Concepts seems the most natural document in the collection.

I'm quite the beginner, so I don't know what the answer might be. Quoted triples definitely seems an obvious way of making claims about other claims, but when suggesting an encoding in terms of quoted triples to people more experienced with semantic web things, I got the reply that "nah, you do that with named graphs instead". It took me a while to grok that — much literature still paints named graphs mainly as a tool for keeping track of remote datasources — but of course a single edge named graph is a way of speaking about that edge, and in a quadstore it is more feasible to search all graphs for a triple than it is to search for a blank node reifying that triple, so named graphs overcome problems with classic reification. Then what is the point of quoted triples as a completely different mechanism?

It is possible that there is some aspect of having just one term that is the quoted triple (s,p,o), instead of any number of size 1 graphs which contain exactly that triple, that is the important difference (at least that is one thing I cannot easily see how it would be simulated), but then that should probably be spelt out. This is the kind of requirement one throws in when aiming to introduce a quoting operation, but it is not entirely clear what application would benefit from it.

The counterargument against quoted triples is conceptual and implementation simplicity: quadstores are nicely flat data structures, whereas quoting brings the complexities of nesting. Of course, representing information that is inherently nested within a flat store only means that the nesting happens at a higher level of the representation, but since this could make it Someone Else's Problem it would probably have its proponents. Why not regard << >> and {| |} merely as syntactic shorthands for constructing a named graph? (It doesn't meet the spec, but why is the spec that way?)

[rat10]

As long as named graphs can't be nested in the syntax they will always be used for one primary purpose mainly. What that purpose is is a very application specific question. It must not always be the same purpose, but managing provenance is a natural default in an integration-focused project like the semantic web.
Quoted triples won't solve that because nesting them is verbose and quickly gets quite unreadable, and the semantics the CG report proposed doesn't help either. But they do, at least syntactically, open the door to Property Graph style statement annotation and qualification, and that is where they will be successful. That is a modelling idiom very different from named graphs, focused more on qualification than on integration, providing detail instead of context.
But what is considered detail and what context is again an intuition that is very application specific. And syntactically both intuitions do overlap in the case of single triples.
Maybe nested named graphs would provide the best of both worlds and bridge them quite naturally (and in one and only one modelling primitive), but syntactically I'd rather go for nesting {{{ ... }}} than << << << ... >> >> >>. or {| {| {| ... |} |} |}.

[afs]

I'm sure a NGS design could be done. (NGS = Named Graph Singleton")

But as already noted, named graphs are already in use for e.g. data management - a non semantic usage pattern - indeed the concepts behind Named Graphs existed before SPARQL.

Some systems have the default as the union of named graphs.
This would result in the triple in the NGS also being asserted.

One use case for quote triples is referring to triple as triples - the "syntactic case". "Triple was added to database" as used in bitemporal modelling for "as it was recorded", different to when a fact was original asserted.

The challenge that I see is what is the reasonably minimal building block. Encoding abstractions with triples (c.f RDF Lists, Reification) has practical usage problems.

[rat10]

I'm sure a NGS design could be done. (NGS = Named Graph Singleton")

The point is nesting. Then different levels can have different purposes. The outermost named graph could still be used for data management.

But as already noted, named graphs are already in use for e.g. data management - a non semantic usage pattern - indeed the concepts behind Named Graphs existed before SPARQL.

Defined in Named Graphs, Carroll et al 2005, with a very definitive semantics, which was largely ignored in practice. My take on that history is: if a semantics doesn't match the predominant intuition and needs of users, it won't survive. RDF-Star semantics as defined in the CG report will face the same fate.

Some systems have the default as the union of named graphs. This would result in the triple in the NGS also being asserted.

You will always find some system that has some default that doesn't match a certain proposal. We have to be pragmatic. A pragmatic approach to named graph semantics IMO would be: formalize the "data management" semantics as the default - names address graphs, graphs are just ordinary chunks of RDF data - and add a facility to specify other semantics on demand. Plain and simple IMHO.

One use case for quote triples is referring to triple as triples - the "syntactic case". "Triple was added to database" as used in bitemporal modelling for "as it was recorded", different to when a fact was original asserted.

The challenge that I see is what is the reasonably minimal building block.

Define reasonably. The quoted triple as defined by the CG report is indeed minimal. The downside however is that the overwhelming majority of use cases will have to add another triple to refer to an occurrence, and two more triples to implement the TEP. All that for the sake of a very specific use case and an unwillingness to tackle the type/instance problem (which will not go away, ever). This is a design that is minimal in what it achieves, but maximal in the trouble it causes. Reasonable? Hardly.

I can only repeat that I find the graph literal datatype as proposed by Antoine Z. and before by Ivan H. much more convincing as a way to satisfy the need for syntactically faithful representations of triples: it has clear and intuitive semantics that even a novice user will immediately understand, it represents a minimal extension to RDF, it perfectly captures the meaning of blank nodes if the graph captures the whole CBD. What more could you want?

[TallTed]

@rat10 (and others) — Please avoid the temptation to use every acronym/abbreviation available to you without linking to the meaning you intend. I stumble over many of these, even when I have known their (typical) meaning for years, significantly but not only because they are not always used for that meaning.

TEP? Probably but not certain to have been intended to mean rdf-star:TransparencyEnablingProperty, as defined in § 7.2 Extended vocabulary of the RDF-star and SPARQL-star Final Community Group Report 17 December 2021.

CBD? Probably but not certain to have been intended to mean Concise Bounded Description, which has very limited validation as a W3C Member Submission ("This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process.")

Even the recent citation of the Named Graphs paper was challenging to run down. I think this link gets what was intended. I note that there is no official W3C Standard or Draft for Named Graph, though there does exist a W3C Editor's Draft.

[afs]

"Named Graph" was introduced in SPARQL in the definitions section

• https://www.w3.org/TR/rdf-sparql-query/#sparqlDataset
• https://www.w3.org/TR/sparql11-query/#sparqlDataset

It is in RDF Concepts where it was generalized: https://www.w3.org/TR/rdf-concepts/#dfn-named-graphs

[rat10]

@TallTed This is a discussion board. I don't need to treat entries here with the same diligence than a mail to the list. TEP and CBD have already been discussed in meetings and on the mailinglist, the Named Graph paper is easy to find with the information I gave. The TEP is the only bridge the proposed semantics provides to implement referentially transparent embedded triples, so the acronym should be familiar to anyone with a passing interest. The concept of CBDs has been around more than 20 years now, and I do even write it out half of the time I use it. I think that if you are a member of an RDF 1.2 WG you should feel compelled to look these acronyms up if you don't know them already, and you should be able to disambiguate the correct reference from any other Google result on "TEP" or "CBD" (if there are any). That much I think can be expected from participants in this discussion.

[lars-hellstrom]

@rat10

This is a discussion board. I don't need to treat entries here with the same diligence than a mail to the list.

Actually, I'd say it's the other way around. A mailing list, even if it does get archived, is an ongoing conversation which the subscribers are following; if you don't understand, you can ask. An issue tracker is far more something that will see renewed interest much later, when a poster need not be around anymore. In particular, due diligence before posting an issue is that one at least scans old issues to check if one's own issue is a duplicate of an old issue. That's hard to do if the comments are too obscure.

I think that if you are a member of an RDF 1.2 WG you should […] That much I think can be expected from participants in this discussion.

The published public draft for RDF 1.2 concepts refer to this tracker for feedback. It would be wrong to assume it is only visited by WG members.

[rat10]

@lars-hellstrom Okay, I'll take that into account in future posts. Still, my feeling is that too much of these formal demands rather stiffle discussions than enabling them. And is the mailing list now not anymore considered part of the conversation that I can rely on that readers know about? I did recently write a really exhaustive review of the TEP after Olaf asked me to. Do I have to link to that every time I mention the TEP in this issue tracker?

[doerthe]

To come back on the discussion: As far as I know there are multiple semantics for named graphs which are all implemented. So, if we want to bind rdf-star to named graphs we would need to fix their semantics. Given the discussions we already have here and the fact, that the multiple semantics are captured in a WG-report (that is: there was a discussion), I am not as optimistic as @rat10 that we would come to an agreement.

I'd like to be wrong here :)

I think we first need to fully understand the use cases and decide based on these where (not) to go.

[lars-hellstrom]

@afs wrote:

I'm sure a NGS design could be done. (NGS = Named Graph Singleton")

Do you mean "implementing quoted triples in terms of named graph singletons"? (Feels like 'singleton' should be qualifying 'named graph' rather than the other way around, but whatever.)

Effectively that would mean that in Turtle-star, the quoting << … >> is like [ … ], except that the implicit blank node becomes the name of a size 1 graph rather than the subject of some number of triples.

That violates the spec in that quoted triples are no longer distinct from blank nodes. (I'm not sure whether thinking of them as being drawn from a separate namespace makes sense, especially not when considering dataset isomorphism.)

A naive implementation also violates the spec in that multiple quotations of the same triple might generate new blank nodes representing the same quoted triple, but I suppose you could get around that by keeping a table of named graph singletons and always picking the first match from that table. (What if someone explicitly created a named graph singleton, though — would that be appropriated to represent the quoted triple?)

Finally this would allow for creating data structures that indistinguishable from cyclic quotations:

_:cycle {
   :foo :bar << :baz :bar _:cycle >> .
}
_:cycle2 {
   :baz :bar << :foo :bar _:cycle2 >> .
}

So it seems such a design has some issues to nail down.

But the point of my original question was: What do you (the WG) say to an implementor (not me) who feels quoted triples ought to work in that way? Why shouldn't it be correct?

@rat10

The point is nesting. Then different levels can have different purposes. The outermost named graph could still be used for data management.

Is this the data structures versus structured data distinction? (And it's probably called something else in the CS literature, sigh.) The programming language mainstream don't bother to support composite values, because there are tools (such as cons cells) for building data structures into which you can store as many atomic values as you wish, by allocating dynamic memory as needed. This is not quite the same as proper composite values (a difference that becomes apparent when you work with computer algebra), but the opinion which seems to be dominant among language designers is that it should be enough.

Just like on a heap you can build data structures nested to whatever depth you want, named graphs with blank node names can in principle represent nesting to whatever depth one wants. The Turtle serialisation may not show that nesting, but you could regard << … >> as syntactic sugar, for the inline construction of a separate named graph while you're asserting triples of some other graph. Logical RAM being flat does not prevent nesting, and nor would quadstores being flat.

But does the WG want to do it that way, or do you want it to not be done that way?

[rat10]

@lars-hellstrom

@rat10

The point is nesting. Then different levels can have different purposes. The outermost named graph could still be used for data management.

Is this the data structures versus structured data distinction? [...]
Without properly understanding what you refer to: no.
Just like on a heap you can build data structures nested to whatever depth you want, named graphs with blank node names can in principle represent nesting to whatever depth one wants. The Turtle serialisation may not show that nesting, but you could regard << … >> as syntactic sugar, for the inline construction of a separate named graph while you're asserting triples of some other graph. Logical RAM being flat does not prevent nesting, and nor would quadstores being flat.

I was alluding to the syntactic issue. For one, replacing <<...>> with nested {...} makes for a much saner syntax. It also makes the question obsolete what the difference between << :s :p :o >> and { :s :p :o } might be - there shouldn't be one IMO. It also solves the question of quoted graphs, i.e. "why don't we have << :s :p :o. :x :y :z>>?" because we would have {:s :p :o. :x :y :z} just as well. This makes navigating and querying much more straightforward, as there would be no need to e.g. check for the provenance of a statement twice: as an annotation on a quoted triple or on the named graph containing it. Blank nodes would be local to graphs, as in Pat Hayes' BLogic proposal (see this PDF for an introduction) and that way able to avoid some of the contortions in the CG semantics.
There is some experience already with Notation3 (N3) nested graphs - 2 decades and quite some research, however no large scale usage. Still, compared to RDF-star the Notation3 proposal seems like well explored territory. I would however very strongly suggest that the default semantics for such nested graphs don't follow any special use case, like in N3 or the original Named Graph proposal by Carroll et al 2005, but contend themselves with the standard RDF semantics of referential transparency. Also graph naming semantics should default to what SPARQL suggests: the name addresses the graph. Anything more - like overloading the graph name with references to a thing in the real world or its closure under some entailment regime, or specifying a different semantics for the graph - should be possible to express (and supported by syntactic shortcuts, like {:opaque | :s :p :o} just as an example), but as an extra, in 80/20-style. I never understood why the RDF 1.1 WG wasn't able to agree on such a bare-bones common denominator, but it's never to late, isn't it? ;-)
Implementation would still be based on quad stores and the details - if each statement has an identifier and for each identifier there is a second statement, or a separate entry in an extra table, that records its graph membership(s), or the nesting of graphs is recorded via extra triples - don't need to be discussed here. Amazon Neptune seems to go this route already and there is certainly more than one way to do it.

[EDIT] The reasons why we are discussing RDF-star today and not Notation3 or other approaches to Named Graphs are IMHO largely social and "political". The discussions in the RDF 1.1 WG must have been intense, judging from the mailinglist archive, and it seems that nobody wants to get burned again with that topic. But OTOH a few years ago also only very few people would have thought that a proposal like RDF-star that requires some mayor tweaking in the installed base (specs, serializations and code), would garner such wide support. IMO that support is foremost an expression of a desire to get a sound and concise meta-modelling mechanism, but not very specific to the RDF-star proposal itself. When I ask people why they like RDF-star, or hope for it, they mostly are not aware of its pitfalls and consequences. They just hope for some rubber-stamped solution that they can use for what they actually care about.
There is some reluctance to jeopardize the momentum of support with a switch away from RDF-star. That's what I mean with "political", but my political instincts tell me that it is possible and that in the end everybody will be very happy if this WG arrives at a well-rounded solution, not another lukewarm compromise.

[niklasl]

In trying to understand the possible relationships between quoted triples and named graphs (as I elaborated upon here), I think the notion of "graph literals", denoting themselves, help. It appears to me that the reason for not defining semantics of named graphs has been about the relation between a graph and its name, not "what a graph is". The graph is already defined as a set of triples.

A named graph could be just (in Notation 3, where a formula are "literals which are graphs themselves"):

<g1> rdfg:nameOf { <s> :p "o" . } .

(Note: In an imagined future where TriG 1.X acquired such a syntax it would be nigh ambiguous with named graphs, so perhaps some "quotation" marker, such as %{ .... } would be necessary.)

This also makes it possible to define subproperties of rdfg:nameOf, e.g. :denotes rdfs:subPropertyOf rdfg:nameOf, owl:sameAs ., or :believes rdfs:subPropertyOf rdfg:nameOf, rdfs:domain foaf:Person ., to represent the various notions of "naming".

Such "graphs themselves" would be opaque until explicitly linked together, with "transparency enabling"properties" between named graphs. This is exactly like how named graphs in a dataset are often managed in practise, just with explicit semantics.

But what would such graph literals mean in the default graph of an implicit or explicit dataset, or "within" a named graph? This is where opacity is an issue. Are graph literals "visible" there? Named graphs are not. as I understand it. So I would define them as not, until "enabled". Within a graph that "enabling" could be done with rdf:type, e.g. rdfg:NeutralGraph or even rdfg:NegativeGraph. (This is what RDF surfaces is about, and has a precursor in the old RDF Graph Literals and Named Graphs Note.)

Another question is whether a quoted triple is such a singleton graph (one statement), or still contained by it? As I mentioned in the referenced email, RDF 1.1 semantics state:

A subgraph of an RDF graph is a subset of the triples in the graph. A triple is identified with the singleton set containing it, so that each triple in a graph is considered to be a subgraph. A proper subgraph is a proper subset of the triples in the graph.

Given that plus a notion of graph literals gives us a yes, they are identical. This sets it even further apart from a reified statement though, which could, IIUC, be defined as unique, given OWL, with rdf:Statement owl:key (rdf:subject rdf:predicate rdf:object). And you can "point into" such triples (x:nameOfTheSubject owl:propertyChainAxiom (rdf:subject foaf:name)), since they are fully transparent but still "neutral". I haven't seen any need for that expressed in use cases for RDF-star triples though; I have seen more need for being able to map old reified forms into qualified descriptions though (e.g. for mapping a bf:Contribution to dc:contributor). (I personally wouldn't mind a graph literal typed as rdf:Statement to magically turn into such though, but I'd have to work to argue for it.)

There are practical questions in play too. Given that named graphs are what is currently managed as "units of description" in quad stores, it would be necessary to make some room for these self-denoting graphs. Given that room is already being required for quoted triples I think it would be beneficial to consider this larger question of "nested graphs". Technically, a "special URI" made by uniquely hashing its canonicalized ntriples representation (e.g. like <urn:tdb:2014:urn:sha256:fed610a12857801b8fed465951e8dbb3d3a4a03f2933dd146a897cd0ded87ea9>), can be to conceptual graphs what skolemization is to bnodes (and I believe quoted triples are often implemented something like that in practise). This has the upshot of everything in RDF still being possible to flatten to just RDF 1.1. NQuads, with no new syntax for that (unless the special URI is desired to be very special, and not just a protocol).

Storing such as actual specially-named graphs in separate "documents" or "contexts" could work in existing implementations as is (with some code wrangling, cf. how we handle bnodes, especially RDF lists). But it may be untenable for lots of small graphs (see e.g. this performance assessment). This is also a lot of overhead for the case of annotated triples (both asserted and quoted). This may be another practical reason for keeping single triples within the same "graph storage unit". But I think that's an implementation detail. (At the National Library of Sweden we store RDF as just JSON-LD, so we basically side-step all of that (at a cost). This of course has a lot of bearing upon my view of RDF data as "raw", with all entailment happening upon that.)

Some more motivation to think along these lines is that quoted triples quickly blow up syntactically when you need to talk about, i.e. quote, facts like:

<bob> :knows [ a :Person ; :name "Mary" ] .

or:

<abc> :hasOrderedParts (<a> <b> <c>) .

And we still need separate graphs to capture things like:

<ng1> { <mary> a :Person ; :name "Mary" . }
<ng2> { <mary> :name "Mary" . }
<ng2> rdfg:subGraphOf <ng1> .

With all this said, I must stress that we have a need for quoted triples, often also asserted, i.e. annotated triples. But as we use named graphs for all provenance management (including data from other sources), I strongly believe these ought to be explicitly co-defined in RDF 1.2, and not just being "different" in an undefined way. See e.g. json-ld/json-ld-star#45 for more thoughts and needs. (Also, see this wikidata experiment for related use of annotations for provenance.)

[rat10]

In trying to understand the possible relationships between quoted triples and named graphs (as I elaborated upon here),

A post that IMO didn't get the attention it deserves. However, to answer the main question: many people just don't want to get "there" again - "there" being named graphs and all the stressful disagreement around them. A truce was called in RDF 1.1 that left many people unsatisfied, but is a truce nonetheless. IMO this is a social issue rather than a technical one. A technical solution that just adds to what we have now, without disturbing anything that exists, is perfectly possible. But there is a very outspoken reluctance to go there. Just check recent WG minutes, 15.6.23 and 22.6.23. The RDF*/star CG didn't engage in discussing the issue, instead taking Olaf's dictum that the two approaches are "orthogonal" as the last word on it.

A named graph could be just (in Notation 3, where a formula are "literals which are graphs themselves"):

<g1> rdfg:nameOf { <s> :p "o" . } .

(Note: In an imagined future where TriG 1.X acquired such a syntax it would be nigh ambiguous with named graphs, so perhaps some "quotation" marker, such as %{ .... } would be necessary.)

This also makes it possible to define subproperties of rdfg:nameOf, e.g. :denotes rdfs:subPropertyOf rdfg:nameOf, owl:sameAs ., or :believes rdfs:subPropertyOf rdfg:nameOf, rdfs:domain foaf:Person ., to represent the various notions of "naming".

Basically: yes. The graph name "identifies" a graph. It doesn't necessarily denote it, but may mean something else. That is in line with the muddled way how identification works on the semantic web in general (some background). It just gets more apparent here because the thing addressed is not a thing in the real world or a resource on the web (e.g. an HTML document) but another piece of RDF data.

Such "graphs themselves" would be opaque until explicitly linked together, with "transparency enabling"properties" between named graphs. This is exactly like how named graphs in a dataset are often managed in practise, just with explicit semantics.

This I can't agree with. IMO an RDF 1.1 named graph, lacking any further specification, can only be assumed to be referentially transparent, just like any other set of triples, because that is the way RDF is defined. Can you explain how you come to the conclusion that in practice they are managed to be referentially opaque?

But what would such graph literals mean in the default graph of an implicit or explicit dataset, or "within" a named graph? This is where opacity is an issue. Are graph literals "visible" there? Named graphs are not. as I understand it. So I would define them as not, until "enabled". Within a graph that "enabling" could be done with rdf:type, e.g. rdfg:NeutralGraph or even rdfg:NegativeGraph. (This is what RDF surfaces is about, and has a precursor in the old RDF Graph Literals and Named Graphs Note.)

I'm pondering a design in which RDF 1.1 named graphs are left as they are (of course a vocabulary to describe their intended or application-specific semantics should be added), but nested graphs - using curly brackets as well - would be defined with a clear (and configurable) semantics.

[...]

Technically, a "special URI" made by uniquely hashing its canonicalized ntriples representation (e.g. like <urn:tdb:2014:urn:sha256:fed610a12857801b8fed465951e8dbb3d3a4a03f2933dd146a897cd0ded87ea9>), can be to conceptual graphs what skolemization is to bnodes (and I believe quoted triples are often implemented something like that in practise).

From what I heard they are rather implemented as triples with an identifier and a special marker. Maybe that "special URI" is the identifier? Well, implementation detail...

[...]

With all this said, I must stress that we have a need for quoted triples, often also asserted, i.e. annotated triples. But as we use named graphs for all provenance management (including data from other sources), I strongly believe these ought to be explicitly co-defined in RDF 1.2, and not just being "different" in an undefined way. See e.g. json-ld/json-ld-star#45 for more thoughts and needs. (Also, see this wikidata experiment for related use of annotations for provenance.)

My proposal to the WG would be to say that RDF 1.1 named graphs are meant to implement application-specific semantics. RDF currently provides no means to explicitly describe their meaning, but such a facility could (and IMO should) easily be added. Nonetheless there are things that RDF is too weak to do and that can only be achieved through out-of-band means. That's what RDF 1.1 named graphs are for, and should remain to be used for (in the absence of any other grouping mechanism they also are and will be used as an optimization technique for purposes that RDF could do, albeit only on a singleton level - one of the downsides of the proposed singleton <<...>> approach and the reason why I would favor nested graphs).

Any solution - quoted triples, or nested graphs or a singleton property-based triple identification mechanism or what have you - should have clearly defined default semantics (asserted referentially transparent occurrences IMO) and a syntactically concise mechanism to define other semantics. And any solution has to be able to be mapped to an n-ary relation in an unambiguous way - flattened in your words - to guarantee compatibility with RDF 1.1.

[lars-hellstrom]

@rat10 wrote

I was alluding to the syntactic issue. For one, replacing <<...>> with nested {...} makes for a much saner syntax.

I agree it's nicer, but wouldn't braces for quoting get into trouble with SPARQL's use of braces for grouping? I'm thinking specifically about group patterns. Even if the context of a group pattern can be proved sufficiently distinct from the context of an RDF term that there is no confusion, one would still have to parse a lot of text before being able to determine which it is, if both use braces.

Blank nodes would be local to graphs, as in Pat Hayes' BLogic proposal (see this PDF for an introduction) and that way able to avoid some of the contortions in the CG semantics.

That PDF rather seems to suggest the blank nodes are local to graph surfaces, where a graph surface may contain multiple graphs, so no change from the current state of affairs in that respect. (I've come across a scheme for signatures of graphs that would put the blank node naming the graph to sign inside the signature graph, but also the blank node naming that signature graph inside the signature graph, so merely nesting graphs would not suffice for that scheme. Then again, I don't know if it was a good scheme.)

[lars-hellstrom]

@niklasl wrote:

Another question is whether a quoted triple is such a singleton graph (one statement), or still contained by it? As I mentioned in the referenced email, RDF 1.1 semantics state:

A subgraph of an RDF graph is a subset of the triples in the graph. A triple is identified with the singleton set containing it, so that each triple in a graph is considered to be a subgraph. A proper subgraph is a proper subset of the triples in the graph.

I think this is a red herring. That 'is identified' has the smell of something an author writes because they don't want to burden the presentation with extra formalia (or themselves with having to write out those formalia), not something that logically means anything. The classical example is to identify the letter a with the length 1 word/string a: it simplifies your notation, but you don't want to do that in your formal construction of words on a given alphabet.

Storing such as actual specially-named graphs in separate "documents" or "contexts" could work in existing implementations as is (with some code wrangling, cf. how we handle bnodes, especially RDF lists). But it may be untenable for lots of small graphs (see e.g. this performance assessment).

That assessment is annoyingly void on details on how they actually store the quoted triples. For the other approaches they refer to Reifying RDF: What works well with wikidata, whose authors give plenty of details, but for quoted triples there is just "our product does this today". Also the dataset appears not to have any nesting of quoting, which could be skewing the assessment.

This is also a lot of overhead for the case of annotated triples (both asserted and quoted). This may be another practical reason for keeping single triples within the same "graph storage unit".

You're thinking the asserted and the quoted forms of a triple should share storage? Oh well, implementation details, I suppose.

One interesting example mentioned in that Reifying RDF paper is the presidencies of Grover Cleveland. In Wikidata there were (at least at the time) two edges asserting Grover Cleveland was president of the United States, corresponding to his two non-consecutive terms as president, and these could be distinct by virtue of having different start time and end time annotations. In RDF, an edge is just a triple, no matter what assertions might have been made about that triple. This corresponds neatly to the RDF-star spec that << :s :p :o >> is always the same RDF term with the same value, no matter how many times you say it. There's probably an illustrative example that can be made out of this, which would be well placed in rdf-concepts.