s3dgraphy 1.6.0.dev17__tar.gz → 1.6.0.dev18__tar.gz

{s3dgraphy-1.6.0.dev17/src/s3dgraphy.egg-info → s3dgraphy-1.6.0.dev18}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: s3dgraphy
-Version: 1.6.0.dev17
+Version: 1.6.0.dev18
 Summary: 3D Stratigraphic Graph Management Library for archaeological and heritage applications
 Author-email: Emanuel Demetrescu <emanuel.demetrescu@cnr.it>
 Maintainer-email: Emanuel Demetrescu <emanuel.demetrescu@cnr.it>
@@ -35,6 +35,7 @@ Requires-Dist: pandas>=2.0.0
 Requires-Dist: lxml>=4.9.0
 Requires-Dist: openpyxl>=3.0.0
 Requires-Dist: networkx>=3.0
+Requires-Dist: dtcstamp>=0.1.0
 Provides-Extra: rdf
 Requires-Dist: rdflib>=7.0; extra == "rdf"
 Provides-Extra: rdf-embedded

{s3dgraphy-1.6.0.dev17 → s3dgraphy-1.6.0.dev18}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "s3dgraphy"
-version = "1.6.0.dev17"
+version = "1.6.0.dev18"
 description = "3D Stratigraphic Graph Management Library for archaeological and heritage applications"
 readme = "README.md"
 requires-python = ">=3.9"
@@ -51,6 +51,12 @@ dependencies = [
     "lxml>=4.9.0",              # used by graphml importer/exporter
     "openpyxl>=3.0.0",          # used by xlsx_importer
     "networkx>=3.0",            # used by temporal/inference_engine.py
+    # The stamp FORMAT — read, write, compare, walk — extracted so that a
+    # Blender add-on or a Metashape script can use it without installing any of
+    # the four above. It has zero dependencies of its own and is one module, so
+    # it can also simply be copied; s3dgraphy depends on it rather than
+    # vendoring it, because two copies of a format rule drift.
+    "dtcstamp>=0.1.0",
 ]
 
 [project.urls]

{s3dgraphy-1.6.0.dev17 → s3dgraphy-1.6.0.dev18}/src/s3dgraphy/JSON_config/datamodel_translations.json

@@ -124,7 +124,7 @@
   },
   "DTCAcquisitionNode": {
    "description": {
-    "en": "A DTC ACQUISITION chunk: the digital event by which an asset ENTERS this study from an (opaque, Tier-0) external source — a data-transfer / ingestion event, DISTINCT from the genesis DTCProcessNode. Projected as crmdig:D12_Data_Transfer_Event (a subclass of D7_Digital_Machine_Event, ⊂ prov:Activity): 'events that transfer a digital object from one digital carrier to another; normally the digital object remains the same' — the object arrives opaque, no genesis is asserted. Tier 0: single-ring chain — the acquisition event --dtc_had_output[prov:generated]--> the acquired Resource (ResourceNode); the upstream root is an opaque external entity recorded as literals on data (repo/record/agent/retrieved_at/rights), not a genesis sub-graph. data.dtc_kind from the `acquisition` axis (download / ingest / local_import). Keeps genesis != acquisition as distinct TYPES inside the one DTC substrate.",
+    "en": "A DTC ACQUISITION step: the digital event by which an asset ENTERS this study from an (opaque, Tier-0) external source — a data-transfer / ingestion event, DISTINCT from the genesis DTCProcessNode. Projected as crmdig:D12_Data_Transfer_Event (a subclass of D7_Digital_Machine_Event, ⊂ prov:Activity): 'events that transfer a digital object from one digital carrier to another; normally the digital object remains the same' — the object arrives opaque, no genesis is asserted. Tier 0: single-ring chain — the acquisition event --dtc_had_output[prov:generated]--> the acquired Resource (ResourceNode); the upstream root is an opaque external entity recorded as literals on data (repo/record/agent/retrieved_at/rights), not a genesis sub-graph. data.dtc_kind from the `acquisition` axis (download / ingest / local_import). Keeps genesis != acquisition as distinct TYPES inside the one DTC substrate.",
     "validated_it": false,
     "validated_el": false,
     "validated_he": false,
@@ -146,7 +146,7 @@
   },
   "DTCProcessNode": {
    "description": {
-    "en": "A DTC PROCESS chunk: the transformation/processing event that turns inputs into produced digital objects (data.dtc_kind from the `process` axis, e.g. transformation). Projected as a crmdig:D7_Digital_Machine_Event / prov:Activity; its inputs and outputs are the dtc_had_input (prov:used) and dtc_had_output (prov:generated) edges.",
+    "en": "A DTC PROCESS step: the transformation/processing event that turns inputs into produced digital objects (data.dtc_kind from the `process` axis, e.g. transformation). Projected as a crmdig:D7_Digital_Machine_Event / prov:Activity; its inputs and outputs are the dtc_had_input (prov:used) and dtc_had_output (prov:generated) edges.",
     "validated_it": false,
     "validated_el": false,
     "validated_he": false,
@@ -1097,6 +1097,22 @@
    "label": {
     "en": "Registration transform"
    }
+  },
+  "RepresentationModelNodeGroup": {
+   "description": {
+    "en": "Typed aggregation of the representation models that form ONE named set published under a single Document — «Survey 2015» under D.01, «Reconstruction» under D.09 (EM16-RMNG, meeting of 2026-09-10). Until then the RM container lived only as EM Tools' `scene.rm_containers` PropertyGroup, so the grouping that gives the set its meaning was invisible to anyone reading the graph. IT SITS BESIDE, IT DOES NOT REPLACE: every member keeps its own epoch edges (has_first_epoch / survive_in_epoch) and the Document keeps its DIRECT has_representation_model edges to each model — the group is added on top and never put in between, so a consumer that ignores it reads exactly what it read before. Membership is the TAG axis 'is_in_representation_model_group', like is_in_functional_unit and is_in_location, but 1:1 and not m:n: a mesh belongs to exactly one container, the rule already in force on the Blender side where `mesh_names` is authoritative. A group may legally be EMPTY and may legally have NO Document: both are states the RM Manager UI already shows. NOT a FunctionalUnitNodeGroup (that aggregates stratigraphic units into a building component; these members are models, not units); NOT an ActivityNodeGroup (nothing happened here and the set has no formation event of its own); NOT the Document, which stays the documentary anchor — deleting the container removes the group and not the Document."
+   },
+   "label": {
+    "en": "RM Container"
+   }
+  },
+  "DTCDeviceNode": {
+   "description": {
+    "en": "The APPARATUS a DTC step happened on — camera, sensor, drone, computer, scanner, total station, GNSS receiver. Projected as crmdig:D8_Digital_Device and attached to the EVENT by dtc_happened_on_device (crmdig:L12_happened_on_device), never to the input or the output: the three dtc_kinds flow axes are what went in, what happened and what came out, and a device is what it happened ON. Until 2026-09-16 it was a STRING inside how.acquisition, and a string cannot be asked «what did this machine produce» or «that lens was distorted, which models are affected». NOT a DTCNode: a DTC node is a STEP (an event in the chain) and a device is a thing in the world — it has no inputs, no outputs, and a provenance walk has no business entering it; subclassing would have put it in the chain by inheritance and set the class hierarchy arguing with dtc_role. data.dtc_kind comes from the `device` axis of dtc_kinds (em_visual_rules.json), so adding an apparatus is a JSON entry plus a sign. THE ID IS DERIVED FROM THE DESCRIPTOR (make | model | serial) by uuid5 — the same mechanism bucket_acquisition uses for a campaign name, but WITHOUT the graph_id in the key, because a campaign is an event of one study while the same camera in two studies is one camera. WHAT THAT COSTS, DECLARED: without a serial number two identical bodies derive the same id and MERGE, and the graph then cannot say which body took a given file. data.distinguishes records which happened ('serial' = one body, 'make+model' = a model). A declared merge is better than an invented distinction: salting the id with a graph or a timestamp would make two records of the SAME camera look like two cameras, and that failure is silent. Gated out of the stratigrapher palette, like every DTC node."
+   },
+   "label": {
+    "en": "DTC Device"
+   }
   }
  }
 }

