s3dgraphy 1.6.0.dev23__tar.gz → 1.6.0.dev24__tar.gz

{s3dgraphy-1.6.0.dev23/src/s3dgraphy.egg-info → s3dgraphy-1.6.0.dev24}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: s3dgraphy
-Version: 1.6.0.dev23
+Version: 1.6.0.dev24
 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>

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "s3dgraphy"
-version = "1.6.0.dev23"
+version = "1.6.0.dev24"
 description = "3D Stratigraphic Graph Management Library for archaeological and heritage applications"
 readme = "README.md"
 requires-python = ">=3.9"

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/src/s3dgraphy/JSON_config/datamodel_translations.json

@@ -1436,6 +1436,46 @@
     "de": "Repräsentationsmodell Einzelfund"
    }
   },
+  "ResourceFileNode": {
+   "description": {
+    "en": "ONE FILE of a resource (E.D. 2026-09-30, «la risorsa e i suoi file»): the ResourceNode is the SET — the handle a person stamps, cites and opens, with name, kind, scope, residency, role, tier, packaging and rights — and the ResourceFileNode is each member: an obj, its mtl and its textures are three files of one resource. Reached by has_file (reverse is_file_of); the ROLE (entry_point | member) and the RELATIVE PATH travel on the EDGE, because the same file (a corrected texture) sits in N resources under N paths. With ONE file the node is IMPLICIT: a ResourceNode with url (and checksum) and no has_file is a resource of one file, and s3dgraphy.resources.files.resource_files shows that file anyway; the node is written only when there are several files or the one file has a stamp or an identity of its own. Fields: url (a path, a file:// / s3:// / http(s):// URI or a blend:// locator), checksum ('sha256:<hex>'; 'emstruct1:<hex>' for a datablock, comparable not verifiable), size_bytes, media_type. For a datablock blend_file and datablock are READ from the blend:// locator (resources/resolver.py, the one place that knows its form), never stored twice. The same file in several resources is ONE node, recognised by its checksum.",
+    "validated_it": false,
+    "validated_el": false,
+    "validated_he": false,
+    "validated_es": false,
+    "validated_pl": false,
+    "validated_ro": false,
+    "validated_fr": false,
+    "validated_de": false,
+    "it": "UN FILE di una risorsa (E.D. 30 set 2026, «la risorsa e i suoi file»): il ResourceNode è l'INSIEME — la maniglia che si timbra, si cita e si apre — e il ResourceFileNode è ogni membro: un obj, il suo mtl e le sue texture sono tre file di una risorsa sola. Raggiunto da has_file; il RUOLO (entry_point | member) e il PERCORSO RELATIVO stanno sull'ARCO, perché lo stesso file sta in più risorse con percorsi diversi. Con UN file il nodo è IMPLICITO: url e checksum restano sul ResourceNode. Per un datablock blend_file e datablock si leggono dal locator blend://, mai scritti due volte.",
+    "el": "ΕΝΑ ΑΡΧΕΙΟ ενός πόρου (E.D. 30/9/2026): ο ResourceNode είναι το ΣΥΝΟΛΟ — η λαβή που σφραγίζεται, παρατίθεται και ανοίγεται — και ο ResourceFileNode κάθε μέλος του: ένα obj, το mtl του και οι υφές του είναι τρία αρχεία ενός πόρου. Συνδέεται με has_file· ο ΡΟΛΟΣ (entry_point | member) και η ΣΧΕΤΙΚΗ ΔΙΑΔΡΟΜΗ βρίσκονται στην ΑΚΜΗ, γιατί το ίδιο αρχείο ανήκει σε πολλούς πόρους με διαφορετικές διαδρομές. Με ΕΝΑ αρχείο ο κόμβος είναι ΣΙΩΠΗΡΟΣ: url και checksum μένουν στον ResourceNode.",
+    "he": "קובץ אחד של משאב (E.D. 30.9.2026): ResourceNode הוא הקבוצה — הידית שמחתימים, מצטטים ופותחים — ו־ResourceFileNode הוא כל חבר בה: קובץ obj, קובץ ה־mtl שלו והטקסטורות שלו הם שלושה קבצים של משאב אחד. מקושר ב־has_file; התפקיד (entry_point | member) והנתיב היחסי נמצאים על הקשת, כי אותו קובץ נמצא בכמה משאבים בנתיבים שונים. עם קובץ אחד הצומת משתמע: url ו־checksum נשארים על ה־ResourceNode.",
+    "es": "UN ARCHIVO de un recurso (E.D. 30 sep 2026): el ResourceNode es el CONJUNTO — el asa que se sella, se cita y se abre — y el ResourceFileNode es cada miembro: un obj, su mtl y sus texturas son tres archivos de un solo recurso. Se alcanza con has_file; el ROL (entry_point | member) y la RUTA RELATIVA están en la ARISTA, porque el mismo archivo está en varios recursos con rutas distintas. Con UN archivo el nodo es IMPLÍCITO: url y checksum quedan en el ResourceNode.",
+    "pl": "JEDEN PLIK zasobu (E.D. 30.09.2026): ResourceNode to ZBIÓR — uchwyt, który się stempluje, cytuje i otwiera — a ResourceFileNode to każdy jego element: obj, jego mtl i tekstury to trzy pliki jednego zasobu. Osiągany przez has_file; ROLA (entry_point | member) i ŚCIEŻKA WZGLĘDNA są na KRAWĘDZI, bo ten sam plik należy do wielu zasobów pod różnymi ścieżkami. Przy JEDNYM pliku węzeł jest DOMYŚLNY: url i checksum zostają w ResourceNode.",
+    "ro": "UN FIȘIER al unei resurse (E.D. 30 sep 2026): ResourceNode este ANSAMBLUL — mânerul care se ștampilează, se citează și se deschide — iar ResourceFileNode este fiecare membru: un obj, mtl-ul său și texturile sale sunt trei fișiere ale unei singure resurse. Atins prin has_file; ROLUL (entry_point | member) și CALEA RELATIVĂ stau pe MUCHIE, pentru că același fișier stă în mai multe resurse cu căi diferite. Cu UN singur fișier nodul este IMPLICIT: url și checksum rămân pe ResourceNode.",
+    "fr": "UN FICHIER d'une ressource (E.D. 30 sept. 2026) : le ResourceNode est l'ENSEMBLE — la poignée que l'on tamponne, cite et ouvre — et le ResourceFileNode chaque membre : un obj, son mtl et ses textures sont trois fichiers d'une seule ressource. Atteint par has_file ; le RÔLE (entry_point | member) et le CHEMIN RELATIF sont sur l'ARÊTE, car le même fichier appartient à plusieurs ressources sous des chemins différents. Avec UN fichier le nœud est IMPLICITE : url et checksum restent sur le ResourceNode.",
+    "de": "EINE DATEI einer Ressource (E.D. 30.09.2026): der ResourceNode ist die MENGE — der Griff, den man stempelt, zitiert und öffnet — und der ResourceFileNode jedes Mitglied: ein obj, sein mtl und seine Texturen sind drei Dateien einer Ressource. Erreicht über has_file; die ROLLE (entry_point | member) und der RELATIVE PFAD stehen auf der KANTE, weil dieselbe Datei in mehreren Ressourcen unter verschiedenen Pfaden liegt. Bei EINER Datei ist der Knoten IMPLIZIT: url und checksum bleiben am ResourceNode."
+   },
+   "label": {
+    "en": "Resource file",
+    "validated_it": false,
+    "validated_el": false,
+    "validated_he": false,
+    "validated_es": false,
+    "validated_pl": false,
+    "validated_ro": false,
+    "validated_fr": false,
+    "validated_de": false,
+    "it": "File della risorsa",
+    "el": "Αρχείο πόρου",
+    "he": "קובץ משאב",
+    "es": "Archivo del recurso",
+    "pl": "Plik zasobu",
+    "ro": "Fișier al resursei",
+    "fr": "Fichier de la ressource",
+    "de": "Datei der Ressource"
+   }
+  },
   "ResourceNode": {
    "description": {
     "en": "Class to represent a link node (ResourceNode) in the graph. Attributes: url (str): URL of the link. url_type (str): Type of URL (e.g., 'External link', 'Image'). description (str): Description of the link.",
@@ -5647,6 +5687,65 @@
     "de": "Hat Sperrfrist"
    }
   },
