Matching patterns inside quads: Variable components in Quad pattern terms of match()

[jeswr]

Context

With RDF 1.2, datasets contain reified statements whose triple terms have internal structure, and a common need is matching on that structure — e.g. all ?r rdf:reifies <<( :s ?p ?o )>> statements. The RDF/JS match() contract (DatasetCore.match, Store.match, Source.match) only defines null/undefined as the per-argument wildcard, and quad matching is defined via .equals — so a Quad passed as a pattern term can only match exactly. There is no way to express a wildcard inside a Quad pattern term, because Quad components must be terms.

Proposal

Document/sanction the following interpretation of pattern arguments (no change to Quad.equals/Variable.equals — cf. the concerns in rdfjs/data-model-spec#162; only match()'s interpretation of its arguments changes):

• A Quad pattern argument containing a Variable component (at any depth) matches structurally: concrete components must be term-equal, Variable components match any term in that position, nested Quad components recurse.
• A variable-free Quad pattern argument keeps exact-equals semantics.
• Occurrences of the same variable are independent wildcards (join semantics belong to a bindings-level API, not match).

Precedent

• rdf-stores.js implements exactly this shape (dedicated quoted-triple indexes; variables as independent wildcards).
• Comunica already has a consumer contract for it: sources advertising features.quotedTripleFiltering receive quoted patterns in match() directly; others get variables nullified plus post-filtering.
• SPARQL 1.2 uses variables as the nested-wildcard mechanism in the query grammar.
• Question: Does DatasetCore.has support wildcards? dataset-spec#70 notes implementations can go beyond the spec's minimal matching.

N3.js is adding this in rdfjs/N3.js#633 (adopting the rdf-stores.js semantics so behaviour is aligned across implementations); it would be good to record the shared semantics at the types/spec level — e.g. widening the pattern-argument types/documentation on match() — so sources can implement it consistently and consumers can rely on it.

Open sub-questions worth settling here: whether top-level Variable arguments to match() should also act as wildcards (rdf-stores.js normalizes them to undefined; N3.js currently treats them as non-matching), and where same-variable join semantics should live.

[rubensworks]

I agree we should add something like this.

While the nested matching in match can be tricky for implementors to implement in an efficient, this complexity will only exist for implementations that support the indexing of nested triple terms. So for pure RDF 1.1 implementations, there will be no change related to this. (unless we also incorporate the suggested top-level variable matching for same variables, which would be a breaking change AFAICS)