{s3dgraphy-1.6.0.dev17 → s3dgraphy-1.6.0.dev18}/src/s3dgraphy/JSON_config/em_visual_rules.json

@@ -1,6 +1,6 @@
 {
   "formal_language": "EM",
-  "version": "1.6.16",
+  "version": "1.6.17",
   "_note_material_vs_qualia_color": [
     "DUE COSE DIVERSE CHE SI CHIAMANO ENTRAMBE color. Non confonderle: e gia successo.",
     "1) QUI, in node_styles.<tipo>.style.material.rgba_color — il COLORE DEL MATERIALE BLENDER del proxy 3D, in float LINEARI. UNA sola chiave: `rgba_color`. Fino a S8 il file ne usava due (`color` sui 13 tipi stratigrafici, `rgba_color` sugli altri) e get_material_color() ne leggeva una sola, restituendo None per 21 tipi su 38; ora sono unificate e la vecchia `color` e letta solo come tolleranza verso file scritti prima. Un tipo che non diventa mai una mesh NON ha material affatto (i contenitori di gruppo, e da S7 i dieci nodi che rendono per icona): per loro get_material_color() torna None, ed e corretto.",
@@ -9,7 +9,7 @@
     "In breve: qui si decide di che colore DISEGNARE una US; li si registra di che colore ERA."
   ],
   "_changelog": {
-    "1.6.16": "Asset declarations made TRUE. Four styles named a 2D file that is not there — SE.png, TSU.svg, serUSD.svg and unknown.png (which never existed) — and GRAPH named two, so it drew no icon at all. icons.ts returns null for a missing file and the canvas quietly draws the shape, so all five failed silently. Now: graph.svg authored (neutral gray, three nodes and their edges, the meta-container), unknown points at the generic_node.svg that exists, the three stale halves name the file that is there. Enforced by tests/test_visual_assets.py; the 16 unmodelled .glb are REPORTED (there and in sync-datamodels.sh), not asserted \u2014 a placeholder that looks official is harder to notice than an absence.",
+    "1.6.16": "Asset declarations made TRUE. Four styles named a 2D file that is not there — SE.png, TSU.svg, serUSD.svg and unknown.png (which never existed) — and GRAPH named two, so it drew no icon at all. icons.ts returns null for a missing file and the canvas quietly draws the shape, so all five failed silently. Now: graph.svg authored (neutral gray, three nodes and their edges, the meta-container), unknown points at the generic_node.svg that exists, the three stale halves name the file that is there. Enforced by tests/test_visual_assets.py; the 16 unmodelled .glb are REPORTED (there and in sync-datamodels.sh), not asserted — a placeholder that looks official is harder to notice than an absence.",
     "1.6.15": "Georeferencing gets its symbol on the canvas: node_styles GCP (GCPSetNode, crosshair) and RGT (RegistrationTransformNode, axes + rotation arc), in the same #FF6600 reference family as GEO/SS/LINK, each with its own 2D icon. ADDITIVE. Also 1.6.14-era: dtc_kinds.process.photogrammetry. Note the limit of a per-TYPE rule: whether a transform is georeferenced or a site-local frame is an INSTANCE fact (data.crs) and is read from the has_gcp_set edge, not from the style.",
     "1.6.14": "BUGFIX-GLYPH follow-up (2026-08-05, E.D.): SE now renders its GLYPH in the scene (the new SE.svg, a stratigraphic-section box with a writable middle band) instead of a bare triangle, so a name can be written inside it. Added SE to 2d_render_glyph_types (aspect 1.331 from the SVG viewBox) and switched SE 2d_icon_prefer to vector (the raster SE.png is the stale stipple; the new symbol is the SVG). Dropped the interim shape_bbox=square. The shape:triangle stays declared for other consumers but the 2D scene draws the glyph. NOTE: verify the SVG carries a light background for dark-canvas legibility (like combiner.svg).",
     "1.6.13": "BUGFIX-GLYPH (2026-08-05): SE (StratigraphicEvent) gains shape_bbox=\"square\" on its style, like BR. Its triangle was drawn in the wide default 90x32 box, leaving the connect handle far from the glyph; a square bbox (side = min(w,h)) makes the triangle sit in a ~32x32 box with the handle adjacent, matching BR (diamond, square) and the glyph types. No shape_scale: unlike BR (a 0.7 marker) the SE triangle stays full-size. The SCENE representation of SE remains the triangle shape, not the raster icon (S10/POL5 decision unchanged).",
@@ -29,7 +29,8 @@
     "1.5.3": "Fix USD / serUSD material colour: RGB was (0.549, 0.103, 0.0) = #8C1A00 (red), should be #D86400 (orange) to match the canonical USD documentary colour used in the GraphML palette template, node_registry defaults and document_variant_styles.observable. USD border_color also corrected from #8C1A00 to #D86400 (serUSD border was already correct).",
     "1.5.2": "Added RSF (Reused Special Find / spolia) node style — octagon, red border (#9B3333), white fill. Sibling of SF/VSF, distinguished by border colour. Originating DP: DP-26.",
     "1.5.1": "Added LocationNodeGroup node style (dashed roundrectangle, kind-based border colour) and is_in_location edge style with primary_modifier override.",
-    "1.5.0": "Initial EM 1.5 visual rules."
+    "1.5.0": "Initial EM 1.5 visual rules.",
+    "1.6.17": "Added RepresentationModelNodeGroup node style (EM16-RMNG): the group family's dashed roundrectangle with the RM family's #FF6600 title-tab, and the is_in_representation_model_group edge style. Additive only — no existing style touched, and the epoch↔RM / Document→RM edges keep the rendering they had."
   },
   "2d_render_glyph_types": {
     "_comment": "Node types the 2D renderer draws as a CENTRED GLYPH (their official icon) instead of a shape. Their box is HEIGHT-DRIVEN: the height is the engine node height and the width is that height times the `aspect` below (EM2 made them square; EM3 generalised the square to a per-glyph aspect). Keyed by RUNTIME node_type, deliberately: this block is read both by EMStudio's icons.ts and by its Rust layout engine, and a list keyed by node_type needs no alias table on either side (`node_styles` is keyed by the short abbreviation, EXT/COMB/..., which the engine does not know). Added in 1.6.11 (EM2) because the fact had been living as a hand-written set inside icons.ts, and the layout engine needs the same fact to give those nodes a height-driven box: a glyph drawn 32 wide inside a 90x32 box leaves empty margins, and the connect handle — anchored to the right edge of the box — ends up floating away from the glyph. NB two things this does NOT include. (1) `document` and `property`: they are drawn with custom geometry (a sheet with a folded corner, a bracketed text annotation) that is NOT square, and squaring their box would crush the text. (2) DTC nodes: their glyph is chosen per NODE from `data.dtc_kind` and not from the type, so a consumer decides that node by node — a plain `link` is not a glyph, a `link` with a dtc_kind is.",
@@ -790,6 +791,18 @@
           "description": "Interpretive / semantic identity (basilica, room A, courtyard)."
         }
       }
