The cheap shape for many small entities has no ACL and one ETag

[tophcodes]

Context for where this comes from: a personal memory palace on the pod, SKOS concepts mapped
onto spatial places, with many small placement entities per spatial region. Each placement
is a handful of triples.

The shape that falls out is many fragments (<#p-foo>) in few larger documents, because
that is the shape the storage model makes cheap. A document with no inner named graphs is
read with a fixed two store queries, and every inner named graph adds one on top, "2+N
in-process queries, and no fast path that skips the shelves" (src/resource.rs:457-462).
Fragments in the default graph cost nothing extra; inner named graphs cost 2+N.

Three things follow from that choice, and together they look like one pattern rather than three separate defects.

1. A fragment is not addressable. StorageSpace::resolve takes a request path
(src/space.rs:323), and the only thing the source does with a fragment is strip or refuse
paths that normalization would change (src/space.rs:328). Access control uses the same
unit: the ACL for /foo is /.aux/foo.acl, authorized by acl:Control on the subject
resource (docs/uri-space.md, the auxiliary table), and "that graph is the unit access
control decides about" (README.md:107). So a per-placement permission means a
per-placement document, and a per-placement document means one request per entity on read:
exactly the cost the fragment shape avoided. #4 makes a resource's named graphs
addressable and is still open; it says nothing about fragments.

2. One ETag, one contention point, for every fragment in the document. N3 Patch reaches only the resource's default graph and cannot name a graph (src/resource.rs:372, ADR-8), so every fragment of a document is written through that one surface. The validator hashes the resource's whole quad set (src/dataset.rs:539), so two clients patching two disjoint fragments of the same document hold the same If-Match value, and the second one gets a 412 for triples that never overlapped. Related: #10.

3. Convergent writes are designed and unimplemented (README.md:166, #92). The mechanism that would let (2) merge instead of refuse is not there yet.

What is not written down

No document says whether the fragment shape is the intended way to hold many small entities. docs/uri-space.md describes the request-target space and does not mention fragments at all; docs/architecture.md and README.md describe the resource-as-named-graph model and stop at the document. So the cheapest storage shape is also the one the pod can say the least about, and whether that is deliberate is recorded nowhere.

The questions

• Is the fragment shape the intended way to store many small entities, or is it just what happens to be cheap?
• If it is intended: how is fine-grained access control meant to work over it? Is per-fragment authorization out of scope, and is "cut into documents and pay the requests" the answer?
• If it is not intended: what is the intended shape for many small entities that does not pay 2+N per read?
• Is one shared ETag per document for concurrent fragment writes an accepted consequence, or something Merge concurrent writes instead of refusing them with 412 #92 is meant to remove?

No proposal here. Each of these is a decision rather than a missing feature.