A Virtual Special Find — the reconstructed whole-object node in Extended Matrix — is by design composed of contained Special Finds, the documented physical fragments the reconstruction is built from. Many of the properties the modeller wants to assert on the VSF are not independent assertions: they reach into the contained SFs and pull information up. Material is the canonical example — if a VSF is a marble Doric capital and all its contained SFs are marble fragments, the VSF’s material is marble because the contained SFs’ material is marble, not as a fresh assertion supported by independent evidence. Today there’s no way to express that semantics: the modeller has to either re-author the property on the VSF (duplicating the paradata chain that lives on the SF) or leave the VSF property empty and rely on the reader to infer the inheritance. Both options lose information about the structure of the modeller’s reasoning.
DP-66 introduces two new edge types that close this gap cleanly, both grounded in established external vocabularies (PROV-O for inheritance, CRMinf for premise reuse) that the v1.6 RDF integration is already adopting through em.ttl. The clean architectural insight that emerged through a thought-experiment iteration in conversation 2026-06-08: there are exactly two ways a contained-unit property can flow up to a container-unit property, and both are needed, and neither one involves running the contained property through an Extractor. The naive design — extend the extracted_from edge to accept PropertyNode as a source, treating a property as a kind of generalised “evidence” — turns out to be the wrong shape. A property is not raw evidence; it is already an interpreted statement about an attribute of a stratigraphic unit. Re-interpreting it through another Extractor would be crminf:I7_Belief_Adoption operating on the output of a previous crminf:I7_Belief_Adoption, which has no semantic interpretation in the CRMinf model. The rule “Extractor consumes only Documents; Property is reused via Pattern 1 or feeds a Combiner via Pattern 2” is a clean type-discipline that falls out of CRMinf, not an arbitrary restriction.
Pattern 1 — pure inheritance. The container’s property asserts the same value as the source’s property, verbatim. There is no Extractor or Combiner of the container’s own; the container is pointing at the source’s existing paradata chain and saying “I assert the same thing for the same reasons”. The data-layer expression is a new edge was_derived_from (PropertyNode → PropertyNode) that maps to prov:wasDerivedFrom in RDF — PROV-O’s standard predicate for “value Y derived from value X”. The authoring surface is a syntactic shortcut: when the modeller writes material@SF10 as the name of a PropertyNode on the VSF, the s3dgraphy importer splits the string on @, creates the PropertyNode named material, and creates a was_derived_from edge from this new PropertyNode to SF10.material. The verbatim string material@SF10 is preserved on attributes['display_name'] so the yEd round-trip stays byte-identical (same preserve-original-plus-edge pattern DP-62 established for the localized unita_tipo codes — the original lives on the attribute slot, the structural edge captures the canonical semantics for consumers). On read, a Heriverse exporter, a SPARQL query, or any other consumer walks the edge and reaches the source’s full chain (Document → Extractor → Combiner) transparently, with no duplication of paradata anywhere in the graph.
Pattern 2 — premise reuse. The container computes a new value through its own Combiner, but the Combiner’s premises include properties of contained nodes alongside (or instead of) Extractor-derived premises from the container’s own Documents. The canonical example: a column reconstruction VSF whose height is computed via formula from the diameters of its contained SF fragments. Each SF’s diameter is already a mature property of that SF (someone measured the fragment, the measurement is documented, the SF has its own diameter PropertyNode with its own chain). The VSF’s height is not the same value as any single diameter — it is the output of an inference, parameterised by an archaeological formula relating diameter to height for the relevant column order. The right shape is: the VSF.height PropertyNode hangs off the VSF’s own Combiner; the Combiner takes the SFs’ diameter PropertyNodes as direct premises via a new edge is_premise_of (PropertyNode → CombinerNode), which maps to crminf:J5_used_as_premise in RDF. The Combiner also takes input from the VSF’s own Extractor (which captures the formula’s documentary basis — the petrology / architecture standards reference). On the consumer side, a SPARQL query ?combiner crminf:J5_used_as_premise ?p returns every property playing a premise role in any inference, with the chain reachable both ways (premise → combiner → result, and result → combiner → premise).
The architectural rule that emerges: a PropertyNode plays two distinct roles in the paradata graph. As an output, it is the assertion produced by its own chain (Document → Extractor → Combiner → PropertyNode), which is the only configuration today. As an input to another node’s reasoning, it can either be (a) referenced directly via was_derived_from (Pattern 1, pure pointer, no Extractor or Combiner needed at the consumer side because the value is the same) or (b) consumed as a premise of another Combiner via is_premise_of (Pattern 2, the property is one of several inputs to a fresh inference). What it cannot do is be the source of an Extractor — the extracted_from edge stays Document-only. Drawing the wrong edge in yEd or asserting it in code raises a validation error at parse time, with the diagnostic message “A property is already a mature belief — use @<source> for pure inheritance (Pattern 1) or is_premise_of to feed it into a Combiner (Pattern 2)”. The rule is principled, not arbitrary: it falls out of the CRMinf separation between I7_Belief_Adoption (which acts on raw evidence) and I5_Inference_Making (which acts on already-adopted beliefs).
Containment scope and cycle detection. The MVP enforces that the source PropertyNode in either pattern belongs to a node in a containment relationship with the target node — for the canonical VSF/SF case, this is the membership of the SF inside the VSF’s container group node (DP-43). Cross-graph references or arbitrary-node-pair derivations are out of scope; they would dilute the semantic meaning of the inheritance (“I assert X because the unit I contain asserts X” has very different epistemic weight from “I assert X because some unrelated unit in another part of the graph asserts X”). Cycle detection runs on the union of the new edges (was_derived_from and is_premise_of) at graph-save time, on GraphML import, and on reverse export — a property cannot transitively derive from itself either directly or through a Combiner chain. Offending cycles are reported through the GraphML Warnings panel (DP-43 surface).
Authoring affordances. Pattern 1 is authored primarily via the @<source> shortcut on PropertyNode names — fast, type-able, immediately legible. The explicit was_derived_from dashed edge in the yEd palette is available as an alternative for users who prefer to draw the relation graphically rather than encoding it in a name string; the two paths produce identical s3dgraphy graphs. Pattern 2 is authored only via the explicit is_premise_of dashed edge in yEd — no syntactic shortcut, because premise reuse is a genuine inferential derivation that deserves visual representation in the graph alongside the Combiner it feeds. The modeller draws an edge from the source PropertyNode (on a contained SF) to the Combiner that produces the target PropertyNode (on the container VSF), the same way they draw edges from Extractors to Combiners today.
Round-trip discipline and the 1.7 polymateric stretch. The same attributes['display_name'] preserve-on-attribute pattern from DP-62 keeps Pattern 1 round-trip byte-identical: the verbatim material@SF10 string survives yEd → GraphML → s3dgraphy → pyArchInit → GraphML → yEd without mutation. Pattern 2 round-trips through the new edge declarations in s3Dgraphy_connections_datamodel.json plus the existing GraphML d13 / pyArchInit rapporti machinery — the canonical-edges series (DP-62) already proved this multi-format byte-identity is achievable when the data layer is clean. The polymateric case (a single container property with multiple was_derived_from edges to different source properties, compounding their values) is deliberately deferred to 1.7: the value-resolution semantics (concat? labeled map? typed union?) deserve their own design call once the MVP single-inheritance shape has been stressed on real excavation data. For 1.6 MVP, attempting to attach two was_derived_from edges to the same PropertyNode produces a validation error suggesting either splitting into separate properties (material_main, material_secondary) or expressing the multi-source case as Pattern 2 (a Combiner aggregating the multiple SF materials into a derived compound).
Why this lands cleanly inside the v1.6 RDF integration. The two new edge types map onto external vocabularies the EM ontology layer is already adopting — prov:wasDerivedFrom is part of PROV-O, listed in em.ttl’s imports; crminf:J5_used_as_premise is part of CRMinf, the inference-modelling extension of CIDOC-CRM that the v1.6 datamodel work has been moving toward (Extractor already maps to crminf:I7_Belief_Adoption, Combiner to crminf:I5_Inference_Making). DP-66 is in this sense a natural extension of the v1.6 ontology track rather than a parallel architectural piece — once the new edges land in the datamodel JSON and the RDFExporter, every consumer of EM data through the SPARQL endpoint gets queryable inheritance and premise-reuse with no extra work. The StratiGraph excavations active during the 1.6 cycle are the natural beta testers: column-reconstruction Virtual Special Finds with non-trivial fragment counts are exactly where Pattern 2 shows up daily, and the multilingual recognition story (PR #22 / DP-63) makes the @ shortcut work uniformly whether the source PropertyNode’s name is material (English UI) or materiale (Italian UI).
1.6
Needed — a Virtual Special Find from a real excavation with ≥3 contained SFs, ideally a column reconstruction where Pattern 2 (height from fragment diameters via formula) and Pattern 1 (material inheritance) BOTH apply on the same VSF
Designed 2026-06-08 in conversation with the maintainer. Triggered by the recurring observation that a Virtual Special Find inherits properties from its contained Special Finds in two qualitatively different ways: (a) pure value transit (`material` flows up from a monomateric SF), and (b) computational synthesis (`height` of a column emerges from combining diameter measurements across fragments). The naive design — let an Extractor consume a PropertyNode as evidence — was rejected after a thought-experiment iteration: six concrete scenarios (material→stone-type, diameter→column-class, epigraph→deceased-name, scale-indicator→derived-dimensions, disagreement-override, derived-measurement) all collapse cleanly into either Pattern 1 (pure inheritance, no Extractor needed) or Pattern 2 (the property feeds a Combiner — never an Extractor). The CRMinf semantic anchor explains why: `I7_Belief_Adoption` (Extractor) adopts a belief from raw evidence (`Document`); `I5_Inference_Making` (Combiner) draws an inference from premises that are already adopted beliefs (`PropertyNode`). A property fed to `I7` would be `I7` on `I7` — adopt-a-belief from an already-adopted-belief — which has no semantic interpretation. The rule ‘Extractor accepts Document only; Property feeds Combiner only’ is therefore not an arbitrary restriction but a CRMinf-clean type-discipline. Open decisions deferred to review call: (1) error UX when the modeller draws an `extracted_from: PropertyNode → ExtractorNode` edge in yEd — proposing a validation warning with a one-click ‘convert to is_premise_of’ that retargets the edge to the Combiner if one exists, or suggests creating one. (2) The `@source` shortcut needs to handle disambiguation when multiple contained nodes share a name (rare; cf. DP-62 family-preference fallback). (3) Round-trip discipline on reverse-export to pyArchInit: pyArchInit has no native concept of inter-row property inheritance — DP-66 properties on a VSF map to the same `us_table` row's property cells, with the inheritance/premise edges *materialised* in s3dgraphy after re-import (round-trip restores the structure). Sketch: a side-channel column or convention in the `rapporti`-like JSON-encoded attributes column. Worth a separate iteration once Pattern 1+2 ship. Cross-refs: DP-60 (Paradata NodeGroup) wraps the inherited / premise-reused chains the same way it wraps native ones; DP-62 (canonical-edges) established the preserve-original-plus-edge pattern that `@source` reuses; DP-63 (multilingual @lang) is the sibling preserve-and-tag pattern on text content; DP-64 (viewport stratigraphic annotator) is the adjacent authoring-UX work — when DP-64 ships the drag-to-link gesture, a follow-up could extend it to drag-PropertyNode-onto-Combiner for Pattern 2 authoring; DP-43 (Group Nodes) defines the VSF container that hosts both VSF + contained SFs; DP-46 (Proxy Box Creator) + DP-50 (Surface Areale System) produce the proxies whose properties are subject to the inheritance/premise rules; DP-32 (Propagative Metadata System) is the resolver pattern the inherited paradata chains traverse on read.