+    },
+    "RepresentationModelNodeGroup": {
+      "_comment": "Group-folder rendering for an RM container (EM16-RMNG): the named set of representation models a Document publishes — «Survey 2015» under D.01. Shape and frame are the GROUP family's, unchanged and deliberately not reinvented (roundrectangle, neutral grey fill, dashed black border) — what identifies the family is the group title-tab colour, exactly as cyan identifies ActivityNodeGroup, peach ParadataNodeGroup, green TimeBranchNodeGroup and grey LocationNodeGroup. The tab here carries #FF6600, which is the RM family's OWN border colour (see the RM / RMDoc / RMSF styles): the box reads as «a group of representation models» without a new shape and without a new colour being invented. Verified free before use: #FF6600 was not in use as a label_background by any other style, and is not among the colours the GraphML importer keys on.",
+      "style": {
+        "shape": "roundrectangle",
+        "fill_color": "#F5F5F5",
+        "border_color": "#000000",
+        "border_style": "dashed",
+        "border_width": 1.0,
+        "label_background": "#FF6600",
+        "label_position": "top"
+      }
     }
   },
   "document_roles": {
@@ -811,7 +824,7 @@
     }
   },
   "document_variant_styles": {
-    "_comment": "Axis 3 of the three-axis Canonical-Document classification (EM 1.6). Declares how the document's Representation Model (RM) is spatialized in the 3D scene. Q-C (EM 1.6): the axis is a scale of METRIC AUTHORITY OF PLACEMENT, and it is authoritative on the **RMDoc** — the spatial instance — not on the Document. The Document's existence is certain; what has degrees is its spatialisation, which is what the RMDoc IS (proxy:US :: RMSF:SF :: RM:state :: RMDoc:Document). The position itself (X,Y,Z + rotation) lives on the RMDoc and nowhere else; the Document may mirror the value on its yEd border for diagram convenience, but it carries no position. The ladder, from most to least metric authority: reality_based \u2192 observable \u2192 asserted \u2192 symbolic. `em_based` is not a rung of that ladder but a provenance statement (the asset IS an EM-derived reconstruction). Temporality is a separate matter: it is an attribution, certain or argued through a paradata chain, never a grade on this axis. The 'geometry' property drives both the GraphML DocumentNode border colour (in yEd) and the RM contour colour in the 3D viewport (per the v1.6 toggle). Documents without an RM (e.g. PDF articles, bibliographies) omit the geometry property entirely — no node, no colour. Border WIDTH carries the canonical/instance distinction: width >= 3.0 is the canonical document, anything thinner is a use-instance. The COLOUR classifies the canonical document's geometry-axis category. A black thick border means 'canonical without geometry classification' (canonical_unknown). Renamed from 'master' in schema 2: every digital document is a copy, so 'master' misread as 'original vs copies'; what the flag marks is the document drawn at its own creation, vs the instances that re-use it. Kept in sync with the reference nodes in templates/em_palette_template.graphml.",
+    "_comment": "Axis 3 of the three-axis Canonical-Document classification (EM 1.6). Declares how the document's Representation Model (RM) is spatialized in the 3D scene. Q-C (EM 1.6): the axis is a scale of METRIC AUTHORITY OF PLACEMENT, and it is authoritative on the **RMDoc** — the spatial instance — not on the Document. The Document's existence is certain; what has degrees is its spatialisation, which is what the RMDoc IS (proxy:US :: RMSF:SF :: RM:state :: RMDoc:Document). The position itself (X,Y,Z + rotation) lives on the RMDoc and nowhere else; the Document may mirror the value on its yEd border for diagram convenience, but it carries no position. The ladder, from most to least metric authority: reality_based → observable → asserted → symbolic. `em_based` is not a rung of that ladder but a provenance statement (the asset IS an EM-derived reconstruction). Temporality is a separate matter: it is an attribution, certain or argued through a paradata chain, never a grade on this axis. The 'geometry' property drives both the GraphML DocumentNode border colour (in yEd) and the RM contour colour in the 3D viewport (per the v1.6 toggle). Documents without an RM (e.g. PDF articles, bibliographies) omit the geometry property entirely — no node, no colour. Border WIDTH carries the canonical/instance distinction: width >= 3.0 is the canonical document, anything thinner is a use-instance. The COLOUR classifies the canonical document's geometry-axis category. A black thick border means 'canonical without geometry classification' (canonical_unknown). Renamed from 'master' in schema 2: every digital document is a copy, so 'master' misread as 'original vs copies'; what the flag marks is the document drawn at its own creation, vs the instances that re-use it. Kept in sync with the reference nodes in templates/em_palette_template.graphml.",
     "default": {
       "border_color": "#000000",
       "border_style": "solid",
@@ -858,32 +871,130 @@
   "dtc_kinds": {
     "_comment": "DATA-DRIVEN, EXPANDABLE per-kind vocabulary for the DTC substrate profile (ECHOES). Mirrors the Master-Document axis vocabularies above (document_roles/content_natures): the three base kinds (input/process/output) each list specific kinds seeded from the 2017 DTC palette. Adding a new kind (e.g. audio, spectroscopy) is a JSON entry here (+ a glyph) — NOT a code change; the DTC node classes validate against these keys via s3dgraphy.utils.get_dtc_kinds(). `glyph` names the 2017 DTC SVG (wired in the later glyph/visual-manager slice; recorded here as data only).",
     "input": {
-      "photo": { "label": "Photograph", "glyph": "09_photos", "description": "Photographic acquisition (single image or set)." },
-      "laserscanner": { "label": "Laser scan", "glyph": "10_laserscanner", "description": "Terrestrial/close-range laser scanning acquisition." },
-      "topographic": { "label": "Topographic survey", "glyph": "01_topographicnetwork", "description": "Total-station / topographic-network acquisition." }
+      "photo": {
+        "label": "Photograph",
+        "glyph": "09_photos",
+        "description": "Photographic acquisition (single image or set)."
+      },
+      "laserscanner": {
+        "label": "Laser scan",
+        "glyph": "10_laserscanner",
+        "description": "Terrestrial/close-range laser scanning acquisition."
+      },
+      "topographic": {
+        "label": "Topographic survey",
+        "glyph": "01_topographicnetwork",
+        "description": "Total-station / topographic-network acquisition."
+      }
     },
     "process": {
       "photogrammetry": {
         "label": "Photogrammetry",
         "glyph": "03_mesh",
-        "description": "Structure-from-motion reconstruction: a cluster of photographs becomes a 3D model. A specific kind of transformation, named because what a reader needs to know about a mesh is which family of process made it \u2014 and because the placement (RegistrationTransform) only means something for this one."
+        "description": "Structure-from-motion reconstruction: a cluster of photographs becomes a 3D model. A specific kind of transformation, named because what a reader needs to know about a mesh is which family of process made it — and because the placement (RegistrationTransform) only means something for this one."
       },
-      "transformation": { "label": "Transformation", "glyph": "00_transformation", "description": "A processing/transformation step turning inputs into produced digital objects." }
+      "transformation": {
+        "label": "Transformation",
+        "glyph": "00_transformation",
+        "description": "A processing/transformation step turning inputs into produced digital objects."
+      }
     },
     "acquisition": {
-      "download": { "label": "Download", "glyph": null, "description": "Retrieval of a digital object from a remote (opaque, Tier-0) repository." },
-      "ingest": { "label": "Ingest", "glyph": null, "description": "Generic ingestion of a digital object into the study." },
-      "local_import": { "label": "Local import", "glyph": null, "description": "Acquisition from the local file system (project-folder search) — the local analog of remote acquisition." },
-      "uri_reference": { "label": "URI reference", "glyph": null, "description": "The URI was acquired, not the object: the resource stays where it is and is reached through its own access protocol (an open link, or one you subscribe to). No bytes were copied — calling this a download would record a retrieval that never happened." }
+      "download": {
+        "label": "Download",
+        "glyph": null,
+        "description": "Retrieval of a digital object from a remote (opaque, Tier-0) repository."
+      },
+      "ingest": {
+        "label": "Ingest",
+        "glyph": null,
+        "description": "Generic ingestion of a digital object into the study."
+      },
+      "local_import": {
+        "label": "Local import",
+        "glyph": null,
+        "description": "Acquisition from the local file system (project-folder search) — the local analog of remote acquisition."
+      },
+      "uri_reference": {
+        "label": "URI reference",
+        "glyph": null,
+        "description": "The URI was acquired, not the object: the resource stays where it is and is reached through its own access protocol (an open link, or one you subscribe to). No bytes were copied — calling this a download would record a retrieval that never happened."
+      }
     },
     "output": {
-      "pointcloud": { "label": "Point cloud", "glyph": "02_pointcloud", "description": "Produced point cloud." },
-      "mesh": { "label": "Mesh", "glyph": "03_mesh", "description": "Produced 3D mesh model." },
-      "dem": { "label": "DEM", "glyph": "07_DEM", "description": "Digital Elevation Model." },
-      "orthophoto": { "label": "Orthophoto", "glyph": "08_ortophoto", "description": "Produced orthophoto / orthomosaic." },
-      "points": { "label": "Points", "glyph": "04_points", "description": "Vector point features." },
-      "lines": { "label": "Lines", "glyph": "05_lines", "description": "Vector line features." },
-      "polygons": { "label": "Polygons", "glyph": "06_polygons", "description": "Vector polygon features." }
+      "pointcloud": {
+        "label": "Point cloud",
+        "glyph": "02_pointcloud",
+        "description": "Produced point cloud."
+      },
+      "mesh": {
+        "label": "Mesh",
+        "glyph": "03_mesh",
+        "description": "Produced 3D mesh model."
+      },
+      "dem": {
+        "label": "DEM",
+        "glyph": "07_DEM",
+        "description": "Digital Elevation Model."
+      },
+      "orthophoto": {
+        "label": "Orthophoto",
+        "glyph": "08_ortophoto",
+        "description": "Produced orthophoto / orthomosaic."
+      },
+      "points": {
+        "label": "Points",
+        "glyph": "04_points",
+        "description": "Vector point features."
+      },
+      "lines": {
+        "label": "Lines",
+        "glyph": "05_lines",
+        "description": "Vector line features."
+      },
+      "polygons": {
+        "label": "Polygons",
+        "glyph": "06_polygons",
+        "description": "Vector polygon features."
+      }
+    },
+    "device": {
+      "_comment": "THE APPARATUS AXIS — what a step happened ON, not what went in or came out. crmdig:L12_happened_on_device, deliberately NOT L10_had_input: the photographs are the input and the camera is not, and flattening the two makes «which files did this body take» unanswerable, which is the only reason the node exists. One class (DTCDeviceNode, crmdig:D8_Digital_Device) and the genus from here, so adding an apparatus stays a JSON entry plus a sign — the same rule the flow axes follow. | THE GLYPHS ARE ONE FAMILY: 11_device is a rounded box with a connector on one side, the poorest shape that still says «apparatus» and free of any optical cue because a computer has no lens. Two boxes whose connectors touch read as a RIG — a computer with a sensor on it, a camera on a drone — which is how an assembly is said without inventing a second symbol. Every genus keeps that outline IDENTICAL and changes one inner mark, so the family reads from far away and the genus from close up. The SVGs live in JSON_config/src/2D/dtc/ beside 00–10; these names are declared here first and drawn separately. | NOTE FOR WHOEVER EXTENDS THIS: `laserscanner` sits on the `input` axis above, and now that this axis exists it is in the wrong box — a scanner is an apparatus, not an input. It is NOT moved: stamps already emitted carry that kind on that axis, and moving it would invalidate them in silence, which is the defect this whole substrate is built against. Left to E.D.",
+      "camera": {
+        "label": "Camera",
+        "glyph": "11_device_optical",
+        "description": "A photographic or video body. The circle is the GENUS mark and sits inside the family outline: the outline itself stays free of optics so a computer can wear it."
+      },
+      "sensor": {
+        "label": "Sensor",
+        "glyph": "11_device_sensor",
+        "description": "A measuring instrument that is not a camera — multispectral, thermal, a lidar head, a magnetometer. The wave mark says «it records a quantity»."
+      },
+      "drone": {
+        "label": "Drone",
+        "glyph": "11_device_drone",
+        "description": "The airframe that carried the apparatus. Its own device because it is the thing that flew, and a rig is drawn as its connector touching the payload's."
+      },
+      "computer": {
+        "label": "Computer",
+        "glyph": "11_device_computer",
+        "description": "The machine a processing step ran on. Here because «the reconstruction produced different numbers on the two workstations» is a question somebody will ask, and it is the reason the family outline had to stay free of optics."
+      },
+      "scanner": {
+        "label": "Scanner",
+        "glyph": "11_device_scanner",
+        "description": "A range or structured-light scanner — the APPARATUS. Distinct from the `laserscanner` entry on the `input` axis, which is a kind of input and is left where it is on purpose (see the note above)."
+      },
+      "total_station": {
+        "label": "Total station",
+        "glyph": "11_device_station",
+        "description": "A theodolite with a rangefinder — the instrument behind a `topographic` input."
+      },
+      "gnss": {
+        "label": "GNSS receiver",
+        "glyph": "11_device_gnss",
+        "description": "A satellite positioning receiver: the apparatus that produces a how.acquisition.location whose `source` is a measurement and not a person's word."
+      }
     }
   },
   "edge_style": {
@@ -1069,6 +1180,15 @@
         "width": 1.5
       },
       "label": "Included in Timebranch"
+    },
+    "is_in_representation_model_group": {
+      "_comment": "Membership of a representation model in an RM container (EM16-RMNG). Dashed like the other membership edges that are TAGS rather than structure (has_representation_model, has_property), and carrying the RM family's #FF6600 so the line reads as part of the same family as the group's title-tab. NOTE: is_in_functional_unit has no entry in this block — a pre-existing gap, reported and not fixed here.",
+      "style": {
+        "color": "#FF6600",
+        "line_style": "dashed",
+        "width": 1.5
+      },
+      "label": "Is in Representation Model Group"
     }
   }