+  "has_file": {
+   "label": {
+    "en": "Has file",
+    "validated_it": false,
+    "validated_el": false,
+    "validated_he": false,
+    "validated_es": false,
+    "validated_pl": false,
+    "validated_ro": false,
+    "validated_fr": false,
+    "validated_de": false,
+    "it": "Ha il file",
+    "el": "Έχει αρχείο",
+    "he": "יש קובץ",
+    "es": "Tiene el archivo",
+    "pl": "Ma plik",
+    "ro": "Are fișierul",
+    "fr": "A pour fichier",
+    "de": "Hat die Datei"
+   },
+   "ui_phrase_as_source": {
+    "en": "{node} with file {x}",
+    "validated_it": false,
+    "validated_el": false,
+    "validated_he": false,
+    "validated_es": false,
+    "validated_pl": false,
+    "validated_ro": false,
+    "validated_fr": false,
+    "validated_de": false,
+    "it": "{node} con il file {x}",
+    "el": "{node} με το αρχείο {x}",
+    "he": "{node} עם הקובץ {x}",
+    "es": "{node} con el archivo {x}",
+    "pl": "{node} z plikiem {x}",
+    "ro": "{node} cu fișierul {x}",
+    "fr": "{node} avec le fichier {x}",
+    "de": "{node} mit der Datei {x}"
+   },
+   "ui_phrase_as_target": {
+    "en": "{node} file of {x}",
+    "validated_it": false,
+    "validated_el": false,
+    "validated_he": false,
+    "validated_es": false,
+    "validated_pl": false,
+    "validated_ro": false,
+    "validated_fr": false,
+    "validated_de": false,
+    "it": "{node} file di {x}",
+    "el": "{node} αρχείο του {x}",
+    "he": "{node} קובץ של {x}",
+    "es": "{node} archivo de {x}",
+    "pl": "{node} plik zasobu {x}",
+    "ro": "{node} fișier al {x}",
+    "fr": "{node} fichier de {x}",
+    "de": "{node} Datei von {x}"
+   }
+  },
   "has_first_epoch": {
    "label": {
     "en": "Has first epoch",
@@ -7006,6 +7105,27 @@
     "fr": "Validé par",
     "de": "Validiert von"
    }
+  },
+  "was_revision_of": {
+   "label": {
+    "en": "Was revision of",
+    "validated_it": false,
+    "validated_el": false,
+    "validated_he": false,
+    "validated_es": false,
+    "validated_pl": false,
+    "validated_ro": false,
+    "validated_fr": false,
+    "validated_de": false,
+    "it": "È una revisione di",
+    "el": "Είναι αναθεώρηση του",
+    "he": "הוא גרסה מתוקנת של",
+    "es": "Es una revisión de",
+    "pl": "Jest rewizją",
+    "ro": "Este o revizie a",
+    "fr": "Est une révision de",
+    "de": "Ist eine Revision von"
+   }
   }
  },
  "dtc_kinds": {

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/src/s3dgraphy/JSON_config/em.ttl

@@ -46,8 +46,8 @@
     dcterms:creator "Emanuele Demetrescu" ;
     dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
     dcterms:issued "2026-05-23"^^xsd:date ;
-    owl:versionInfo "1.6.8" ;
-    rdfs:comment "Formal ontology for Extended Matrix (EM): a human-readable layout for knowledge graphs of archaeological stratigraphy and virtual reconstruction. Extends CIDOC-CRM, CRMarchaeo, CRMinf, CRMdig, CRMgeo, with PROV-O for agent provenance and HDT-O for digital-twin granularity. This file declares the em: classes and properties introduced in s3dgraphy v1.6.0. v1.6.2 (2026-09-21, CIDOC repair pass): the eight terms the datamodels cited and this file never defined are declared in section 12; em:NodeGroup and em:ParadataNodeGroup leave the undeclared crm:E78_Collection for crm:E73_Information_Object and crm:E89_Propositional_Object; em:SemanticShape leaves crmgeo:SP5 for crm:E73_Information_Object, provisionally; crmarchaeo:AP11_has_physical_relation becomes AP11_has_physical_relation_to, the name CRMarchaeo has used since 2.0; and em:RepresentationModel says what a representation model IS. v1.6.5 (2026-10-20, MICRO la definizione dell\'unita\'): em:hasDefinition, the DEFINIZIONE of a stratigraphic unit as a subproperty of crm:P2_has_type — declared for the node datamodel 1.6.9 entry StratigraphicNode.properties.definition, not emitted by default (owl:versionInfo was left at 1.6.2 by the 1.6.3/1.6.4 passes and is realigned here). v1.6.8 (2026-10-11, MICRO la geometria per origine): the vertices of a 3D reading (point, line, polyline) are data of the region (node datamodel 1.6.15, AnnotationRegionNode.coords) and leave for RDF as ONE GeoSPARQL 1.1 literal: <region> geo:hasGeometry <region>/geometry, a geo:Geometry with geo:asWKT '<CRS IRI> POINT Z (x y z)' | 'MULTIPOINT Z (...)' | 'LINESTRING Z (...)'^^geo:wktLiteral. WHY GeoSPARQL and not em: terms: the WKT literal is the standard every triplestore with a spatial index reads, and it is the 3D twin of the Media Fragment a 2D region already emits (a string a consumer outside EM can act on); CRMgeo was built to meet GeoSPARQL at exactly this point (SP5 Geometric Place Expression ~ geo:Geometry), and an em:coords literal would say the same thing to nobody. The CRS travels INSIDE the literal, so it cannot be separated from the numbers: em:LocalSceneFrame (declared here) for the scene-local frame, the OGC EPSG IRI for a projected one. em:vertexCount stays (the count of a .glb resource above the threshold). The .glb of a reading is no longer a SemanticShape's rdfs:seeAlso: above coords.inline_max_vertices (500) it is a ResourceNode the region reaches with has_linked_resource (crm:P67_refers_to), and a proxy's .glb is likewise a proxy_model ResourceNode (connections 1.6.28-1.6.29). v1.6.7 (2026-09-30, MICRO la cattura in RDF): no em: term added — the acquisition of a digital object is typed by its KIND. A capture is not a transfer: crmdig:D2_Digitization_Process for a photograph or a laser scan, crmdig:D11_Digital_Measurement_Event for a topographic or GNSS survey, crm:E65_Creation for a field drawing or a recording sheet (made by hand; the file is their copy, so no D7 machine event is asserted); a retrieval (download, local import, URI, ingest) stays crmdig:D12_Data_Transfer_Event. The rule is data (em_visual_rules 1.6.24, dtc_kinds.acquisition.<kind>.mapping). v1.6.6 (2026-10-07, MICRO la misura in RDF): the place of a reading gets its quote and its measure. The quote of a passage reuses W3C Web Annotation (oa:hasSelector -> oa:TextQuoteSelector, oa:exact) — the only standard term for a quote, which has no fragment-string form; its offsets stay the RFC 5147 em:hasSelector 'char=s,e'. The length of a line or polyline reuses CIDOC (crm:P43_has_dimension -> crm:E54_Dimension, P90_has_value xsd:double, P91_has_unit -> a QUDT unit IRI); two em: terms are new, em:vertexCount and em:crs, for what neither vocabulary says. The .glb of a 3D reading is not described here: its URL is the rdfs:seeAlso of the SemanticShape the region reaches with em:hasSemanticShape, and no coordinate enters RDF."@en ;
+    owl:versionInfo "1.6.9" ;
+    rdfs:comment "Formal ontology for Extended Matrix (EM): a human-readable layout for knowledge graphs of archaeological stratigraphy and virtual reconstruction. Extends CIDOC-CRM, CRMarchaeo, CRMinf, CRMdig, CRMgeo, with PROV-O for agent provenance and HDT-O for digital-twin granularity. This file declares the em: classes and properties introduced in s3dgraphy v1.6.0. v1.6.9 (2026-10-18, MICRO la risorsa e i suoi file): em:ResourceFile, ONE FILE of a resource (node datamodel 1.6.17), a subclass of crmdig:D1_Digital_Object; the resource is composed of its files by crm:P106_is_composed_of (connections has_file, 1.6.30). A distinct URI because a DTC output resource is already typed crmdig:D1, and a file typed only D1 would read back as a resource. v1.6.2 (2026-09-21, CIDOC repair pass): the eight terms the datamodels cited and this file never defined are declared in section 12; em:NodeGroup and em:ParadataNodeGroup leave the undeclared crm:E78_Collection for crm:E73_Information_Object and crm:E89_Propositional_Object; em:SemanticShape leaves crmgeo:SP5 for crm:E73_Information_Object, provisionally; crmarchaeo:AP11_has_physical_relation becomes AP11_has_physical_relation_to, the name CRMarchaeo has used since 2.0; and em:RepresentationModel says what a representation model IS. v1.6.5 (2026-10-20, MICRO la definizione dell\'unita\'): em:hasDefinition, the DEFINIZIONE of a stratigraphic unit as a subproperty of crm:P2_has_type — declared for the node datamodel 1.6.9 entry StratigraphicNode.properties.definition, not emitted by default (owl:versionInfo was left at 1.6.2 by the 1.6.3/1.6.4 passes and is realigned here). v1.6.8 (2026-10-11, MICRO la geometria per origine): the vertices of a 3D reading (point, line, polyline) are data of the region (node datamodel 1.6.15, AnnotationRegionNode.coords) and leave for RDF as ONE GeoSPARQL 1.1 literal: <region> geo:hasGeometry <region>/geometry, a geo:Geometry with geo:asWKT '<CRS IRI> POINT Z (x y z)' | 'MULTIPOINT Z (...)' | 'LINESTRING Z (...)'^^geo:wktLiteral. WHY GeoSPARQL and not em: terms: the WKT literal is the standard every triplestore with a spatial index reads, and it is the 3D twin of the Media Fragment a 2D region already emits (a string a consumer outside EM can act on); CRMgeo was built to meet GeoSPARQL at exactly this point (SP5 Geometric Place Expression ~ geo:Geometry), and an em:coords literal would say the same thing to nobody. The CRS travels INSIDE the literal, so it cannot be separated from the numbers: em:LocalSceneFrame (declared here) for the scene-local frame, the OGC EPSG IRI for a projected one. em:vertexCount stays (the count of a .glb resource above the threshold). The .glb of a reading is no longer a SemanticShape's rdfs:seeAlso: above coords.inline_max_vertices (500) it is a ResourceNode the region reaches with has_linked_resource (crm:P67_refers_to), and a proxy's .glb is likewise a proxy_model ResourceNode (connections 1.6.28-1.6.29). v1.6.7 (2026-09-30, MICRO la cattura in RDF): no em: term added — the acquisition of a digital object is typed by its KIND. A capture is not a transfer: crmdig:D2_Digitization_Process for a photograph or a laser scan, crmdig:D11_Digital_Measurement_Event for a topographic or GNSS survey, crm:E65_Creation for a field drawing or a recording sheet (made by hand; the file is their copy, so no D7 machine event is asserted); a retrieval (download, local import, URI, ingest) stays crmdig:D12_Data_Transfer_Event. The rule is data (em_visual_rules 1.6.24, dtc_kinds.acquisition.<kind>.mapping). v1.6.6 (2026-10-07, MICRO la misura in RDF): the place of a reading gets its quote and its measure. The quote of a passage reuses W3C Web Annotation (oa:hasSelector -> oa:TextQuoteSelector, oa:exact) — the only standard term for a quote, which has no fragment-string form; its offsets stay the RFC 5147 em:hasSelector 'char=s,e'. The length of a line or polyline reuses CIDOC (crm:P43_has_dimension -> crm:E54_Dimension, P90_has_value xsd:double, P91_has_unit -> a QUDT unit IRI); two em: terms are new, em:vertexCount and em:crs, for what neither vocabulary says. The .glb of a 3D reading is not described here: its URL is the rdfs:seeAlso of the SemanticShape the region reaches with em:hasSemanticShape, and no coordinate enters RDF."@en ;
     owl:imports <http://www.cidoc-crm.org/cidoc-crm/> ,
                 <http://www.cidoc-crm.org/extensions/crminf/> ,
                 <http://www.cidoc-crm.org/extensions/crmarchaeo/> ,
@@ -706,6 +706,12 @@ em:RegistrationTransform
     rdfs:subClassOf crm:E73_Information_Object ;
     rdfs:comment "The 7-parameter similarity (rotation, translation, positive scale) that places a produced model in a frame, carrying its own error bar (rms, residuals) beside the claim rather than in a log nobody keeps. It DESCRIBES a mapping between two crmgeo:SP4 spatial coordinate reference systems, which CIDOC and CRMgeo model individually but never as a parameterised map between two of them — hence E73 as the honest superclass. Deliberately NOT an event: the alternative, leaving the parameters as literals on the D7 acquisition, loses the ability to point at «the placement» as a thing that gets superseded, and being superseded is the whole reason the transform is a node. The three modes are the SHAPE of the graph, never a flag: a transform with a CRS that has_gcp_set points at = absolute; a transform with crs=null and no control set = a site-local frame; no transform at all = nobody placed it. Maps to: Python RegistrationTransformNode (node_type=\'registration_transform\')."@en .
 
+em:ResourceFile
+    a owl:Class ;
+    rdfs:label "Resource File"@en ;
+    rdfs:subClassOf crmdig:D1_Digital_Object ;
+    rdfs:comment "ONE FILE of a resource: the resource (crm:E73_Information_Object) is the set a person stamps, cites and opens, the file is each of its members — an obj, its mtl, its textures. The resource reaches it with crm:P106_is_composed_of; the file's role (entry point or member) and its path relative to the entry point are data of that relation in the property graph and are not projected. With one file the file is implicit and not emitted: the resource's own url and checksum are that file. Maps to: Python ResourceFileNode (node_type='resource_file')."@en .
+
 em:Narrative
     a owl:Class ;
     rdfs:label "Narrative"@en ;

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/src/s3dgraphy/JSON_config/em_visual_rules.json

@@ -1,6 +1,6 @@
 {
   "formal_language": "EM",
-  "version": "1.6.25",
+  "version": "1.6.27",
   "_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,6 +9,8 @@
     "In breve: qui si decide di che colore DISEGNARE una US; li si registra di che colore ERA."
   ],
   "_changelog": {
+    "1.6.27": "THE GLYPH OF THE FILE (MICRO-REVISIONE, 20 Oct 2026, decision of E.D. 30 Sep 2026: Claude draws it). node_styles.FILE.2d_file_vect: src/2D/link.svg -> src/2D/resource_file.svg, a sheet with a folded corner and the digest sign inside the 2017 DTC circle. WHERE, MEASURED: a resource takes its sign from node_styles.<KEY>.2d_file_vect (LINK -> src/2D/link.svg), a FILE, which EMStudio's icons.ts resolves (declaration, then src/2D/<node_type>.svg) and sync-datamodels.sh vendors from the top level of src/2D/. It is NOT a DTC glyph (dtc_kinds name the glyphs of DTC kinds, and a file is a node type, not a kind) and NOT a 2d_glyphs entry: LINK is not in 2d_render_glyph_types either, and joining that list would change how the label is laid out, which nobody asked. Still no .glb (as before). The dashed border and the LINK colour stay.",
+    "1.6.26": "THE FILE OF A RESOURCE (MICRO-RISORSA-FILE, 18 Oct 2026, decision of E.D. 30 Sep 2026). node_styles += FILE for ResourceFileNode (node datamodel 1.6.17): the LINK chain glyph and colour with a DASHED border — a file is a member of the resource it hangs from, the same family and not a second resource. NO NEW GLYPH: it reuses src/2D/link.svg, declares no .glb (LINK's src/3D/link.glb is itself among the missing 3D models, and a new type must not add to that gap), and a sign of its own is left to E.D.",
     "1.6.25": "THE EIGHT DTC GLYPHS APPROVED (E.D., 30 Sep 2026; MICRO-GEOMETRIA-ORIGINE part 1). The eight drafts of 1.6.23 moved from src/2D/bozze/dtc_<glyph>.svg to src/2D/dtc/<glyph>.svg (12_gnss_survey … 19_vectorization), the BOZZA word removed from their comment, glyphs_from_svg --write rerun: their 2d_glyphs entries no longer carry draft: true. src/2D/bozze/ is empty again. Still without a glyph (open): the four recoveries download, local_import, uri_reference, ingest.",
     "1.6.24": "THE CAPTURE IN RDF (MICRO-GENERI-GLIFI, 30 Sep 2026; proposed by Claude, accepted by E.D.). Six acquisition kinds declare `mapping` — the rdf:type their DTCAcquisitionNode takes INSTEAD of crmdig:D12_Data_Transfer_Event, which describes a transfer: photo, laserscanner → crmdig:D2_Digitization_Process (⊂ D11 ⊂ D7); topographic, gnss_survey → crmdig:D11_Digital_Measurement_Event (⊂ D7); field_drawing, recording_sheet → crm:E65_Creation (⊂ E7; made by hand, the file is their copy). The retrievals (download, local_import, uri_reference, ingest) declare none and stay D12. See dtc_kinds.acquisition._mapping_comment; read by rdf_exporter and rdf_importer through utils.get_dtc_kind_mapping. CRMem (em.ttl) 1.6.6 -> 1.6.7 for the changelog note.",
     "1.6.23": "THE EIGHT DTC GLYPHS, AS DRAFTS (MICRO-GENERI-GLIFI, 30 Sep 2026). The eight kinds 1.6.22 left with glyph: null now name a pictogram — gnss_survey 12_gnss_survey, field_drawing 13_field_drawing, recording_sheet 14_recording_sheet, decimation 15_decimation, georeferencing 16_georeferencing, format_conversion 17_format_conversion, classification 18_classification, vectorization 19_vectorization — drawn by Claude on the 2017 DTC family (circle r 41.14, black stroke, no colour) and marked BOZZA. They live in src/2D/bozze/dtc_<glyph>.svg, so their 2d_glyphs entries carry draft: true and no consumer vendors them as official. APPROVAL IS E.D.'S: move the file to src/2D/dtc/<glyph>.svg (dropping the dtc_ prefix), remove the word BOZZA from its comment, rerun `python -m s3dgraphy.tools.glyphs_from_svg --write`. The four retrieval kinds (download, local_import, uri_reference, ingest) still have glyph: null.",
@@ -3345,6 +3347,16 @@
       },
       "label_position": "over"
     },
