s3dgraphy 1.6.0.dev18__tar.gz → 1.6.0.dev21__tar.gz

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

@@ -1,17 +1,17 @@
 Metadata-Version: 2.4
 Name: s3dgraphy
-Version: 1.6.0.dev18
+Version: 1.6.0.dev21
 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>
 License: GPL-3.0-or-later
-Project-URL: Homepage, https://github.com/zalmoxes-laran/s3dgraphy
+Project-URL: Homepage, https://github.com/ExtendedMatrix/s3Dgraphy
 Project-URL: Documentation, https://docs.extendedmatrix.org/projects/s3dgraphy/
-Project-URL: Repository, https://github.com/zalmoxes-laran/s3dgraphy.git
-Project-URL: Bug Reports, https://github.com/zalmoxes-laran/s3dgraphy/issues
-Project-URL: Source Code, https://github.com/zalmoxes-laran/s3dgraphy
+Project-URL: Repository, https://github.com/ExtendedMatrix/s3Dgraphy.git
+Project-URL: Bug Reports, https://github.com/ExtendedMatrix/s3Dgraphy/issues
+Project-URL: Source Code, https://github.com/ExtendedMatrix/s3Dgraphy
 Project-URL: Extended Matrix, https://www.extendedmatrix.org
-Project-URL: Changelog, https://github.com/zalmoxes-laran/s3dgraphy/blob/main/CHANGELOG.md
+Project-URL: Changelog, https://github.com/ExtendedMatrix/s3Dgraphy/blob/main/CHANGELOG.md
 Keywords: archaeology,stratigraphy,graph,3d,heritage,temporal-modeling,knowledge-graph,extended-matrix
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Science/Research
@@ -81,7 +81,7 @@ Dynamic: license-file
 [![Python versions](https://img.shields.io/pypi/pyversions/s3dgraphy.svg)](https://pypi.org/project/s3dgraphy/)
 [![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)
 [![Downloads](https://pepy.tech/badge/s3dgraphy)](https://pepy.tech/project/s3dgraphy)
-[![Publish to PyPI](https://github.com/zalmoxes-laran/s3dgraphy/actions/workflows/publish.yml/badge.svg)](https://github.com/zalmoxes-laran/s3dgraphy/actions/workflows/publish.yml)
+[![Publish to PyPI](https://github.com/ExtendedMatrix/s3Dgraphy/actions/workflows/publish.yml/badge.svg)](https://github.com/ExtendedMatrix/s3Dgraphy/actions/workflows/publish.yml)
 
 ## 3D Stratigraphic Graph Management Library
 
@@ -260,7 +260,7 @@ match exactly and case-sensitively. The same flow applies to
 
 - **[User Guide](https://docs.extendedmatrix.org/projects/s3dgraphy/)** - Complete documentation
 - **[API Reference](https://docs.extendedmatrix.org/projects/s3dgraphy/api.html)** - Detailed API docs
-- **[Examples](https://github.com/zalmoxes-laran/s3dgraphy/tree/main/examples)** - Code examples and tutorials
+- **[Examples](https://github.com/ExtendedMatrix/s3Dgraphy/tree/main/examples)** - Code examples and tutorials
 - **[Extended Matrix](https://www.extendedmatrix.org)** - Framework overview
 
 ## Where this sits
@@ -284,7 +284,7 @@ framework and no socket on purpose — what it does can be proved on a table.
 ### Setting up Development Environment
 
 ```bash
-git clone https://github.com/zalmoxes-laran/s3dgraphy.git
+git clone https://github.com/ExtendedMatrix/s3Dgraphy.git
 cd s3dgraphy
 python3 -m venv .venv
 .venv/bin/pip install -e ".[dev]"
@@ -339,7 +339,7 @@ git push --follow-tags
 ## 🤝 Contributing
 
 We welcome contributions. Open an issue or a pull request on
-[GitHub](https://github.com/zalmoxes-laran/s3dgraphy) — and see the
+[GitHub](https://github.com/ExtendedMatrix/s3Dgraphy) — and see the
 [Development](#-development) section above for how to run the suite and read its
 known baseline.
 
@@ -372,7 +372,7 @@ s3Dgraphy — referencing records live or baking them into the graph.
 
 The PyArchInit integration drove the design of the LocationNodeGroup in
 s3Dgraphy 0.1.41 (insight from
-[issue #5](https://github.com/zalmoxes-laran/s3Dgraphy/issues/5) by
+[issue #5](https://github.com/ExtendedMatrix/s3Dgraphy/issues/5) by
 [Enzo Cocca](https://github.com/enzococca)).
 
 To request inclusion in this list, see the [Ecosystem page](https://docs.extendedmatrix.org/en/latest/ecosystem.html) of the Extended Matrix manual.
@@ -384,9 +384,79 @@ s3Dgraphy is designed to be consumed by independent tools. **Revit**,
 domain-specific tools are natural candidates for similar bridges into the
 Extended Matrix ecosystem. If you maintain such a project and want to
 explore an integration, open a discussion at
-[github.com/zalmoxes-laran/s3Dgraphy/discussions](https://github.com/zalmoxes-laran/s3Dgraphy/discussions)
+[github.com/ExtendedMatrix/s3Dgraphy/discussions](https://github.com/ExtendedMatrix/s3Dgraphy/discussions)
 or look at the PyArchInit integration as a worked example.
 
+## Pubblicare su PyPI
+
+Il rilascio è **manuale** — Actions → *Publish to PyPI* → *Run workflow*, con il
+tag e il bersaglio (`testpypi` o `pypi`) — e **non usa nessun token**.
+
+### Perché non un token
+
+Un token API di lunga vita nei segreti del repository è una chiave di una
+persona che tiene in ostaggio un artefatto del progetto, e non dice **da dove**
+viene la wheel. Misurato il 22 settembre 2026 sulla versione che i servizi
+installano davvero:
+
+```
+curl https://pypi.org/integrity/s3dgraphy/1.6.0.dev18/\
+     s3dgraphy-1.6.0.dev18-py3-none-any.whl/provenance
+→ 404  {"message":"No provenance available for …"}
+```
+
+Tre servizi installano questa libreria e finisce dentro le immagini Docker che
+consegniamo a un partner: chi le specchia può risalire al Dockerfile, al commit
+e al tag — e poi arriva alla wheel, e la catena si interrompe lì.
+
+Il **Trusted Publisher** toglie il token e dà l'attestazione, perché sono la
+stessa cosa vista dai due lati: PyPI si fida di un'identità — questo
+repository, questo workflow — invece che di un segreto, e quell'identità è
+esattamente ciò che l'attestazione afferma.
+
+### I campi da mettere su PyPI (una volta, e li mette E.D.)
+
+PyPI → *Your projects* → **s3dgraphy** → *Settings* → **Publishing** → *Add a
+new publisher* → **GitHub**. Quattro campi, e questi sono i valori esatti:
+
+| campo | valore |
+|---|---|
+| **Owner** | `ExtendedMatrix` |
+| **Repository name** | `s3Dgraphy` |
+| **Workflow name** | `publish.yml` |
+| **Environment name** | *(vuoto)* |
+
+`Environment name` resta vuoto perché il workflow non dichiara nessun
+`environment:`. Se un giorno gliene si dà uno — è il modo di chiedere
+un'approvazione umana prima del push su PyPI — quel campo va compilato con lo
+stesso nome, e i due devono restare d'accordo.
+
+Su **TestPyPI** la procedura è identica, sul sito `test.pypi.org`, con gli
+stessi quattro valori: sono due indici diversi e ciascuno tiene la sua lista.
+
+Finché quei campi non ci sono, il workflow **fallisce** al passo di publish con
+un errore di PyPI che dice che il publisher non è configurato — che è il modo
+giusto di fallire.
+
+### Il cancello
+
+Dopo ogni rilascio in produzione il workflow interroga l'indice:
+
+```bash
+./scripts/verifica-provenance.sh 1.6.0.dev19
+```
+
+Un publish riuscito senza provenance è un publish che ha fatto metà del lavoro
+e lo dichiara riuscito. Lo script distingue i due guasti — l'attestazione che
+**manca** e quella che nomina un **altro repository**, che è il più grave dei
+due perché sembra una garanzia — e si può lanciare a mano su qualunque versione
+già pubblicata, inclusa una di un altro progetto:
+
+```bash
+PACCHETTO=sigstore GITHUB_REPOSITORY=sigstore/sigstore-python \
+  ./scripts/verifica-provenance.sh 4.5.0
+```
+
 ## 📄 License
 
 This project is licensed under the **GNU General Public License v3.0** - see the [LICENSE](LICENSE) file for details.
@@ -402,7 +472,7 @@ If you use s3dgraphy in your research, please cite:
   title={s3dgraphy: 3D Stratigraphic Graph Management Library},
   author={Demetrescu, Emanuel},
   year={2026},
-  url={https://github.com/zalmoxes-laran/s3dgraphy},
+  url={https://github.com/ExtendedMatrix/s3Dgraphy},
   version={1.6.0},
   institution={CNR-ISPC (National Research Council - Institute of Heritage Science)}
 }
@@ -418,11 +488,11 @@ If you use s3dgraphy in your research, please cite:
 
 ## 🔗 Links
 
-- **GitHub Repository**: https://github.com/zalmoxes-laran/s3dgraphy
+- **GitHub Repository**: https://github.com/ExtendedMatrix/s3Dgraphy
 - **PyPI Package**: https://pypi.org/project/s3dgraphy/
 - **Documentation**: https://docs.extendedmatrix.org/projects/s3dgraphy/
 - **Extended Matrix Website**: https://www.extendedmatrix.org
-- **Bug Reports**: https://github.com/zalmoxes-laran/s3dgraphy/issues
+- **Bug Reports**: https://github.com/ExtendedMatrix/s3Dgraphy/issues
 
 ---
 

{s3dgraphy-1.6.0.dev18 → s3dgraphy-1.6.0.dev21}/README.md

@@ -4,7 +4,7 @@
 [![Python versions](https://img.shields.io/pypi/pyversions/s3dgraphy.svg)](https://pypi.org/project/s3dgraphy/)
 [![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)
 [![Downloads](https://pepy.tech/badge/s3dgraphy)](https://pepy.tech/project/s3dgraphy)
-[![Publish to PyPI](https://github.com/zalmoxes-laran/s3dgraphy/actions/workflows/publish.yml/badge.svg)](https://github.com/zalmoxes-laran/s3dgraphy/actions/workflows/publish.yml)
+[![Publish to PyPI](https://github.com/ExtendedMatrix/s3Dgraphy/actions/workflows/publish.yml/badge.svg)](https://github.com/ExtendedMatrix/s3Dgraphy/actions/workflows/publish.yml)
 
 ## 3D Stratigraphic Graph Management Library
 
@@ -183,7 +183,7 @@ match exactly and case-sensitively. The same flow applies to
 
 - **[User Guide](https://docs.extendedmatrix.org/projects/s3dgraphy/)** - Complete documentation
 - **[API Reference](https://docs.extendedmatrix.org/projects/s3dgraphy/api.html)** - Detailed API docs
-- **[Examples](https://github.com/zalmoxes-laran/s3dgraphy/tree/main/examples)** - Code examples and tutorials
+- **[Examples](https://github.com/ExtendedMatrix/s3Dgraphy/tree/main/examples)** - Code examples and tutorials
 - **[Extended Matrix](https://www.extendedmatrix.org)** - Framework overview
 
 ## Where this sits
@@ -207,7 +207,7 @@ framework and no socket on purpose — what it does can be proved on a table.
 ### Setting up Development Environment
 
 ```bash
-git clone https://github.com/zalmoxes-laran/s3dgraphy.git
+git clone https://github.com/ExtendedMatrix/s3Dgraphy.git
 cd s3dgraphy
 python3 -m venv .venv
 .venv/bin/pip install -e ".[dev]"
@@ -262,7 +262,7 @@ git push --follow-tags
 ## 🤝 Contributing
 
 We welcome contributions. Open an issue or a pull request on
-[GitHub](https://github.com/zalmoxes-laran/s3dgraphy) — and see the
+[GitHub](https://github.com/ExtendedMatrix/s3Dgraphy) — and see the
 [Development](#-development) section above for how to run the suite and read its
 known baseline.
 
@@ -295,7 +295,7 @@ s3Dgraphy — referencing records live or baking them into the graph.
 
 The PyArchInit integration drove the design of the LocationNodeGroup in
 s3Dgraphy 0.1.41 (insight from
-[issue #5](https://github.com/zalmoxes-laran/s3Dgraphy/issues/5) by
+[issue #5](https://github.com/ExtendedMatrix/s3Dgraphy/issues/5) by
 [Enzo Cocca](https://github.com/enzococca)).
 
 To request inclusion in this list, see the [Ecosystem page](https://docs.extendedmatrix.org/en/latest/ecosystem.html) of the Extended Matrix manual.
@@ -307,9 +307,79 @@ s3Dgraphy is designed to be consumed by independent tools. **Revit**,
 domain-specific tools are natural candidates for similar bridges into the
 Extended Matrix ecosystem. If you maintain such a project and want to
 explore an integration, open a discussion at
-[github.com/zalmoxes-laran/s3Dgraphy/discussions](https://github.com/zalmoxes-laran/s3Dgraphy/discussions)
+[github.com/ExtendedMatrix/s3Dgraphy/discussions](https://github.com/ExtendedMatrix/s3Dgraphy/discussions)
 or look at the PyArchInit integration as a worked example.
 
+## Pubblicare su PyPI
+
+Il rilascio è **manuale** — Actions → *Publish to PyPI* → *Run workflow*, con il
+tag e il bersaglio (`testpypi` o `pypi`) — e **non usa nessun token**.
+
+### Perché non un token
+
+Un token API di lunga vita nei segreti del repository è una chiave di una
+persona che tiene in ostaggio un artefatto del progetto, e non dice **da dove**
+viene la wheel. Misurato il 22 settembre 2026 sulla versione che i servizi
+installano davvero:
+
+```
+curl https://pypi.org/integrity/s3dgraphy/1.6.0.dev18/\
+     s3dgraphy-1.6.0.dev18-py3-none-any.whl/provenance
+→ 404  {"message":"No provenance available for …"}
+```
+
+Tre servizi installano questa libreria e finisce dentro le immagini Docker che
+consegniamo a un partner: chi le specchia può risalire al Dockerfile, al commit
+e al tag — e poi arriva alla wheel, e la catena si interrompe lì.
+
+Il **Trusted Publisher** toglie il token e dà l'attestazione, perché sono la
+stessa cosa vista dai due lati: PyPI si fida di un'identità — questo
+repository, questo workflow — invece che di un segreto, e quell'identità è
+esattamente ciò che l'attestazione afferma.
+
+### I campi da mettere su PyPI (una volta, e li mette E.D.)
+
+PyPI → *Your projects* → **s3dgraphy** → *Settings* → **Publishing** → *Add a
+new publisher* → **GitHub**. Quattro campi, e questi sono i valori esatti:
+
+| campo | valore |
+|---|---|
+| **Owner** | `ExtendedMatrix` |
+| **Repository name** | `s3Dgraphy` |
+| **Workflow name** | `publish.yml` |
+| **Environment name** | *(vuoto)* |
+
+`Environment name` resta vuoto perché il workflow non dichiara nessun
+`environment:`. Se un giorno gliene si dà uno — è il modo di chiedere
+un'approvazione umana prima del push su PyPI — quel campo va compilato con lo
+stesso nome, e i due devono restare d'accordo.
+
+Su **TestPyPI** la procedura è identica, sul sito `test.pypi.org`, con gli
+stessi quattro valori: sono due indici diversi e ciascuno tiene la sua lista.
+
+Finché quei campi non ci sono, il workflow **fallisce** al passo di publish con
+un errore di PyPI che dice che il publisher non è configurato — che è il modo
+giusto di fallire.
+
+### Il cancello
+
+Dopo ogni rilascio in produzione il workflow interroga l'indice:
+
+```bash
+./scripts/verifica-provenance.sh 1.6.0.dev19
+```
+
+Un publish riuscito senza provenance è un publish che ha fatto metà del lavoro
+e lo dichiara riuscito. Lo script distingue i due guasti — l'attestazione che
+**manca** e quella che nomina un **altro repository**, che è il più grave dei
+due perché sembra una garanzia — e si può lanciare a mano su qualunque versione
+già pubblicata, inclusa una di un altro progetto:
+
+```bash
+PACCHETTO=sigstore GITHUB_REPOSITORY=sigstore/sigstore-python \
+  ./scripts/verifica-provenance.sh 4.5.0
+```
+
 ## 📄 License
 
 This project is licensed under the **GNU General Public License v3.0** - see the [LICENSE](LICENSE) file for details.
@@ -325,7 +395,7 @@ If you use s3dgraphy in your research, please cite:
   title={s3dgraphy: 3D Stratigraphic Graph Management Library},
   author={Demetrescu, Emanuel},
   year={2026},
-  url={https://github.com/zalmoxes-laran/s3dgraphy},
+  url={https://github.com/ExtendedMatrix/s3Dgraphy},
   version={1.6.0},
   institution={CNR-ISPC (National Research Council - Institute of Heritage Science)}
 }
@@ -341,11 +411,11 @@ If you use s3dgraphy in your research, please cite:
 
 ## 🔗 Links
 
-- **GitHub Repository**: https://github.com/zalmoxes-laran/s3dgraphy
+- **GitHub Repository**: https://github.com/ExtendedMatrix/s3Dgraphy
 - **PyPI Package**: https://pypi.org/project/s3dgraphy/
 - **Documentation**: https://docs.extendedmatrix.org/projects/s3dgraphy/
 - **Extended Matrix Website**: https://www.extendedmatrix.org
-- **Bug Reports**: https://github.com/zalmoxes-laran/s3dgraphy/issues
+- **Bug Reports**: https://github.com/ExtendedMatrix/s3Dgraphy/issues
 
 ---
 

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

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "s3dgraphy"
-version = "1.6.0.dev18"
+version = "1.6.0.dev21"
 description = "3D Stratigraphic Graph Management Library for archaeological and heritage applications"
 readme = "README.md"
 requires-python = ">=3.9"
@@ -60,13 +60,13 @@ dependencies = [
 ]
 
 [project.urls]
-Homepage = "https://github.com/zalmoxes-laran/s3dgraphy"
+Homepage = "https://github.com/ExtendedMatrix/s3Dgraphy"
 Documentation = "https://docs.extendedmatrix.org/projects/s3dgraphy/"
-Repository = "https://github.com/zalmoxes-laran/s3dgraphy.git"
-"Bug Reports" = "https://github.com/zalmoxes-laran/s3dgraphy/issues"
-"Source Code" = "https://github.com/zalmoxes-laran/s3dgraphy"
+Repository = "https://github.com/ExtendedMatrix/s3Dgraphy.git"
+"Bug Reports" = "https://github.com/ExtendedMatrix/s3Dgraphy/issues"
+"Source Code" = "https://github.com/ExtendedMatrix/s3Dgraphy"
 "Extended Matrix" = "https://www.extendedmatrix.org"
-Changelog = "https://github.com/zalmoxes-laran/s3dgraphy/blob/main/CHANGELOG.md"
+Changelog = "https://github.com/ExtendedMatrix/s3Dgraphy/blob/main/CHANGELOG.md"
 
 # ─────────────────────────────────────────────────────────────────────────
 # Optional features — pip install s3dgraphy[<extra>]
@@ -104,12 +104,12 @@ sync = [
     # ingestion + projection between a Graph and the host application's
     # SQL tables. SQLite works out of the box; add the [postgres] extra
     # for the PostgreSQL backend. Moved from pyArchInit in 1.6.0
-    # (zalmoxes-laran/s3Dgraphy#10).
+    # (ExtendedMatrix/s3Dgraphy#10).
     "sqlalchemy>=2.0",
 ]
 postgres = [
     # PostgreSQL backend driver. Combine with [sync] for the SQL bridge
-    # (zalmoxes-laran/s3Dgraphy#9 + #10). Standalone, it also enables
+    # (ExtendedMatrix/s3Dgraphy#9 + #10). Standalone, it also enables
     # the PG path of PyArchInitImporter when that lands.
     "psycopg2-binary>=2.9",
 ]

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

@@ -842,7 +842,7 @@
   },
   "SpecialFindUnit": {
    "description": {
-    "en": "Movable physical object whose ORIGINAL position is unknown (and sometimes whose pertinence to the site is uncertain). Distinct from in-situ artefacts — known to exist(ed) but displaced. Architectural artefacts, coins, fragments without findspot. Provenance / pertinence uncertainty is captured via paradata edges, not by class.",
+    "en": "Movable physical object whose ORIGINAL position is unknown (and sometimes whose pertinence to the site is uncertain). Distinct from in-situ artefacts — known to exist(ed) but displaced. Architectural artefacts, coins, fragments without findspot. This is also the unit for a REDEPOSITED object: a block in secondary deposition found inside a layer, which is observed where it lies but not where it was made to lie. Provenance / pertinence uncertainty is captured via paradata edges, not by class.",
     "validated_it": false,
     "validated_el": false,
     "validated_he": false,

{s3dgraphy-1.6.0.dev18 → s3dgraphy-1.6.0.dev21}/src/s3dgraphy/JSON_config/em.ttl

@@ -13,7 +13,7 @@
 @prefix xsd:       <http://www.w3.org/2001/XMLSchema#> .
 
 # ============================================================================
-# Extended Matrix (EM) Ontology — v1.6.0
+# Extended Matrix (EM) Ontology — v1.6.5
 # ============================================================================
 # Formal extension of the CIDOC-CRM family + HDT-O for the Extended Matrix
 # stratigraphic + paradata + virtual-reconstruction modeling. Companion to
@@ -31,7 +31,7 @@
 #     Python inheritance (e.g. AuthorAINode → AuthorNode) is for code reuse.
 #   * "Maps to: Python ClassName" comments anchor each class to its
 #     s3dgraphy Python counterpart for round-trip verification.
-#   * AP11_has_physical_relation discrimination uses subproperties (em:abuts,
+#   * AP11_has_physical_relation_to discrimination uses subproperties (em:abuts,
 #     em:cuts, em:fills, em:overlies, em:bondedTo, em:physicallyEquals)
 #     rather than reified relations with E55_Type tags — this is the
 #     SPARQL-friendly pattern.
@@ -44,8 +44,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.0" ;
-    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."@en ;
+    owl:versionInfo "1.6.5" ;
+    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)."@en ;
     owl:imports <http://www.cidoc-crm.org/cidoc-crm/> ,
                 <http://www.cidoc-crm.org/extensions/crminf/> ,
                 <http://www.cidoc-crm.org/extensions/crmarchaeo/> ,
@@ -305,7 +305,7 @@ em:RepresentationModel
     a owl:Class ;
     rdfs:label "Representation Model"@en ;
     rdfs:subClassOf crmdig:D1_Digital_Object ;
-    rdfs:comment "A 3D model or spatialized image representing some node in the graph. Abstract base. Specialized into em:StratigraphicRepresentation, em:DocumentaryRepresentation, em:SpecialFindRepresentation. Always linked to what it represents via crm:P138_represents."@en .
+    rdfs:comment "A 3D model or spatialized image representing some node in the graph. Abstract base. Specialized into em:StratigraphicRepresentation, em:DocumentaryRepresentation, em:SpecialFindRepresentation. Always linked to what it represents via crm:P138_represents. WHAT IT IS (E.D., 21 September 2026). A representation model is a DOCUMENT WITH A DATE: it was made on a day, by somebody, from something, and it is naturally anchored to an EPOCH rather than to a unit. It is also potentially PARTIAL — a photogrammetric survey can come back with an incomplete mesh, a facade recorded from one side only, a room whose ceiling nobody could reach. Both of those together have one consequence worth stating so nobody reasons past it: the ABSENCE of a link between a model and a stratigraphic unit IS NOT INFORMATIVE. It does not mean the unit was not represented, and it does not mean the unit is not there; it means this document does not reach that far. Queries must not read a missing link as a negative claim. The PROXY has a different statute and is not the same kind of thing: em:SemanticShape is CUMULATIVE and ARGUED — a quale synthesised from several sources, inheriting the extractor/combiner chain, so it can be more COMPLETE than any single model while being far less detailed. A model is one look at the thing; a proxy is what we have concluded the thing occupies. DATING AND PROVENANCE HAVE NO FIELD OF THEIR OWN ON THIS CLASS, and that is deliberate: they travel through has_linked_resource to a ResourceNode and back up through dtc_had_output to the DTC event that produced it, where the date, the device and the author already live and are already paradata. A `date` field MUST NOT be added to RepresentationModelNode: it would duplicate the DTC chain, drift from it, and turn a documented provenance into a typed-in string."@en .
 
 em:StratigraphicRepresentation
     a owl:Class ;
@@ -328,7 +328,12 @@ em:SpecialFindRepresentation
 em:SemanticShape
     a owl:Class ;
     rdfs:label "Semantic Shape (proxy geometry)"@en ;
-    rdfs:subClassOf crmgeo:SP5_Geometric_Place_Expression ;
+    # PROVVISORIO — crmgeo:SP6_Declarative_Place è il candidato migliore,
+    # decisione rinviata da E.D. (21 set 2026). Era crmgeo:SP5_Geometric_Place_Expression,
+    # che NON è dichiarata nel documento servito a http://www.cidoc-crm.org/extensions/crmgeo/
+    # (CRMgeo 2.0 draft: SP1,2,3,4,6,7,10,11,12,13,14,15 — SP5 sopravvive solo nella scope
+    # note di SP6). crm:E73_Information_Object è la mossa sicura che non impegna.
+    rdfs:subClassOf crm:E73_Information_Object ;
     rdfs:comment "3D proxy geometry (convex shapes or spheres, or a .glb via rdfs:seeAlso) representing the spatial extent of a node. Lighter weight than a full RepresentationModel: intended for spatial indexing and rough containment, not for visual rendering. SINCE 2026-08-11 IT IS A PAYLOAD: the proxy of a unit is a quale — a property of type 'geometry' — and this class is what that property points at through P138i (has_semantic_shape). The reason is paradata: a lone shape cannot say where it came from, while a property inherits the extractor/combiner chain, so one proxy can be synthesised from several sources (a photogrammetric mesh and a historical photograph). The class itself did not change; who points at it did. Maps to: Python SemanticShapeNode (node_type='semantic_shape')."@en .
 
 em:convexShape
@@ -483,7 +488,7 @@ em:confidenceLevel
 # ============================================================================
 # 11. STRATIGRAPHIC PHYSICAL RELATIONS (AP11 subproperties)
 # ============================================================================
-# CRMarchaeo's AP11_has_physical_relation is the generic relation between
+# CRMarchaeo's AP11_has_physical_relation_to is the generic relation between
 # two stratigraphic units. We discriminate the specific type with named
 # subproperties — the SPARQL-friendly pattern (queries can be specific
 # OR fall back to the generic AP11 via subproperty inference).
@@ -491,7 +496,7 @@ em:confidenceLevel
 em:abuts
     a owl:ObjectProperty ;
     rdfs:label "abuts"@en ;
-    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation ;
+    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation_to ;
     rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:range crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:comment "Source stratigraphic unit abuts against the target. Non-symmetric: A abuts B does NOT imply B abuts A (B is_abutted_by A). Maps to: connections_datamodel edge 'abuts'."@en .
@@ -499,7 +504,7 @@ em:abuts
 em:cuts
     a owl:ObjectProperty ;
     rdfs:label "cuts"@en ;
-    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation ;
+    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation_to ;
     rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:range crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:comment "Source stratigraphic unit cuts (is incised into) the target. Non-symmetric. Maps to: connections_datamodel edge 'cuts'."@en .
@@ -507,7 +512,7 @@ em:cuts
 em:fills
     a owl:ObjectProperty ;
     rdfs:label "fills"@en ;
-    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation ;
+    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation_to ;
     rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:range crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:comment "Source stratigraphic unit fills the target (typically a deposit filling a cut). Non-symmetric. Maps to: connections_datamodel edge 'fills'."@en .
@@ -515,7 +520,7 @@ em:fills
 em:overlies
     a owl:ObjectProperty ;
     rdfs:label "overlies"@en ;
-    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation ;
+    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation_to ;
     rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:range crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:comment "Source stratigraphic unit overlies (covers) the target. Non-symmetric. Maps to: connections_datamodel edge 'overlies'."@en .
@@ -523,7 +528,7 @@ em:overlies
 em:bondedTo
     a owl:ObjectProperty , owl:SymmetricProperty ;
     rdfs:label "bonded to"@en ;
-    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation ;
+    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation_to ;
     rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:range crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:comment "Two stratigraphic units are physically bonded (e.g. masonry bonding). Symmetric. Maps to: connections_datamodel edges 'bonded_to' / 'is_bonded_to'."@en .
@@ -531,7 +536,7 @@ em:bondedTo
 em:physicallyEquals
     a owl:ObjectProperty , owl:SymmetricProperty ;
     rdfs:label "physically equals"@en ;
-    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation ;
+    rdfs:subPropertyOf crmarchaeo:AP11_has_physical_relation_to ;
     rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:range crmarchaeo:A8_Stratigraphic_Unit ;
     rdfs:comment "Two distinct stratigraphic-unit ids refer to the same physical entity (e.g. across campaigns or archives). Symmetric. Maps to: connections_datamodel edges 'equals' / 'is_physically_equal_to'."@en .
@@ -612,13 +617,13 @@ em:UnknownNode
 em:NodeGroup
     a owl:Class ;
     rdfs:label "Node Group (abstract)"@en ;
-    rdfs:subClassOf crm:E78_Collection ;
+    rdfs:subClassOf crm:E73_Information_Object ;
     rdfs:comment "Abstract superclass of the EM grouping axes — activity (intention), paradata (justification), timebranch (alternative time), location (place), functional unit (architectural composition). A group is a Collection of nodes and never changes what its members ARE. Maps to: Python GroupNode (node_type='Group')."@en .
 
 em:ParadataNodeGroup
     a owl:Class ;
     rdfs:label "Paradata Node Group"@en ;
-    rdfs:subClassOf em:NodeGroup , crm:E78_Collection ;
+    rdfs:subClassOf em:NodeGroup , crm:E89_Propositional_Object ;
     rdfs:comment "All the paradata of one stratigraphic unit gathered as a unit, by EM convention named '[US_name]_PD'. Distinct class so the paradata groups are findable by type rather than by naming convention. Maps to: Python ParadataNodeGroup (node_type='ParadataNodeGroup')."@en .
 
 em:LocationNodeGroup
@@ -635,5 +640,112 @@ em:GeoPositionNode
 
 
 # ============================================================================
-# End of em.ttl v1.6.1
+# 12. TERMS THE DATAMODELS CITE — declared here for the first time
+#     (added 2026-09-21, repair pass on the CIDOC mapping)
+# ============================================================================
+#
+# These eight em: terms were named by s3Dgraphy_node_datamodel.json and
+# s3Dgraphy_connections_datamodel.json and never defined here. An undefined
+# term is not an error anywhere: it serialises as a perfectly well-formed IRI
+# that no reasoner can place and no query can reach through its superclass.
+# Domain, range and superclass below are READ OFF the datamodels
+# (em_extension.subclass_of, mapping.cidoc, allowed_connections) — nothing is
+# invented. Where the datamodel did not say, the field is absent and the
+# comment says so.
+
+em:FunctionalUnit
+    a owl:Class ;
+    rdfs:label "Functional Unit"@en ;
+    rdfs:subClassOf crm:E24_Physical_Human-Made_Thing ;
+    rdfs:comment "The stratigraphic units that together make up one recognisable functional or architectural component — the column made of its US, the wall made of its US (DP-72). Physical, not curatorial: it takes E24 rather than the collection class its em:NodeGroup parent carries, because a component is a whole made of parts and not a set somebody assembled. It is likewise not an em:WorkingUnit (an activity axis: why something was done) — this answers what a set of units IS. Since 2026-09-21 it is also a bearer of the temporal index: has_first_epoch and survive_in_epoch both accept it, and the asymmetry with ActivityNodeGroup (which takes has_first_epoch and never survive_in_epoch) is the point — an activity is an event and does not survive, a thing persists. Maps to: Python FunctionalUnitNodeGroup (node_type=\'FunctionalUnitNodeGroup\')."@en .
+
+em:RepresentationModelNodeGroup
+    a owl:Class ;
+    rdfs:label "Representation Model Container"@en ;
+    rdfs:subClassOf em:NodeGroup , crm:E73_Information_Object ;
+    rdfs:comment "The representation models that form ONE named set published under a single Document — «Survey 2015» under D.01, «Reconstruction» under D.09 (EM16-RMNG, 2026-09-10). The one group subtype that does not override its parent class: a container of models is a conceptual set, not a physical thing and not an event. Membership is 1:1 — a mesh belongs to exactly one container — and the container sits BESIDE the direct Document→model edges, never in between. Maps to: Python RepresentationModelNodeGroup (node_type=\'RepresentationModelNodeGroup\')."@en .
+
+em:GCPSet
+    a owl:Class ;
+    rdfs:label "Ground Control Point Set"@en ;
+    rdfs:subClassOf crm:E73_Information_Object ;
+    rdfs:comment "The set of ground control points a registration was (or will be) solved from: a documented list of measured places and, for each, where it was observed. An information object that CARRIES places and measurements without being either — it is not an E53 Place and not a crmsci:S21 Measurement. Named in the EM extension because «the control points behind this registration» is the unit archaeologists actually hand each other, and CIDOC has nothing above E73 for it. The individual observations stay payload literals in this version; exploding each point into an S21 Measurement of an E53 Place is declared as a refinement, not implied. Maps to: Python GCPSetNode (node_type=\'gcp_set\')."@en .
+
+em:RegistrationTransform
+    a owl:Class ;
+    rdfs:label "Registration Transform"@en ;
+    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:Narrative
+    a owl:Class ;
+    rdfs:label "Narrative"@en ;
+    rdfs:subClassOf crm:E33_Linguistic_Object ;
+    rdfs:comment "A narrative over the EM graph: an ordered sequence of chapters, each anchored to a lane (epoch, activity, area) or standing outside the stratigraphy (introduction, geographic placement), composed of prose blocks and embed blocks. E33 because the narrative IS linguistic content about the heritage entity — and an E33 is already an E73 Information Object in CRM, so it is versionable, licensable and embargoable like the graph itself without a second assertion. The embeds are not content but references, and project as P67_refers_to. Endorsement is a separate act and a separate edge: see em:validatedBy. Maps to: Python NarrativeNode (node_type=\'narrative\')."@en .
+
+em:NeutralSU
+    a owl:Class ;
+    rdfs:label "Neutral Stratigraphic Unit (USNt)"@en ;
+    rdfs:subClassOf crmarchaeo:A3_Stratigraphic_Interface ;
+    rdfs:comment "PROVISIONAL (datamodel extension_status: proposed_provisional — the class is declared so the IRI stops being undefined, NOT because the CIDOC placement is settled). A void that is part of the DESIGN and not the product of a destruction: the risparmi of masonry, a window or door opening, a niche, the empty volume of a room. The wall was built around it, so nothing was ever removed — which is what separates it from the negative unit, whose void is what a destructive act left behind. A3 Stratigraphic Interface is the better-informed placeholder; the genesis it wants is CONSTRUCTIVE (A4-flavoured), not the A5 destructive modification the negative unit takes. Consequence already enforced in the connections datamodel: USNt takes is_after / is_before and nothing else — a void cannot cut, fill, abut or bond. Maps to: Python NeutralStratigraphicUnit (stratigraphic subtype token \'USNt\' since POL6, 2026-08-04)."@en .
+
+em:hasSubEpoch
+    a owl:ObjectProperty ;
+    rdfs:label "has sub-epoch"@en ;
+    rdfs:domain crm:E4_Period ;
+    rdfs:range crm:E4_Period ;
+    rdfs:comment "Splits an epoch into ordered sub-epochs (phases): the SUBJECT is the parent epoch, the OBJECT a phase, which is itself an epoch. Direction taken from the connections datamodel, which states it in words — «Source is the parent epoch, target a phase» — and from the edge\'s own name; the reverse edge is is_in_epoch. Phases partition the parent\'s time-span: when hidden the parent holds all the units, when shown the units are distributed across the phases. NO rdfs:subPropertyOf IS ASSERTED, deliberately. The edge\'s mapping.cidoc is crm:P10_falls_within, whose containment runs the other way (a phase falls within its parent, as that mapping\'s own _comment says) — so the CRM projection of this edge is currently written source-first on the wrong end, and the superproperty here would bake that in. crm:P10i_contains is the candidate; the decision is E.D.\'s and is recorded in the repair report of 2026-09-21. Maps to: connections_datamodel edge \'has_sub_epoch\'."@en .
+
+em:validatedBy
+    a owl:ObjectProperty ;
+    rdfs:label "validated by"@en ;
+    rdfs:subPropertyOf prov:wasInfluencedBy ;
+    rdfs:domain em:Narrative ;
+    rdfs:range em:HumanAuthor ;
+    rdfs:comment "A HUMAN author endorses a piece of content: they have read it and put their name to it (EM Narrative N4, «Who Made This?»). Distinct from em:hasAuthor, and the distinction is the point: hasAuthor says who WROTE it, human or AI; validatedBy says who accepted RESPONSIBILITY for it. The range is em:HumanAuthor and never em:AIAuthor — a model endorsing a model would be a signature with nobody behind it. It is not a quality judgement and not a peer review. The absence of the property IS the unendorsed state, so a machine draft cannot claim an endorsement it never received. Superproperty and domain/range read off the connections datamodel (mapping.cidoc prov:wasInfluencedBy; source NarrativeNode, target AuthorNode). prov:wasInfluencedBy is the domain-neutral anchor because it is true and claims nothing more: endorsement has no exact term in CIDOC-CRM or PROV-O, and the datamodel records that an E13 Attribute Assignment reification is where this would change. Maps to: connections_datamodel edge \'validated_by\'."@en .
+
+
+# ============================================================================
+# CRMem v1.6.3 (2026-09-21) — the first of the four surviving CRMem properties
+# Decided by E.D. in the CIDOC-EM branch chat, 21 September 2026.
+# ============================================================================
+
+em:isInActivity
+    a owl:ObjectProperty ;
+    rdfs:label "is in activity"@en ;
+    rdfs:domain crm:E1_CRM_Entity ;
+    rdfs:range crm:E7_Activity ;
+    rdfs:comment "An entity of any kind — a stratigraphic unit, a quale, a document, an extractor, a whole paradata group — is CLASSIFIED UNDER an activity-shaped grouping. This is the axis of INTENTION in the Extended Matrix, orthogonal to space (is_in_location) and to time (the epoch edges), and it is a curatorial grouping and not an event anyone attended. NO SUPERPROPERTY, deliberately, and the reason is the whole justification for the term: CIDOC can say that an actor PARTICIPATED in an event (P11i), that a thing WAS PRESENT (P12i), that an object WAS USED (P16i) — but it cannot say that an arbitrary entity is classified under an activity. P12i would even pass the type check, because E28 Conceptual Object reaches E77 through E71/E70, but it would be false: a PropertyNode attended nothing. P9i needs an E4 Period in the subject and the sources here are not periods; P129i needs an E89 in the object and E7 Activity is not one. Verified against CIDOC CRM 7.1.3 and CRMarchaeo 2.1.1: CRMarchaeo has specific archaeological activities (A9, A1, A6) but no generic activity class and none of its 32 AP properties expresses membership in one. The CLASS is not ours — crm:E7_Activity is CIDOC core and ActivityNodeGroup stays mapped to it — only the property is. NAMED isInActivity and NOT participatedInActivity (the dead CIDOC-S3D desideratum it replaces), because participation is a claim this model does not make. Maps to: connections_datamodel edge 'is_in_activity' (sources StratigraphicNode/ParadataNode/ParadataNodeGroup/DocumentNode/ExtractorNode/CombinerNode/PropertyNode, target ActivityNodeGroup); mapping.cidoc stays EMPTY on purpose, and the exporter emits this property on its own."@en .
+
+em:belongsToAlternative
+    a owl:ObjectProperty ;
+    rdfs:label "belongs to alternative"@en ;
+    rdfs:domain crm:E1_CRM_Entity ;
+    rdfs:range em:TimeBranch ;
+    rdfs:subPropertyOf crminf:J28i_is_referred_to_in ;
+    rdfs:comment "An entity belongs to one alternative reconstruction scenario rather than another. UNLIKE em:contrastsWith and em:isInActivity this term HAS an honest ceiling: CRMinf does cover membership in a set of propositions (J28/J28i, and since 1.2 the I17 pattern with J30/J31/J32), so the extension NARROWS here instead of widening. What it adds beneath that ceiling is the identity of the scenario as an addressable thing, which the bare membership property does not carry: a reader must be able to ask which units belong to scenario B, not merely that they are referred to somewhere. Maps to: connections_datamodel edges is_in_timebranch (source StratigraphicNode, target TimeBranchNodeGroup) and the deprecated has_timebranch. Replaces the dead desideratum CIDOC-S3D:belongsToAlternative, which named the same thing under a prefix that resolved to nothing."@en .
+
+em:hasSemanticShape
+    a owl:ObjectProperty ;
+    rdfs:label "has semantic shape"@en ;
+    rdfs:domain crm:E1_CRM_Entity ;
+    rdfs:range em:SemanticShape ;
+    rdfs:comment "An entity is represented, for the purpose of spatial reasoning, by a simplified geometry that STANDS FOR it — a convex hull, a sphere, a proximity volume — as distinct from a geometry that measures it. The two answer different questions: a measured geometry says where the unit was found, a semantic shape says how it is to be reasoned about spatially when its true shape is unknown, irrelevant, or argued. NO SUPERPROPERTY: crmgeo places (SP5 and its neighbourhood) express a place expression, not a schematic stand-in, and since the proxy-as-property change of v1.6.10 the source of this relation includes a PropertyNode — a quale does not occupy a place, so a place-valued property would be false as well as imprecise. The CLASS is ours (em:SemanticShape, itself declared beneath crm:E73_Information_Object) because the stand-in is an information object and not a physical extent. Maps to: connections_datamodel edge has_semantic_shape (source Node, target SemanticShapeNode). Replaces the dead desideratum CIDOC-S3D:hasSymbolicSpatialRepresentation."@en .
+
+# ============================================================================
+# 13. NODE ELEMENTS — CRMem v1.6.5 (2026-10-20)
+#     Decided by E.D. on 2026-09-27: the definition of a unit is an ELEMENT
+#     OF THE NODE, like name and description — not a qualia.
+# ============================================================================
+
+em:hasDefinition
+    a owl:ObjectProperty ;
+    rdfs:label "has definition"@en ;
+    rdfs:subPropertyOf crm:P2_has_type ;
+    rdfs:domain crmarchaeo:A8_Stratigraphic_Unit ;
+    rdfs:range crm:E55_Type ;
+    rdfs:comment "The DEFINITION of a stratigraphic unit — strato di crollo, riempimento, taglio: the DEFINIZIONE box of the US sheet — as a concept of a controlled vocabulary (a SKOS concept, typed crm:E55_Type). It is a TYPE of the unit and nothing more, which is why it narrows crm:P2_has_type rather than widening anything: every em:hasDefinition triple IS a P2_has_type triple, and a CIDOC-only consumer reading the entailment loses nothing. What the subproperty adds is the ability to tell, in SPARQL, the definition from any other type a unit may carry. NOT EMITTED BY DEFAULT: the exporter writes crm:P2_has_type directly (node datamodel StratigraphicNode.properties.definition.rdf.with_concept), because an unreasoned store would otherwise not see the P2 edge at all; the switch is one line in that entry. A definition that carries only a label and no concept URI projects to nothing (rdf.label_only = null): a word is not a concept. Maps to: node_datamodel StratigraphicNode.properties.definition (em.json data.definition), inherited by every stratigraphic subtype."@en .
+
+# ============================================================================
+# End of em.ttl v1.6.5
 # ============================================================================

{s3dgraphy-1.6.0.dev18 → s3dgraphy-1.6.0.dev21}/src/s3dgraphy/JSON_config/em_document_types.json

@@ -3,7 +3,8 @@
     "version": "2.0",
     "last_updated": "2025-01-29",
     "maintainers": ["Emanuel Demetrescu"],
-    "license": "CC-BY-4.0",
+    "license": "CC-BY-SA-4.0",
+    "license_note": "Share-alike per allinearsi agli strumenti terminologici da cui questo datamodel prende gli ancoraggi (ICCD CC BY-SA 3.0 IT) e perche' una derivazione resti aperta. Gli identificatori AAT/CIDOC citati nei `mappings` sono RIFERIMENTI, non contenuto incorporato: lo share-alike non si propaga ai vocabolari altrui, che mantengono i propri termini.",
     "description": "Comprehensive document types definition for Extended Matrix"
   },
   "vocabulary_versions": {