-}
+}

{s3dgraphy-1.6.0.dev17 → s3dgraphy-1.6.0.dev18}/src/s3dgraphy/JSON_config/node_registry.generated.json

@@ -1,6 +1,6 @@
 {
  "_generated": "by `python -m s3dgraphy.tools.sync_node_datamodel` — DO NOT hand-edit. The flat class hierarchy (parent/node_type/description) is derived from the Python Node subclasses; hand-authored semantics and CIDOC mappings live in s3Dgraphy_node_datamodel.json.",
- "s3Dgraphy_data_model_version": "1.6.4",
+ "s3Dgraphy_data_model_version": "1.6.5",
  "node_types": {
   "ActivityNodeGroup": {
    "parent": "GroupNode",
@@ -37,10 +37,15 @@
    "node_type": "dtc_acquisition",
    "description": "DTC acquisition/ingestion event (ECHOES DTC profile, acquisition seam)."
   },
+  "DTCDeviceNode": {
+   "parent": "Node",
+   "node_type": "dtc_device",
+   "description": "The apparatus an acquisition or a processing step happened on."
+  },
   "DTCNode": {
    "parent": "Node",
    "node_type": null,
-   "description": "Abstract base for a DTC chain chunk. Concrete subclasses set ``node_type``"
+   "description": "Abstract base for one STEP of a DTC chain. Concrete subclasses set ``node_type``"
   },
   "DTCProcessNode": {
    "parent": "DTCNode",
@@ -177,6 +182,11 @@
    "node_type": "representation_model",
    "description": "Node representing a 3D model or spatialized image."
   },
+  "RepresentationModelNodeGroup": {
+   "parent": "GroupNode",
+   "node_type": "RepresentationModelNodeGroup",
+   "description": "Typed aggregation of the representation models that form ONE named set"
+  },
   "RepresentationModelSpecialFindNode": {
    "parent": "RepresentationNode",
    "node_type": "representation_model_sf",

{s3dgraphy-1.6.0.dev17 → s3dgraphy-1.6.0.dev18}/src/s3dgraphy/JSON_config/s3Dgraphy_connections_datamodel.json

@@ -1,6 +1,6 @@
 {
-  "s3Dgraphy_connections_model_version": "1.6.13",
-  "description": "s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.11 (batch ingestion, 2026-08-17): two widenings for bulk assets. has_author.source DTCProcessNode -> DTCNode, so an ACQUISITION event (D12) can carry the author of a whole lot; dtc_had_input.target += DTCNode, so a DECLARED derivation can name a whole acquisition as its input (one input, not 500 edges) — that case projects as prov:wasInformedBy, not prov:used/L10, which range over digital objects and would be wrong for an event. v1.6.8 (MIG1-A): graph-scope rights metadata become first-class nodes (DP-65). is_in_paradata_nodegroup.source += AuthorNode/LicenseNode/EmbargoNode and has_paradata_nodegroup.source += GraphNode, so the graph-self node (GraphNode) owns a graph-scope ParadataNodeGroup whose members are the AuthorNode/LicenseNode/EmbargoNode (+ the DP-65 GeoPositionNode shift), replacing the legacy graph.data['author_name'/'license'/'embargo'] fields. The Data Funnel canvas tier now reads these member nodes (one reader per scope); a one-shot load-time migration materialises the legacy fields into nodes. v1.6.7 (BUGFIX-CONN3): closes the two silent follow-ups of CONN2. has_documentation.source gains PropertyNode (judicious widening): the honest reading of a legacy yEd dashed PropertyNode→Document connector is P70i_is_documented_in ('the property is documented in this source'), NOT has_visual_reference (which CONN2 moved to PropertyNode→ResourceNode). The import heuristic (import_graphml.enhance_edge_type) now routes PropertyNode→Document to has_documentation and the rarer CombinerNode/ParadataNode→Document to generic_connection+warning (a combiner aggregates extractors and cites no document; the DTC chain is NOT synthesised at import). Shelf: hat_as_document no longer offers has_visual_reference (a Document attaches via has_documentation/extracted_from); a new hat_as_visual_resource attaches a ResourceNode image via has_visual_reference from a PropertyNode — the correct home after CONN2. No illegal edge is produced or expected. v1.6.6 (BUGFIX-CONN2): closes the two open domain questions on has_visual_reference (E.D. 2026-08-05). SOURCE narrowed to exactly [PropertyNode]: only a property (an asserted quale) is what a visual reference illustrates; the generic ParadataNode entry is dropped, which — because ExtractorNode, CombinerNode and DocumentNode are all subclasses of ParadataNode — now excludes them by class hierarchy (a PropertyNode is neither a sibling nor a parent of the others). The extractor/combiner denied_edges from v1.6.5 are therefore REDUNDANT for this edge but are KEPT as a defensive guard (they still bite if the source is ever broadened back to ParadataNode). TARGET changed from [DocumentNode] to [ResourceNode]: the oddity was that a visual reference pointed at a source-document (E31) rather than at a visual resource. It now points at the resource-layer image node (ResourceNode = E73 Information Object / ExternalResourceReference — the same P67 hinge RM/RMDoc use via has_linked_resource), keeping DocumentNode = fonte. CIDOC stays P138i_has_representation with the target co-typed E36 Visual Item: E36 is a subclass of E73, so co-typing a ResourceNode as E36 is range-consistent (it was NOT, strictly, for an E31 Document). FOLLOW-UPS flagged for E.D. (see end-of report): (a) import_graphml.enhance_edge_type still hardcodes PropertyNode/Combiner/Paradata→DocumentNode ⇒ has_visual_reference (legacy yEd heuristic, now produces an edge this datamodel refuses) — needs a domain decision on what legacy paradata→document edges become; (b) shelf.hat_as_document lists has_visual_reference among the Document-attach edges — it can no longer validate (target is ResourceNode), so a paradata attach silently no longer attaches; a hat_as_visual_resource(ResourceNode)+has_visual_reference path is the proper home. v1.6.5 (BUGFIX-CONN): has_visual_reference is no longer offered FROM an ExtractorNode or a CombinerNode. An extractor toward a document expresses ONLY extracted_from (its relation to the source is the extraction, not an illustration); a combiner aggregates extractors and illustrates nothing. Because ExtractorNode, CombinerNode and PropertyNode are all subclasses of ParadataNode, and has_visual_reference.source lists ParadataNode, simply dropping the two subtypes from the source list would not exclude them (they still match via the parent class). So this is expressed with node_type_restrictions (keyed by RUNTIME node_type, like USNt) using a new denied_edges blacklist (the mirror of allowed_edges): extractor/combiner deny has_visual_reference. PropertyNode and any other legitimate ParadataNode source keep it unchanged. OPEN domain question for E.D.: which paradata node-types may legitimately have a visual reference (today source = PropertyNode/ExtractorNode/CombinerNode/ParadataNode) — extractor/combiner removed; the rest left as-is, not invented. v1.6.1: has_paradata_nodegroup source extended to include EpochNode — an epoch can now own a ParadataNodeGroup holding its temporal-definition properties (e.g. absolute_time_start/end as PropertyNodes with paradata provenance), mirroring how a StratigraphicNode carries its paradata group. v1.6.0 (paired with node datamodel v1.6.0) introduces: bug fix on is_in_paradata_nodegroup (typo 'ProperrtyNOde' → 'PropertyNode'); semantic fix on has_documentation (P104_is_subject_to → P70i_is_documented_in — P104 means 'subject to a legal right', not 'has documentation'); deprecation of has_timebranch as duplicate of is_in_timebranch (the latter is the canonical one — used by import_graphml.py and graphml_patcher.py; the former exists only in config JSON); component list aligned with node datamodel (HDT-O, PROV-O added). HDT-O containment properties (hdto:contains_HDT, hdto:contains_SU, hdto:isPrimary) and physical-relation discriminator subproperties (em:abuts, em:cuts, em:fills, em:overlies, em:bonded_to, em:equals as rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation) to be added in v1.6.1. v1.5.3 introduced canonical/reverse directionality with verb-based labels for clear socket identification in node editors. v1.5.4 added 'has_visual_reference' edge type. v1.5.5 added 'is_in_location' edge type with context-sensitive CIDOC mapping (P53 for node→location, P89 for the recursive location→location hierarchy) and an optional 'is_primary' boolean attribute (s3d:isPrimary, proposed). v1.6.3: added node_type_restrictions — a per-node-type narrowing of the class-level edge rules (POL5): USN (the NEUTRAL stratigraphic unit, a risparmio) takes is_after/is_before and nothing else, because a void cannot cut, fill, abut or bond. v1.6.4 (POL6): the same restriction, moved to USNt — the tokens went back to their conventional meanings, USN = US negativa (all relations, it is a unit of the sequence) and USNt = US neutra (sequence only).",
+  "s3Dgraphy_connections_model_version": "1.6.15",
+  "description": "s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.15 (HW1, 2026-09-16): the act of acquisition gets a BODY. NEW dtc_happened_on_device — DTCNode -> DTCDeviceNode, crmdig:L12_happened_on_device — because until today the apparatus was a STRING inside how.acquisition, and a string cannot be asked «what did this machine produce», «which surveys used that scanner», «that lens was distorted, which models are affected». It attaches to the EVENT and not to the input or the output: the three dtc_kinds axes are the FLOW (what went in, what happened, what came out) and a device is what it happened ON — the distinction CRMdig draws between L12 and L10, and the one that makes the three questions askable. It is CONTEXT and carries no dtc_role, so a provenance walk does not enter it (per _dtc_role_note below). It has NO PROV-O projection on purpose: prov:used is taken by dtc_had_input and prov:Agent ranges over things that bear responsibility, which a camera does not — same honesty as the 2026-08-17 note on wasInformedBy. NOTHING IS REMOVED and nothing is narrowed. NOT DONE, and named so it is not forgotten: a rig (a sensor ON a drone) is an assembly of two devices and has no edge yet; the glyph family says it by drawing their connectors touching, which is a picture and not a statement. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.14 (EM16-RMNG, 2026-09-10): the RM container becomes a first-class group in the graph. NEW is_in_representation_model_group — membership of a representation model in a RepresentationModelNodeGroup, on the is_in_* tag convention (is_in_activity / is_in_location / is_in_timebranch / is_in_paradata_nodegroup / is_in_functional_unit), 1:1 instead of m:n because a mesh belongs to exactly one container. WIDENED has_representation_model.target += RepresentationModelNodeGroup, so a Document points at the named set as well as at each model. NOTHING IS REMOVED: the epoch↔RM edges and the direct Document→RM edges stay written as before, without a flag and without a mode — the group sits beside and never in between (D1, resolved by E.D. on 2026-09-10). s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.11 (batch ingestion, 2026-08-17): two widenings for bulk assets. has_author.source DTCProcessNode -> DTCNode, so an ACQUISITION event (D12) can carry the author of a whole lot; dtc_had_input.target += DTCNode, so a DECLARED derivation can name a whole acquisition as its input (one input, not 500 edges) — that case projects as prov:wasInformedBy, not prov:used/L10, which range over digital objects and would be wrong for an event. v1.6.8 (MIG1-A): graph-scope rights metadata become first-class nodes (DP-65). is_in_paradata_nodegroup.source += AuthorNode/LicenseNode/EmbargoNode and has_paradata_nodegroup.source += GraphNode, so the graph-self node (GraphNode) owns a graph-scope ParadataNodeGroup whose members are the AuthorNode/LicenseNode/EmbargoNode (+ the DP-65 GeoPositionNode shift), replacing the legacy graph.data['author_name'/'license'/'embargo'] fields. The Data Funnel canvas tier now reads these member nodes (one reader per scope); a one-shot load-time migration materialises the legacy fields into nodes. v1.6.7 (BUGFIX-CONN3): closes the two silent follow-ups of CONN2. has_documentation.source gains PropertyNode (judicious widening): the honest reading of a legacy yEd dashed PropertyNode→Document connector is P70i_is_documented_in ('the property is documented in this source'), NOT has_visual_reference (which CONN2 moved to PropertyNode→ResourceNode). The import heuristic (import_graphml.enhance_edge_type) now routes PropertyNode→Document to has_documentation and the rarer CombinerNode/ParadataNode→Document to generic_connection+warning (a combiner aggregates extractors and cites no document; the DTC chain is NOT synthesised at import). Shelf: hat_as_document no longer offers has_visual_reference (a Document attaches via has_documentation/extracted_from); a new hat_as_visual_resource attaches a ResourceNode image via has_visual_reference from a PropertyNode — the correct home after CONN2. No illegal edge is produced or expected. v1.6.6 (BUGFIX-CONN2): closes the two open domain questions on has_visual_reference (E.D. 2026-08-05). SOURCE narrowed to exactly [PropertyNode]: only a property (an asserted quale) is what a visual reference illustrates; the generic ParadataNode entry is dropped, which — because ExtractorNode, CombinerNode and DocumentNode are all subclasses of ParadataNode — now excludes them by class hierarchy (a PropertyNode is neither a sibling nor a parent of the others). The extractor/combiner denied_edges from v1.6.5 are therefore REDUNDANT for this edge but are KEPT as a defensive guard (they still bite if the source is ever broadened back to ParadataNode). TARGET changed from [DocumentNode] to [ResourceNode]: the oddity was that a visual reference pointed at a source-document (E31) rather than at a visual resource. It now points at the resource-layer image node (ResourceNode = E73 Information Object / ExternalResourceReference — the same P67 hinge RM/RMDoc use via has_linked_resource), keeping DocumentNode = fonte. CIDOC stays P138i_has_representation with the target co-typed E36 Visual Item: E36 is a subclass of E73, so co-typing a ResourceNode as E36 is range-consistent (it was NOT, strictly, for an E31 Document). FOLLOW-UPS flagged for E.D. (see end-of report): (a) import_graphml.enhance_edge_type still hardcodes PropertyNode/Combiner/Paradata→DocumentNode ⇒ has_visual_reference (legacy yEd heuristic, now produces an edge this datamodel refuses) — needs a domain decision on what legacy paradata→document edges become; (b) shelf.hat_as_document lists has_visual_reference among the Document-attach edges — it can no longer validate (target is ResourceNode), so a paradata attach silently no longer attaches; a hat_as_visual_resource(ResourceNode)+has_visual_reference path is the proper home. v1.6.5 (BUGFIX-CONN): has_visual_reference is no longer offered FROM an ExtractorNode or a CombinerNode. An extractor toward a document expresses ONLY extracted_from (its relation to the source is the extraction, not an illustration); a combiner aggregates extractors and illustrates nothing. Because ExtractorNode, CombinerNode and PropertyNode are all subclasses of ParadataNode, and has_visual_reference.source lists ParadataNode, simply dropping the two subtypes from the source list would not exclude them (they still match via the parent class). So this is expressed with node_type_restrictions (keyed by RUNTIME node_type, like USNt) using a new denied_edges blacklist (the mirror of allowed_edges): extractor/combiner deny has_visual_reference. PropertyNode and any other legitimate ParadataNode source keep it unchanged. OPEN domain question for E.D.: which paradata node-types may legitimately have a visual reference (today source = PropertyNode/ExtractorNode/CombinerNode/ParadataNode) — extractor/combiner removed; the rest left as-is, not invented. v1.6.1: has_paradata_nodegroup source extended to include EpochNode — an epoch can now own a ParadataNodeGroup holding its temporal-definition properties (e.g. absolute_time_start/end as PropertyNodes with paradata provenance), mirroring how a StratigraphicNode carries its paradata group. v1.6.0 (paired with node datamodel v1.6.0) introduces: bug fix on is_in_paradata_nodegroup (typo 'ProperrtyNOde' → 'PropertyNode'); semantic fix on has_documentation (P104_is_subject_to → P70i_is_documented_in — P104 means 'subject to a legal right', not 'has documentation'); deprecation of has_timebranch as duplicate of is_in_timebranch (the latter is the canonical one — used by import_graphml.py and graphml_patcher.py; the former exists only in config JSON); component list aligned with node datamodel (HDT-O, PROV-O added). HDT-O containment properties (hdto:contains_HDT, hdto:contains_SU, hdto:isPrimary) and physical-relation discriminator subproperties (em:abuts, em:cuts, em:fills, em:overlies, em:bonded_to, em:equals as rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation) to be added in v1.6.1. v1.5.3 introduced canonical/reverse directionality with verb-based labels for clear socket identification in node editors. v1.5.4 added 'has_visual_reference' edge type. v1.5.5 added 'is_in_location' edge type with context-sensitive CIDOC mapping (P53 for node→location, P89 for the recursive location→location hierarchy) and an optional 'is_primary' boolean attribute (s3d:isPrimary, proposed). v1.6.3: added node_type_restrictions — a per-node-type narrowing of the class-level edge rules (POL5): USN (the NEUTRAL stratigraphic unit, a risparmio) takes is_after/is_before and nothing else, because a void cannot cut, fill, abut or bond. v1.6.4 (POL6): the same restriction, moved to USNt — the tokens went back to their conventional meanings, USN = US negativa (all relations, it is a unit of the sequence) and USNt = US neutra (sequence only).",
   "components": [
     "CIDOC-CRM",
     "CRMarchaeo",
@@ -792,8 +792,10 @@
           "DocumentNode"
         ],
         "target": [
-          "RepresentationModelNode"
-        ]
+          "RepresentationModelNode",
+          "RepresentationModelNodeGroup"
+        ],
+        "_note": "EM16-RMNG widens the TARGET with RepresentationModelNodeGroup so a Document can point at a named set as well as at each model. The direct Document→model edges are NOT replaced: D1 of the 2026-09-10 spec was resolved by E.D. as additive-pure, and 1.6 already relies on this edge carrying the Document→RM bond (commit c46b365, where epoch-edge cleanup picks by epoch endpoint and not by edge type precisely so the Document bond survives)."
       }
     },
     "has_representation_model_doc": {
@@ -1326,7 +1328,7 @@
         "rationale": "crmdig:L10_had_input (D7 Digital Machine Event -> input digital object). Dual-emitted with prov:used (Activity used Entity) — same direction (Process -> input Resource) — so CRMdig and PROV-O readers both see the acquisition consumption. Target is the Resource (ResourceNode); the input is a resource, symmetric to the output. TARGET WIDENED 2026-08-17: when the target is a DTC EVENT (an acquisition consumed as a whole lot) neither L10_had_input nor prov:used holds — both range over digital OBJECTS, and an event is not one. That case projects as prov:wasInformedBy (activity -> activity), applied in the RDF exporter (_serialize_edge); the property-graph edge stays the one edge type, because 'this output came from that input' is one sentence whether the input is a file or a campaign."
       },
       "allowed_connections": {
-        "_note": "Source is the DTC event BASE class: both chunk types link to their Resources — DTCProcessNode (genesis, D7) and DTCAcquisitionNode (acquisition/ingestion, D12), per the dtc_nodes section note. Listing only DTCProcessNode used to pass by accident, because the old validator could not resolve the name and fell back to accepting anything. TARGET 2026-08-17: DTCNode joins ResourceNode so a DECLARED derivation can name a whole ACQUISITION as its input — the serial node exists precisely so a campaign of 500 photographs is one input and not 500 edges. The RDF projection distinguishes the two cases (see mapping.rationale); dtc_derived_from stays resource -> resource, because a shortcut between files cannot be written to an event, and that is reported rather than faked.",
+        "_note": "Source is the DTC event BASE class: both step types link to their Resources — DTCProcessNode (genesis, D7) and DTCAcquisitionNode (acquisition/ingestion, D12), per the dtc_nodes section note. Listing only DTCProcessNode used to pass by accident, because the old validator could not resolve the name and fell back to accepting anything. TARGET 2026-08-17: DTCNode joins ResourceNode so a DECLARED derivation can name a whole ACQUISITION as its input — the serial node exists precisely so a campaign of 500 photographs is one input and not 500 edges. The RDF projection distinguishes the two cases (see mapping.rationale); dtc_derived_from stays resource -> resource, because a shortcut between files cannot be written to an event, and that is reported rather than faked.",
         "source": [
           "DTCNode"
         ],
@@ -1353,7 +1355,7 @@
         "rationale": "crmdig:L11_had_output (D7 Digital Machine Event -> produced digital object). Dual-emitted with prov:generated (Activity generated Entity) — same direction (Process -> Output). Target is the Resource (ResourceNode) — the output is a resource, not a RepresentationModel/Document (those merely reference it)."
       },
       "allowed_connections": {
-        "_note": "Source is the DTC event BASE class: both chunk types link to their Resources — DTCProcessNode (genesis, D7) and DTCAcquisitionNode (acquisition/ingestion, D12), per the dtc_nodes section note. Listing only DTCProcessNode used to pass by accident, because the old validator could not resolve the name and fell back to accepting anything.",
+        "_note": "Source is the DTC event BASE class: both step types link to their Resources — DTCProcessNode (genesis, D7) and DTCAcquisitionNode (acquisition/ingestion, D12), per the dtc_nodes section note. Listing only DTCProcessNode used to pass by accident, because the old validator could not resolve the name and fell back to accepting anything.",
         "source": [
           "DTCNode"
         ],
@@ -1362,6 +1364,31 @@
         ]
       }
     },