+    "FILE": {
+      "2d_file_vect": "src/2D/resource_file.svg",
+      "style": {
+        "border_color": "#FF6600",
+        "fill_color": "#FFFFFF",
+        "border_style": "dashed",
+        "shape": "chain"
+      },
+      "label_position": "over"
+    },
     "GCP": {
       "_comment": "Ground control points — the EVIDENCE behind a registration: which point was seen on which photograph at which pixel, and where it is in the world. The NODE IS THE SET, never the single GCP (data.points), which is why the icon shows one target among several marks. Same orange as the other reference/georeferencing nodes (GEO, SS, LINK) because it is that family; the crosshair shape distinguishes measurement-of-a-place from position-of-a-site. Graphml palette prefix: 'GC.'.",
       "file_3d": "src/3D/gcp_set.glb",

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/src/s3dgraphy/JSON_config/hdto_extension.ttl

@@ -10,7 +10,7 @@
 @prefix dcterms:   <http://purl.org/dc/terms/> .
 
 # ============================================================================
-# HDT-O — Heritage Digital Twin Ontology — s3dgraphy alignment layer (v0.2)
+# HDT-O — Heritage Digital Twin Ontology — s3dgraphy alignment layer (v0.3)
 # ============================================================================
 #
 # Reconciled with ECHOES Deliverable D7.1 "The Digital Commons" (May 2024).
@@ -22,7 +22,14 @@
 #          Namespace placeholder (w3id.org/hdto/) — to be replaced when the
 #          official HDT-O resolvable IRI is published by the ECHOES consortium.
 # Author:  Emanuele Demetrescu (s3dgraphy v1.6.0 integration)
-# Date:    2026-05-23
+# Date:    2026-09-30 (v0.3; v0.2 2026-05-23)
+#
+# v0.3 (2026-09-30): the two declarations this file carried against D7.1 final
+#          are corrected. HC9 Study becomes a subclass of crm:E65 Creation (was
+#          crm:E7 Activity) and HC16 Heritage Proposition Set becomes a subclass
+#          of crminf:I4 Proposition Set and HC15 Persistent Digital Object (was
+#          crm:E73 Information Object alone). Both were recorded as open in
+#          docs/hdto-coverage.md, measured on D7.1_final.docx.
 # License: CC-BY-4.0
 #
 # What this file does:
@@ -87,15 +94,17 @@ hdto:HC15_Persistent_Digital_Object
 hdto:HC16_Heritage_Proposition_Set
     a owl:Class ;
     rdfs:label "Heritage Proposition Set"@en ;
-    rdfs:subClassOf crm:E73_Information_Object ;
-    rdfs:comment "A named graph carrying a set of formal propositions about (or related to) heritage entities. The atomic content unit that an HC2 Heritage Digital Twin aggregates: an HC2 'contains' (HP33) one or more HC16 instances. Version chains across editing actions are documented via HP30 added content / HP31 deleted content / HP32 replaced. An s3dgraphy em:EMGraph IS a Heritage Proposition Set (formally declared in em.ttl via owl:equivalentClass / subClassOf)."@en .
+    rdfs:subClassOf crminf:I4_Proposition_Set ,
+                    hdto:HC15_Persistent_Digital_Object ,
+                    crm:E73_Information_Object ;
+    rdfs:comment "A named graph carrying a set of formal propositions about (or related to) heritage entities. The atomic content unit that an HC2 Heritage Digital Twin aggregates: an HC2 'contains' (HP33) one or more HC16 instances. Per D7.1 (final, V1.0) a subclass of crminf:I4 Proposition Set and of HC15 Persistent Digital Object; crm:E73 Information Object is kept so that a CRM-only reader still resolves it. Version chains across editing actions are documented via HP30 added content / HP31 deleted content / HP32 replaced. An s3dgraphy em:EMGraph IS a Heritage Proposition Set (formally declared in em.ttl via owl:equivalentClass / subClassOf)."@en .
 
 
 hdto:HC9_Study
     a owl:Class ;
     rdfs:label "Study"@en ;
-    rdfs:subClassOf crm:E7_Activity ;
-    rdfs:comment "A scholarly activity (research, analysis or documentation, in any SSH / natural / exact-science domain) about a Heritage Entity (HC1), explicating a disciplinary focus and the part of the entity investigated. A study is about (HP23) one or more HC1 and has created (HP25) documentary outputs (crm:E31 Document) — in s3dgraphy the EM proposition set (HC16 / em:EMGraph). ECHOES D7.1."@en .
+    rdfs:subClassOf crm:E65_Creation ;
+    rdfs:comment "A scholarly activity (research, analysis or documentation, in any SSH / natural / exact-science domain) about a Heritage Entity (HC1), explicating a disciplinary focus and the part of the entity investigated. A study is about (HP23) one or more HC1 and has created (HP25) documentary outputs (crm:E31 Document) — in s3dgraphy the EM proposition set (HC16 / em:EMGraph). A subclass of crm:E65 Creation: the study is the scholarly act, and its documentary output is a separate thing joined to it by HP25, so a report, a field note or a metadata record is never an HC9. ECHOES D7.1 (final, V1.0)."@en .
 
 hdto:HC13_Project
     a owl:Class ;

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/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.14",
+ "s3Dgraphy_data_model_version": "1.6.17",
  "node_types": {
   "ActivityNodeGroup": {
    "parent": "GroupNode",
@@ -197,6 +197,11 @@
    "node_type": null,
    "description": "Base class for all representation nodes in 3D space."
   },
+  "ResourceFileNode": {
+   "parent": "Node",
+   "node_type": "resource_file",
+   "description": "ONE FILE of a resource — the resource is the set, this is each member."
+  },
   "ResourceNode": {
    "parent": "Node",
    "node_type": "resource",

{s3dgraphy-1.6.0.dev23 → s3dgraphy-1.6.0.dev24}/src/s3dgraphy/JSON_config/s3Dgraphy_connections_datamodel.json

@@ -1,6 +1,6 @@
 {
-  "s3Dgraphy_connections_model_version": "1.6.29",
-  "description": "v1.6.29 (LA GEOMETRIA PER ORIGINE, 2026-10-11, decision of E.D. 2026-09-30): the vertices of a point / line / polyline reading are data of the region (node datamodel 1.6.15, data.coords); has_semantic_shape no longer carries a reading's .glb (the 1.6.27 hinge is migrated on opening). has_linked_resource.source += AnnotationRegionNode: above coords.inline_max_vertices (500) the vertices go to a .glb RESOURCE the region reaches with has_linked_resource (P67), as a proxy's shape and an RM do. ADDITIVE: nothing narrowed. v1.6.28 (IL PROXY COME RISORSA, 2026-10-11, decision of E.D. 2026-09-30): the proxy is a property of the US and its .glb is a RESOURCE. has_linked_resource.source += SemanticShapeNode: the shape reaches its glb with has_linked_resource -> ResourceNode(url_type proxy_model), the same hinge a Representation Model uses for its bytes (P67_refers_to), instead of carrying the path in its own url. SemanticShape.url is READ, never written: on opening, a shape with a url and no resource gets one (geometry/migrate.py, uuid5, idempotent), which also covers the older form EMtools still writes (US -has_semantic_shape-> shape with url proxies/<US>.glb). Convex hulls and spheres stay in the shape's data and ask for no resource. ADDITIVE: nothing narrowed. v1.6.27 (LA GEOMETRIA DELLA LETTURA, 2026-10-06, decision of E.D. 2026-09-29): the place of a reading is ONE node, AnnotationRegion with geometry_kind (region2d | passage | point | line | polyline; node datamodel 1.6.10). The chain is extractor -extracted_from-> region -is_on_resource-> what it is on, for every kind. is_on_resource.target += RepresentationModelNode, RepresentationModelDocNode, RepresentationModelSpecialFindNode: a point/line/polyline sits on a 3D model — the one edge that was missing. NO NEW EDGE for the .glb: the region reaches it with has_semantic_shape (source 'Node', already legal), the hinge a proxy uses (Property(geometry) -> SemanticShape.url). has_linked_resource was measured and NOT used: its source does not admit an AnnotationRegion, and it is the RM's hinge to a file, not a proxy's. ADDITIVE: nothing narrowed. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.26 (DUE FRASI, 2026-10-04, E.D. 2026-09-29): combines.ui_phrase.as_source «{node} combining {x}» → «{node} of {x}» — the new node is the combiner and {x} the extractor it combines, and «Combiner combining D.3.1» said the verb twice; the eight other languages already read «di/de/von…». has_property.ui_phrase.as_source «{node} with {x}» CHECKED for every owner the edge admits (US and every stratigraphic unit, Document, RMDoc, Epoch, Graph): «US with material», «Document with height», «Epoch with absolute_time_start», «Graph with license» all read; kept. With more than one owner (v1.6.23) the same phrase names an inheriting owner created from an existing property. v1.6.25 (SUPPORTO AI E VERIFICA SUI NODI, 2026-10-04, decision of E.D. 2026-09-29): human authorship with AI support — an AI proposal a person accepts stays signed by the person, with the mark «supporto AI»; what was made with AI stays among the warnings until a person verifies it with their ORCID. On NODES this lives in `data`, with the names of the narrative blocks: `ai_assisted` {model, by (AuthorAINode id), prompt_ref, fields?}, `validated_by` (AuthorNode id with data.orcid), `validated_at`. See validated_by `node_verification_note` and s3dgraphy.ai_validation. NO EDGE CHANGED: the validated_by EDGE keeps source NarrativeNode; em.ttl widens em:validatedBy's domain to crm:E1 and adds em:aiAssistedBy/aiModel/aiPromptRef/aiAssistedField/validatedAt. v1.6.24 (L'ESTRATTORE LEGGE UN'UNITA', 2026-10-04, decision of E.D. 2026-09-29, extending the proposal of 2026-09-28 on SF/RSF): extracted_from.target += StratigraphicNode — an extractor may read FROM A UNIT that itself has the property it feeds (a reused find whose material is read off the unit it comes from), and not only from a document or an annotation region. The whole StratigraphicNode family, matched by class MRO (US, USV/s, USV/n, SF, RSF, VSF, USD, serSU…). A SUGGESTION, NOT AN ERROR: when the unit read from has no property of the same name as the property the extractor feeds, api.validate reports it under `info` (diagnostics.extraction_source_hints). The extractor keeps the name <source>.<ordinal> whatever its source is (the unit's name in place of the document's). ADDITIVE: nothing narrowed, no mapping changed. v1.6.23 (PIU' PROPRIETARI, 2026-10-04, decision of E.D. 2026-09-29, revisione della scrivania v7): a PropertyNode may have MORE THAN ONE incoming has_property — one unit INSTANTIATES another's property (a USV/s takes the material of the US it completes). The property stays ONE (one value, one paradata chain) with several owners. The inheritance is DECLARED, never automatic: the inheriting has_property carries the edge attribute `inherited: true`. The property stays in the ParadataNodeGroup of its ORIGINAL owner (the one that created it); the others refer to it through their own has_property, never through a group. See has_property `owners_note`. ADDITIVE: no edge, rule or mapping changed (has_property had no cardinality). v1.6.22 (FRASI DEGLI ARCHI, 2026-09-29, decision of E.D. 2026-09-29): `ui_phrase` {as_source, as_target} on the 34 edge types an interface proposes in a menu — the phrase that names a NEW node created linked to an existing one («US above X», «Property of X», «Document for X»). It is EM language, so it lives here and not in a consumer's i18n; the translations are in datamodel_translations.json, section `edge_types` (fields `ui_phrase_as_source` / `ui_phrase_as_target`). See `_ui_phrase_note`. ADDITIVE: no edge, rule or mapping changed. v1.6.21 (PROPRIETA' DIRETTE, 2026-09-28, decision of E.D. revising v1.6.1): has_property.source += EpochNode, GraphNode. Principle: every node that accepts properties receives them DIRECTLY. The sources are now the graph itself (GraphNode), the documents (DocumentNode, RepresentationModelDocNode), every stratigraphic unit (StratigraphicNode, matched by class MRO so SF, RSF, serSU, USD, USN, USNt... are included; the USNt node_type_restriction has scope stratigraphic and does not narrow has_property) and the epochs (EpochNode). v1.6.1 had routed an epoch's absolute_time_start/end through a ParadataNodeGroup because has_property refused an EpochNode (StratiMiner epoch claims degraded to generic_connection). The ParadataNodeGroup (DP-60, E89) is NOT a mandatory passage: it is a grouping, which can be created on the fly, useful to connect something to the whole set of a node's properties (connecting to the group equals connecting to each member PropertyNode) or to one property inside it. Coherence rule (validator, not datamodel): a PropertyNode in the PNG of X (is_in_paradata_nodegroup + X has_paradata_nodegroup PNG) requires X has_property that PropertyNode. has_paradata_nodegroup.source keeps EpochNode. NOT TOUCHED, question for E.D.: the cidoc P43_has_dimension has domain E70 Thing; A8/E31/E73 satisfy it, an E4 Period does not. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.20 (UNA GRAFIA SOLA, 2026-09-27): NEW optional field `spelling_of` on an edge entry, naming the canonical entry of which this one is an OLDER SPELLING. Meaning: the SAME relation, the SAME RDF projection, ACCEPTED WHEN READ, NEVER WRITTEN — every writer (importers, exporters, merge, inference, sync) asks the datamodel for the canonical name (connections_loader: canonical_name / is_canonical False / normalize_edge_name) instead of keeping its own list. It is NOT `deprecated`: `deprecated` drops the edge from RDF on export AND import (measured: an is_bonded_to marked deprecated leaves 0 em:bondedTo triples), which is right for has_timebranch that nobody writes and wrong for a spelling pyArchInit writes every day. Set on the two legacy physical bonds: is_bonded_to spelling_of bonded_to, is_physically_equal_to spelling_of equals. em.ttl is unchanged: it already has ONE property per pair (em:bondedTo, em:physicallyEquals) and its `Maps to:` names both spellings. The datamodel is the source of truth for names (docs/SOURCE_OF_TRUTH.md). s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.18 (CRMem WIRING, 2026-09-24): il prefisso CIDOC-S3D esce dal datamodel. Non era un namespace: era una stringa che _resolve_prefixed non risolve, quindi nessuna tripla veniva emessa da quei campi. Disposizione termine per termine: incompatibleWith -> em:contrastsWith; belongsToAlternative -> em:belongsToAlternative (is_in_timebranch e has_timebranch); hasSymbolicSpatialRepresentation -> em:hasSemanticShape; isPartOfParadataGroup e hasParadataDocumentation RIMOSSI, perche' crm:P106i_forms_part_of e crm:P129i_is_subject_of dicono gia' quello che serve una volta tipizzato il gruppo; has3DRepresentation RIMOSSO sui tre archi di rappresentazione, perche' crm:P138i_has_representation con la co-tipizzazione del target a E36_Visual_Item basta e il '3D' sta nel rdf:type del bersaglio, non nella relazione. INOLTRE contrasts_with perde crm:P15_was_influenced_by: dominio E7_Activity contro un E4_Period, e comunque un'altra proposizione. Esce sulla sola em:contrastsWith. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.17 (CIDOC REPAIR, 2026-09-21): a pass over IRIs that do not exist. An undeclared IRI raises no error anywhere — it makes a well-formed triple that no reasoner uses and no query finds — so these were found by parsing the official releases (CIDOC CRM 7.1.3 + Supplement, CRMarchaeo 2.1.1, CRMinf 1.2.1, CRMsci 3.2, CRMdig 5.0, CRMgeo) and checking every term this file cites against them. FIXED: the nine physical-relation edges (abuts, cuts, fills, overlies, bonded_to, is_bonded_to, equals, is_physically_equal_to, generic_connection) moved from AP11_has_physical_relation to AP11_has_physical_relation_to, the name CRMarchaeo has used since 2.0 — the old one exists only in 1.4.1. is_after: crm:P120_occurs_before is not declared in CRM 7.1.3, so crmarchaeo:AP28_occurs_before — already the extension_mapping, and the same proposition — is promoted to `cidoc` and the extension_mapping cleared; rdf_subject=target is UNCHANGED and still right. has_same_time: crm:P114_is_equal_in_time_to undeclared, same promotion of AP22. changed_from: P123_resulted_from -> P123i_resulted_from (the «i» of the inverse was missing). has_geoposition: the crmgeo:Q4 extension_mapping removed, P53 alone being valid and sufficient. THREE PROJECTIONS RAN BACKWARDS, none of them declaring rdf_subject, so the exporter wrote source-first and the proposition came out reversed: is_in_paradata_nodegroup P106_is_composed_of -> P106i_forms_part_of, has_paradata_nodegroup P70_documents -> P129i_is_subject_of (the reason ParadataNodeGroup becomes E89 in the node datamodel), and is_in_activity, where P9_consists_of is removed and NOTHING replaces it: neither P9i (needs an E4 Period as subject) nor P129i (needs an E89 as object; ActivityNodeGroup is E7) holds, and the empty field is a question for E.D., not an omission. Inverse properties were preferred to rdf_subject throughout: one indirection less. ALSO, by decision of E.D.: has_first_epoch and survive_in_epoch both accept FunctionalUnitNodeGroup, so a functional unit carries its own temporal index — the asymmetry with ActivityNodeGroup, which takes the first and never the second, is meant, because an activity is an event and a functional unit is a thing that persists. «CRMs3D» is renamed «CRMem», in components and in referenced_ontology_versions alike: the companion ontology is em.ttl and its namespace is em:, so the old name pointed at nothing anyone could look up. CRMsci moves 3.1 -> 3.2 (latest release). NOT TOUCHED and still open: the seven CIDOC-S3D properties and their extension_mappings, the E36 co-typing on has_representation_model*, and the direction of has_sub_epoch's P10_falls_within, which the repair report of the same day records as a decision for E.D. 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).",
+  "s3Dgraphy_connections_model_version": "1.6.31",
+  "description": "v1.6.31 (LA REVISIONE DELLA RISORSA, 2026-10-20, decision of E.D. 2026-09-30): NEW was_revision_of / had_revision — ResourceNode → ResourceNode, prov:wasRevisionOf (CIDOC projection crmdig:L21_used_as_derivation_source, as dtc_derived_from, because CRMdig has no term of its own for a revision). The name is the one the em.json container already uses for a ProjectVersion (container.py ProjectVersion.was_revision_of, projected as prov:wasRevisionOf by the RDF exporter): until now it was a FIELD of a document version, never an edge; it is widened here to resources. replace_file makes a NEW resource (same fields, the same files but the replaced one, the new file dtc_derived_from the old file) that was_revision_of the old one; the old one stays as it was, citable, and what pointed at it does not move by itself. No ui_phrase: a revision is made by replace_file, never picked from a menu. ADDITIVE: nothing narrowed. v1.6.30 (LA RISORSA E I SUOI FILE, 2026-10-18, decision of E.D. 2026-09-30): NEW has_file / is_file_of — ResourceNode → ResourceFileNode (node datamodel 1.6.17), crm:P106_is_composed_of + prov:hadMember; the edge `attributes` carry role (entry_point | member) and the path relative to the entry point, because one file sits in several resources under different paths. dtc_derived_from.source/target += ResourceFileNode, so a corrected texture declares the texture it comes from. Representations of the same thing (the datablock in the .blend as master, an OBJ export as distribution) are sibling ResourceNodes tied by dtc_derived_from: no new edge. NO REVISION EDGE exists for resources (measured: none of the 56 edges says «is a revision of»); replace_file keeps the old file and declares the new one derived from it, and the missing edge is reported, not invented. ADDITIVE: nothing narrowed. v1.6.29 (LA GEOMETRIA PER ORIGINE, 2026-10-11, decision of E.D. 2026-09-30): the vertices of a point / line / polyline reading are data of the region (node datamodel 1.6.15, data.coords); has_semantic_shape no longer carries a reading's .glb (the 1.6.27 hinge is migrated on opening). has_linked_resource.source += AnnotationRegionNode: above coords.inline_max_vertices (500) the vertices go to a .glb RESOURCE the region reaches with has_linked_resource (P67), as a proxy's shape and an RM do. ADDITIVE: nothing narrowed. v1.6.28 (IL PROXY COME RISORSA, 2026-10-11, decision of E.D. 2026-09-30): the proxy is a property of the US and its .glb is a RESOURCE. has_linked_resource.source += SemanticShapeNode: the shape reaches its glb with has_linked_resource -> ResourceNode(url_type proxy_model), the same hinge a Representation Model uses for its bytes (P67_refers_to), instead of carrying the path in its own url. SemanticShape.url is READ, never written: on opening, a shape with a url and no resource gets one (geometry/migrate.py, uuid5, idempotent), which also covers the older form EMtools still writes (US -has_semantic_shape-> shape with url proxies/<US>.glb). Convex hulls and spheres stay in the shape's data and ask for no resource. ADDITIVE: nothing narrowed. v1.6.27 (LA GEOMETRIA DELLA LETTURA, 2026-10-06, decision of E.D. 2026-09-29): the place of a reading is ONE node, AnnotationRegion with geometry_kind (region2d | passage | point | line | polyline; node datamodel 1.6.10). The chain is extractor -extracted_from-> region -is_on_resource-> what it is on, for every kind. is_on_resource.target += RepresentationModelNode, RepresentationModelDocNode, RepresentationModelSpecialFindNode: a point/line/polyline sits on a 3D model — the one edge that was missing. NO NEW EDGE for the .glb: the region reaches it with has_semantic_shape (source 'Node', already legal), the hinge a proxy uses (Property(geometry) -> SemanticShape.url). has_linked_resource was measured and NOT used: its source does not admit an AnnotationRegion, and it is the RM's hinge to a file, not a proxy's. ADDITIVE: nothing narrowed. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.26 (DUE FRASI, 2026-10-04, E.D. 2026-09-29): combines.ui_phrase.as_source «{node} combining {x}» → «{node} of {x}» — the new node is the combiner and {x} the extractor it combines, and «Combiner combining D.3.1» said the verb twice; the eight other languages already read «di/de/von…». has_property.ui_phrase.as_source «{node} with {x}» CHECKED for every owner the edge admits (US and every stratigraphic unit, Document, RMDoc, Epoch, Graph): «US with material», «Document with height», «Epoch with absolute_time_start», «Graph with license» all read; kept. With more than one owner (v1.6.23) the same phrase names an inheriting owner created from an existing property. v1.6.25 (SUPPORTO AI E VERIFICA SUI NODI, 2026-10-04, decision of E.D. 2026-09-29): human authorship with AI support — an AI proposal a person accepts stays signed by the person, with the mark «supporto AI»; what was made with AI stays among the warnings until a person verifies it with their ORCID. On NODES this lives in `data`, with the names of the narrative blocks: `ai_assisted` {model, by (AuthorAINode id), prompt_ref, fields?}, `validated_by` (AuthorNode id with data.orcid), `validated_at`. See validated_by `node_verification_note` and s3dgraphy.ai_validation. NO EDGE CHANGED: the validated_by EDGE keeps source NarrativeNode; em.ttl widens em:validatedBy's domain to crm:E1 and adds em:aiAssistedBy/aiModel/aiPromptRef/aiAssistedField/validatedAt. v1.6.24 (L'ESTRATTORE LEGGE UN'UNITA', 2026-10-04, decision of E.D. 2026-09-29, extending the proposal of 2026-09-28 on SF/RSF): extracted_from.target += StratigraphicNode — an extractor may read FROM A UNIT that itself has the property it feeds (a reused find whose material is read off the unit it comes from), and not only from a document or an annotation region. The whole StratigraphicNode family, matched by class MRO (US, USV/s, USV/n, SF, RSF, VSF, USD, serSU…). A SUGGESTION, NOT AN ERROR: when the unit read from has no property of the same name as the property the extractor feeds, api.validate reports it under `info` (diagnostics.extraction_source_hints). The extractor keeps the name <source>.<ordinal> whatever its source is (the unit's name in place of the document's). ADDITIVE: nothing narrowed, no mapping changed. v1.6.23 (PIU' PROPRIETARI, 2026-10-04, decision of E.D. 2026-09-29, revisione della scrivania v7): a PropertyNode may have MORE THAN ONE incoming has_property — one unit INSTANTIATES another's property (a USV/s takes the material of the US it completes). The property stays ONE (one value, one paradata chain) with several owners. The inheritance is DECLARED, never automatic: the inheriting has_property carries the edge attribute `inherited: true`. The property stays in the ParadataNodeGroup of its ORIGINAL owner (the one that created it); the others refer to it through their own has_property, never through a group. See has_property `owners_note`. ADDITIVE: no edge, rule or mapping changed (has_property had no cardinality). v1.6.22 (FRASI DEGLI ARCHI, 2026-09-29, decision of E.D. 2026-09-29): `ui_phrase` {as_source, as_target} on the 34 edge types an interface proposes in a menu — the phrase that names a NEW node created linked to an existing one («US above X», «Property of X», «Document for X»). It is EM language, so it lives here and not in a consumer's i18n; the translations are in datamodel_translations.json, section `edge_types` (fields `ui_phrase_as_source` / `ui_phrase_as_target`). See `_ui_phrase_note`. ADDITIVE: no edge, rule or mapping changed. v1.6.21 (PROPRIETA' DIRETTE, 2026-09-28, decision of E.D. revising v1.6.1): has_property.source += EpochNode, GraphNode. Principle: every node that accepts properties receives them DIRECTLY. The sources are now the graph itself (GraphNode), the documents (DocumentNode, RepresentationModelDocNode), every stratigraphic unit (StratigraphicNode, matched by class MRO so SF, RSF, serSU, USD, USN, USNt... are included; the USNt node_type_restriction has scope stratigraphic and does not narrow has_property) and the epochs (EpochNode). v1.6.1 had routed an epoch's absolute_time_start/end through a ParadataNodeGroup because has_property refused an EpochNode (StratiMiner epoch claims degraded to generic_connection). The ParadataNodeGroup (DP-60, E89) is NOT a mandatory passage: it is a grouping, which can be created on the fly, useful to connect something to the whole set of a node's properties (connecting to the group equals connecting to each member PropertyNode) or to one property inside it. Coherence rule (validator, not datamodel): a PropertyNode in the PNG of X (is_in_paradata_nodegroup + X has_paradata_nodegroup PNG) requires X has_property that PropertyNode. has_paradata_nodegroup.source keeps EpochNode. NOT TOUCHED, question for E.D.: the cidoc P43_has_dimension has domain E70 Thing; A8/E31/E73 satisfy it, an E4 Period does not. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.20 (UNA GRAFIA SOLA, 2026-09-27): NEW optional field `spelling_of` on an edge entry, naming the canonical entry of which this one is an OLDER SPELLING. Meaning: the SAME relation, the SAME RDF projection, ACCEPTED WHEN READ, NEVER WRITTEN — every writer (importers, exporters, merge, inference, sync) asks the datamodel for the canonical name (connections_loader: canonical_name / is_canonical False / normalize_edge_name) instead of keeping its own list. It is NOT `deprecated`: `deprecated` drops the edge from RDF on export AND import (measured: an is_bonded_to marked deprecated leaves 0 em:bondedTo triples), which is right for has_timebranch that nobody writes and wrong for a spelling pyArchInit writes every day. Set on the two legacy physical bonds: is_bonded_to spelling_of bonded_to, is_physically_equal_to spelling_of equals. em.ttl is unchanged: it already has ONE property per pair (em:bondedTo, em:physicallyEquals) and its `Maps to:` names both spellings. The datamodel is the source of truth for names (docs/SOURCE_OF_TRUTH.md). s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.18 (CRMem WIRING, 2026-09-24): il prefisso CIDOC-S3D esce dal datamodel. Non era un namespace: era una stringa che _resolve_prefixed non risolve, quindi nessuna tripla veniva emessa da quei campi. Disposizione termine per termine: incompatibleWith -> em:contrastsWith; belongsToAlternative -> em:belongsToAlternative (is_in_timebranch e has_timebranch); hasSymbolicSpatialRepresentation -> em:hasSemanticShape; isPartOfParadataGroup e hasParadataDocumentation RIMOSSI, perche' crm:P106i_forms_part_of e crm:P129i_is_subject_of dicono gia' quello che serve una volta tipizzato il gruppo; has3DRepresentation RIMOSSO sui tre archi di rappresentazione, perche' crm:P138i_has_representation con la co-tipizzazione del target a E36_Visual_Item basta e il '3D' sta nel rdf:type del bersaglio, non nella relazione. INOLTRE contrasts_with perde crm:P15_was_influenced_by: dominio E7_Activity contro un E4_Period, e comunque un'altra proposizione. Esce sulla sola em:contrastsWith. s3Dgraphy connections datamodel including edge types with CIDOC-CRM mappings. v1.6.17 (CIDOC REPAIR, 2026-09-21): a pass over IRIs that do not exist. An undeclared IRI raises no error anywhere — it makes a well-formed triple that no reasoner uses and no query finds — so these were found by parsing the official releases (CIDOC CRM 7.1.3 + Supplement, CRMarchaeo 2.1.1, CRMinf 1.2.1, CRMsci 3.2, CRMdig 5.0, CRMgeo) and checking every term this file cites against them. FIXED: the nine physical-relation edges (abuts, cuts, fills, overlies, bonded_to, is_bonded_to, equals, is_physically_equal_to, generic_connection) moved from AP11_has_physical_relation to AP11_has_physical_relation_to, the name CRMarchaeo has used since 2.0 — the old one exists only in 1.4.1. is_after: crm:P120_occurs_before is not declared in CRM 7.1.3, so crmarchaeo:AP28_occurs_before — already the extension_mapping, and the same proposition — is promoted to `cidoc` and the extension_mapping cleared; rdf_subject=target is UNCHANGED and still right. has_same_time: crm:P114_is_equal_in_time_to undeclared, same promotion of AP22. changed_from: P123_resulted_from -> P123i_resulted_from (the «i» of the inverse was missing). has_geoposition: the crmgeo:Q4 extension_mapping removed, P53 alone being valid and sufficient. THREE PROJECTIONS RAN BACKWARDS, none of them declaring rdf_subject, so the exporter wrote source-first and the proposition came out reversed: is_in_paradata_nodegroup P106_is_composed_of -> P106i_forms_part_of, has_paradata_nodegroup P70_documents -> P129i_is_subject_of (the reason ParadataNodeGroup becomes E89 in the node datamodel), and is_in_activity, where P9_consists_of is removed and NOTHING replaces it: neither P9i (needs an E4 Period as subject) nor P129i (needs an E89 as object; ActivityNodeGroup is E7) holds, and the empty field is a question for E.D., not an omission. Inverse properties were preferred to rdf_subject throughout: one indirection less. ALSO, by decision of E.D.: has_first_epoch and survive_in_epoch both accept FunctionalUnitNodeGroup, so a functional unit carries its own temporal index — the asymmetry with ActivityNodeGroup, which takes the first and never the second, is meant, because an activity is an event and a functional unit is a thing that persists. «CRMs3D» is renamed «CRMem», in components and in referenced_ontology_versions alike: the companion ontology is em.ttl and its namespace is em:, so the old name pointed at nothing anyone could look up. CRMsci moves 3.1 -> 3.2 (latest release). NOT TOUCHED and still open: the seven CIDOC-S3D properties and their extension_mappings, the E36 co-typing on has_representation_model*, and the direction of has_sub_epoch's P10_falls_within, which the repair report of the same day records as a decision for E.D. 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",
@@ -1574,13 +1574,85 @@
       },
       "allowed_connections": {
         "source": [
-          "ResourceNode"
+          "ResourceNode",
+          "ResourceFileNode"
         ],
         "target": [
+          "ResourceNode",
+          "ResourceFileNode"
+        ],
+        "_note": "WIDENED 2026-10-18 (connections 1.6.30): ResourceFileNode on both sides, so a corrected file (a texture) declares the file it was made from — file → file, as resource → resource already did. Mixing the two (a resource derived from a file) is admitted by the lists and is not the intended use: a resource derives from a resource, a file from a file."
+      }
+    },
+    "has_file": {
+      "name": "has_file",
+      "label": "Has file",
+      "description": "A RESOURCE (the set, the handle a person stamps, cites and opens) has ONE OF ITS FILES (E.D. 2026-09-30, «la risorsa e i suoi file»). The edge — not the file — carries in its `attributes` the ROLE (`entry_point`: the file a reader opens first, e.g. the obj or tileset.json; `member`: a file the entry point calls, e.g. the mtl and the textures) and the PATH relative to the entry point's location (`path`, e.g. 'textures/T_OB_PODIO_LOD1.jpg'), because the same file sits in N resources under N different paths. With ONE file the edge is implicit and not written: the ResourceNode's own url and checksum are that file.",
+      "reverse": {
+        "name": "is_file_of",
+        "label": "Is file of"
+      },
+      "ui_phrase": {
+        "as_source": "{node} with file {x}",
+        "as_target": "{node} file of {x}"
+      },
+      "attributes": {
+        "role": {
+          "type": "string",
+          "values": [
+            "entry_point",
+            "member"
+          ],
+          "required": true,
+          "description": "entry_point = the door a reader opens; member = what the door calls. Exactly one entry_point per resource with files."
+        },
+        "path": {
+          "type": "string",
+          "required": false,
+          "description": "relative to the entry point's location; the entry point's own path is its file name. MEASURED: edge attributes survive em.json (exporter schema 1) and do NOT survive GraphML, whose edges carry no attributes — a GraphML round trip loses role and path, and a resource with several files is not a GraphML concept."
+        }
+      },
+      "mapping": {
+        "cidoc": "P106_is_composed_of",
+        "cidoc_extension": "CIDOC-CRM",
+        "extension_mapping": "prov:hadMember",
+        "extension_name": "PROV-O",
+        "rationale": "crm:P106_is_composed_of (E90 Symbolic Object → E90): the resource (E73) is composed of the file (crmdig:D1 ⊂ E73), both E90, same direction as the edge. prov:hadMember (Collection → Entity) says the same in PROV. The role and the path are edge data and are not projected."
+      },
+      "allowed_connections": {
+        "source": [
           "ResourceNode"
+        ],
+        "target": [
+          "ResourceFileNode"
         ]
       }
     },
+    "was_revision_of": {
+      "name": "was_revision_of",
+      "label": "Was revision of",
+      "description": "A RESOURCE is a REVISION of an earlier resource (E.D. 2026-09-30, «la revisione della risorsa»): the same thing, with one file replaced — a corrected texture. The newer resource is the source, the older the target. The older one stays as it was and citable; the revision is a new ResourceNode with the same fields and the same files but the replaced one, and the new file declares dtc_derived_from the old file. What pointed at the old resource (a Representation Model, a property, a document) is NOT moved by the edge nor by replace_file: whoever calls decides. The chain is read with s3dgraphy.api.revisions_of / current_revision. Same name as ProjectVersion.was_revision_of in the em.json container, which says the same thing of a document version.",
+      "reverse": {
+        "name": "had_revision",
+        "label": "Had revision"
+      },
+      "mapping": {
+        "cidoc": "crmdig:L21_used_as_derivation_source",
+        "cidoc_extension": "CRMdig",
+        "extension_mapping": "prov:wasRevisionOf",
+        "extension_name": "PROV-O",
+        "rationale": "prov:wasRevisionOf (Entity → Entity it revises, a subproperty of prov:wasDerivedFrom) says exactly this, in the edge's direction (newer → older); it is also how the RDF exporter already projects a ProjectVersion's was_revision_of. CRMdig has no term for a revision, so the CIDOC projection is the derivation it specialises, crmdig:L21_used_as_derivation_source, as dtc_derived_from."
+      },
+      "allowed_connections": {
+        "source": [
+          "ResourceNode"
+        ],
+        "target": [
+          "ResourceNode"
+        ],
+        "_note": "2026-10-20 (connections 1.6.31): resources only. A file is not revised, it is replaced: the new file derives from the old with dtc_derived_from, and the RESOURCE (the set) is what has revisions."
+      }
+    },
     "has_registration_transform": {
       "name": "has_registration_transform",
       "label": "Placed by",