A dedicated HDTO Studio would be a graphical front-end focused on the Heritage Digital Twin Ontology profile — a peer to EMStudio rather than a replacement. Both would sit over the same two commons: the s3Dgraphy property-graph substrate (the single source of truth, which now carries the HDTO HC/HP classes additively alongside the EM vocabulary) and the neutral Studio shell with its lens framework. Where EMStudio presents the stratigraphic EM profile, HDTO Studio would present the catalogue-oriented HDTO profile, but neither edits triples directly: authoring happens on the property graph and is projected to RDF/TTL, preserving the two-tier truth discipline.
For now the decision is to develop everything integrated — HDTO is reachable through the HDTO lens inside EMStudio — so this DP exists to hold the separate-GUI option open without committing to it. The shell/lens boundary is what makes the choice reversible and cheap: standing up a distinct HDTO-profile GUI later is a packaging step, not a rewrite. The trigger to revisit is external: interest from ETT / the ECHOES consortium, or a pull from the CNR sister projects who might want a general HDT/CH authoring tool. It must never duplicate the CNRS 3D scientific viewer (ioli); EMStudio and any HDTO Studio stay 2D.
2.0
Needed
Decision (2026-07-22, E.D.): develop ACCORPATO for now — HDTO lives in s3Dgraphy + as the HDTO lens in EMStudio; a separate HDTO Studio is recorded here as a future option only, NOT a deliverable (a deliverable over-commits). Revisit only on ETT / consortium buy-in or a CNR sister-project pull. Full rationale in EMStudio/.claude/wip/handoff-hdt-em-dtc-strategy.md (S4) + roadmap-interop-and-buildout.md. Housekeeping flagged while assigning this number: DP-66 is DUPLICATED (dp-66-property-inheritance-and-premise-reuse.md AND dp-66-switchable-clustering-em-editor.md) — one should be renumbered (e.g. DP-71) to fix the collision. Free gaps in the sequence: 14, 22, 42, 44, 49.