+    "dtc_happened_on_device": {
+      "name": "dtc_happened_on_device",
+      "label": "Happened on device",
+      "description": "The APPARATUS a DTC step happened on — the camera, the scanner, the drone, the workstation. CONTEXT, NOT CHAIN: it deliberately carries no `dtc_role`, so a provenance walk does not traverse it (see _dtc_role_note: an edge without dtc_role is context by construction). A device is not a ring of the chain: it has no inputs and no outputs, and a walk that entered one would leave the flow to describe a thing.",
+      "reverse": {
+        "name": "dtc_was_device_of",
+        "label": "Was the device of"
+      },
+      "mapping": {
+        "cidoc": "crmdig:L12_happened_on_device",
+        "cidoc_extension": "CRMdig",
+        "extension_mapping": null,
+        "extension_name": null,
+        "rationale": "crmdig:L12_happened_on_device (D7 Digital Machine Event -> D8 Digital Device) says exactly this and nothing else, and CRMdig keeps it separate from L10_had_input ON PURPOSE: the photographs are the input, the camera is not. Flatten the two and «which files did this body take» stops being askable, which is the only reason this edge was added. NO PROV-O PROJECTION, and that is a decision rather than an omission. prov:used is already how dtc_had_input projects, and reusing it here would collapse in PROV exactly the distinction CRMdig draws; prov:wasAssociatedWith ranges over prov:Agent, 'a thing that bears some form of responsibility for an activity', and a camera bears none. PROV-O has no device, so this edge does not project into it — the same honesty dtc_had_input applies when it says L10/prov:used do NOT hold for an acquisition as input and projects prov:wasInformedBy instead. A reader that only speaks PROV sees the step and its files, and does not see a false statement about an agent."
+      },
+      "allowed_connections": {
+        "_note": "SOURCE is the DTC event BASE class, like dtc_had_input: both step types run on an apparatus — DTCProcessNode (a reconstruction ran on a workstation) and DTCAcquisitionNode (a campaign ran on a camera). TARGET is DTCDeviceNode only: the device is a thing in the world and not a step, which is why it is NOT a DTCNode subclass — making it one would have put it in the chain by inheritance and set the class hierarchy arguing with dtc_role. A RIG is drawn as two devices, not as a device pointing at another: 'the sensor was on the drone' is a statement about the assembly and it has no edge here yet — see HW1's end-of, where it is named and deliberately not invented.",
+        "source": [
+          "DTCNode"
+        ],
+        "target": [
+          "DTCDeviceNode"
+        ]
+      }
+    },
     "dtc_derived_from": {
       "name": "dtc_derived_from",
       "dtc_role": "chain",
@@ -1455,6 +1482,34 @@
           "Node"
         ]
       }
+    },
+    "is_in_representation_model_group": {
+      "name": "is_in_representation_model_group",
+      "label": "Is in representation model group",
+      "description": "Membership of a representation model in a RepresentationModelNodeGroup (EM16-RMNG): the models that together form one named set published under a single Document — «Survey 2015» under D.01, «Reconstruction» under D.09. THE GROUP SITS BESIDE, IT DOES NOT REPLACE: every member keeps its own epoch edges (has_first_epoch / survive_in_epoch) and the Document keeps its DIRECT has_representation_model edges to each model. This edge is added on top and never put in between, so a consumer that ignores it reads exactly what it read before. Membership is a TAG axis like is_in_functional_unit and is_in_location — the member carries the edge and the group claims nothing of it — with one difference that is semantic: membership here is 1:1, not m:n. A mesh belongs to exactly one container, which is the rule already in force on the Blender side (EM-blender-tools rm_manager/containers.py, where mesh_names is authoritative). A group may legally be EMPTY and may legally have no Document: both are states the RM Manager UI already shows, and neither is validated away.",
+      "reverse": {
+        "name": "includes_representation_model",
+        "label": "Includes representation model"
+      },
+      "mapping": {
+        "cidoc": "P46i_forms_part_of",
+        "cidoc_extension": "CIDOC-CRM",
+        "extension_mapping": "P46_is_composed_of",
+        "extension_name": "CIDOC-CRM",
+        "rationale": "Mereological, exactly like is_in_functional_unit (DP-72): the named set IS composed of its models, so it projects as P46i / P46. The precedent is deliberate — that edge already established that a typed aggregation's membership projects to the same CIDOC property as is_part_of while staying a distinct edge in the EM language, and that consumers reading only the RDF projection correctly see one uniform part-whole relation. NOTE, AND IT IS NOT AN OVERSIGHT: this says nothing about where `digital representation of` grafts into the ontological mapping (P138i / CIDOC-S3D:has3DRepresentation and its CRMdig neighbourhood). That is the RM↔thing relation, a separate question left open as D3 in the 2026-09-10 spec and reserved for E.D.; the group↔member relation decided here does not touch it."
+      },
+      "allowed_connections": {
+        "_note": "Source lists the three concrete representation classes one by one rather than the base RepresentationNode, mirroring what is_in_functional_unit had to do: Node.node_type_map is keyed by node_type, so a base-class name would resolve to a single subclass and refuse the others. A group may itself be a member of another group, which keeps the door open for nesting without requiring it.",
+        "source": [
+          "RepresentationModelNode",
+          "RepresentationModelDocNode",
+          "RepresentationModelSpecialFindNode",
+          "RepresentationModelNodeGroup"
+        ],
+        "target": [
+          "RepresentationModelNodeGroup"
+        ]
+      }
     }
   },
   "_dtc_role_note": "dtc_role marks an edge as part of the DTC CHAIN — the three edges a provenance walk may traverse. It exists because the classification used to be written twice: by name on the node (s3dgraphy.dtc) and by PREFIX in the client (startsWith('dtc_')). The prefix presumed every future dtc_* edge would be chain, so a dtc_* edge that is CONTEXT — a dtc_annotated_by, say — would have been a corridor on the client and not on the node: two rules with one name. Now the datamodel says it once and both sides read it. An edge WITHOUT dtc_role is context by construction: adding one is a JSON entry, and it is born non-traversable."