diff --git a/.github/scripts/test_live_site.py b/.github/scripts/test_live_site.py index e5a04f3..481a756 100644 --- a/.github/scripts/test_live_site.py +++ b/.github/scripts/test_live_site.py @@ -17,17 +17,17 @@ def response(self, path): return {"status": 200, "sha256": hashlib.sha256((self.root / path).read_bytes()).hexdigest(), "headers": {"content-type": "text/plain; charset=utf-8"}} - def test_all_58_files_including_markers_and_exact_16_negative_paths_are_checked(self): + def test_all_declared_files_including_markers_and_exact_16_negative_paths_are_checked(self): seen = [] def fetch(path): seen.append(path) return self.response(path) result = check_public(self.root, self.paths, fetch) self.assertTrue(result["passed"]) - self.assertEqual(result["positive_count"], 58) + self.assertEqual(result["positive_count"], len(self.paths)) self.assertEqual(result["negative_count"], 16) self.assertEqual(set(seen), self.paths | set(NEGATIVE_PATHS)) - self.assertEqual(len(seen), 74) + self.assertEqual(len(seen), len(self.paths) + 16) def test_legacy_bytes_fallback_redirect_missing_positive_and_bad_mime_fail(self): cases = (("README.md", {"status": 200}), diff --git a/MANIFEST.md b/MANIFEST.md index 78bdc7b..c68d4e8 100644 --- a/MANIFEST.md +++ b/MANIFEST.md @@ -61,6 +61,7 @@ admits future files. - `recipes/index.html` - `repository-mcp/index.html` - `robots.txt` +- `semantic-standards/index.html` - `sitemap.xml` - `strategy-and-behaviour/index.html` - `ttrs/index.html` diff --git a/index.html b/index.html index 3a8a192..a75e77b 100644 --- a/index.html +++ b/index.html @@ -171,7 +171,7 @@

One model, every layer

  • Technical layers — PlantUML. Sequence, state, ER/class, and C4 component diagrams — generated from the same model — render in PlantUML, natively inside Studio: no Java, no Graphviz, works even in the browser via vscode.dev. Studio previews PlantUML the way it previews Markdown — a foreign format, not a Transitrix notation.
  • Mermaid, as a fallback. Where a lighter, quicker view is enough, the same layers also render in standard Mermaid, via the recommended editor extension.
    • -

    Built on open standards — ArchiMate 3.2 and BPMN 2.0 — with everything as plain, diffable text. Nothing is locked in: the technical views are standard PlantUML and Mermaid, and your files stay readable with or without our tooling.

    +

    ArchiMate 3.2 and BPMN 2.0 are foundations, with deliberate modelling choices and explicit interoperability limits. Read Semantic Standards and Interoperability for the profile and maintained differences register. Models remain plain, diffable text. Nothing is locked in: the technical views are standard PlantUML and Mermaid, and your files stay readable with or without our tooling.

    diff --git a/llms.txt b/llms.txt index 68a2a4c..65282d0 100644 --- a/llms.txt +++ b/llms.txt @@ -8,6 +8,8 @@ Each notation has exactly one canonical extension — either `*..tra ## Canonical reference +- [Semantic standards and interoperability](https://transitrix.com/semantic-standards/): Scope of the normative profile, persistent identifiers, provenance, validation claims and explicit ArchiMate mapping limits. Methodology holds the authoritative profile and register. + - [DSL examples](https://transitrix.com/dsl-examples/): One minimal, schema-valid YAML example per notation Transitrix Studio ships (BPMN, goals, DGCA, capability maps, process maps, process blueprints, activity networks, activity cards, scenarios, applications, products, nested blocks, compliance impact) — copy-paste ready, all on one page. - [Recipe format `.ttrs`](https://transitrix.com/recipes/): What a `.ttrs` recipe contains, how `..ttrs` is read, the `{{ … }}` directive language, and the reference states an implementation must distinguish. Links the normative specification, the reference implementation and the conformance fixture. - [Notation specs](https://github.com/transitrix/methodology/tree/main/notations): The full specification for every notation, with larger worked examples per format. diff --git a/semantic-standards/index.html b/semantic-standards/index.html new file mode 100644 index 0000000..5f984e7 --- /dev/null +++ b/semantic-standards/index.html @@ -0,0 +1,114 @@ + + + + + + Semantic Standards and Interoperability | Transitrix + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + +
    + +
    + +
    +
    +
    +
    +

    Semantic Standards and Interoperability

    +

    Keep the meaning when a model crosses a boundary: identity, context, mapping limits and evidence matter as much as the format.

    +
    + +
    +

    A foundation, with explicit differences

    +

    Transitrix uses plain-text models under Git. ArchiMate 3.2 is a starting foundation, alongside BPMN for process modelling. Transitrix also makes deliberate choices about identity, time, stakeholder interests and evidence. Better model representation takes precedence over strict fidelity.

    +

    A matching name does not guarantee a matching meaning. The maintained ArchiMate differences register records the source, rationale, status, direction and information loss for each comparison. A partial mapping stays partial; a lossy mapping names what it cannot preserve.

    +
    + +
    +

    One authoritative profile

    +

    The Transitrix Semantic Standards Profile defines obligations for explicitly declared scopes: authoring and interpretation, an optional semantic interchange contract, and a tool's claim of support. It preserves Git/YAML authoring and does not require every model to become RDF.

    +

    Within a claimed scope, MUST means required, SHOULD means a recommendation whose departure needs a reason and evidence, and MAY means optional. A declaration names its profile version, subject, source revision, supported subset and exceptions. The profile and register in Methodology are authoritative; this page is an introduction.

    +
      +
    • RDF 1.1, Turtle and JSON-LD 1.1: requirements for a selected interchange target, with explicit graph context, supported fields and losses. A serialization is not a complete mapping contract.
      • +
    • SKOS and OWL 2: distinct ways to describe retrieval concepts and formal classes. An ontology or inference regime is an optional, separately justified choice.
      • +
    • SHACL 1.0 and SPARQL 1.1: explicit constraints and questions for a declared dataset. Shape validation, inference and approval are separate.
      • +
    • PROV-O, Dublin Core Terms and DCAT 3: possible evidence and metadata mappings for actual resources and datasets. A catalogue entry alone does not establish a service or dataset publication.
      • +
    +

    ISO terminology and architecture standards inform the reviewed correspondence. Where full requirements were unavailable, clause-level conformance remains unevaluated. No upper ontology or external metadata-registry profile is adopted merely by citing it.

    +
    + +
    +

    A concept, a class and an instance

    +

    A taxonomy concept such as payment processing helps readers find related things. An ontology class such as Application describes a formally interpreted category. A particular Payments application is an instance. They can be connected without becoming the same resource.

    +

    Identifiers preserve catalogue and local scope. Two organisations can both use the same local application ID without referring to the same application. A persistent resource IRI should survive a repository move; a snapshot and a vocabulary version identify descriptions, not replacement identities.

    +

    The worked profile example shows separate identifiers, a deliberately non-equivalent vocabulary mapping and source-backed provenance. Its fictional namespaces are illustrative, not a deployed Transitrix vocabulary.

    +
    + +
    +

    Evidence is not approval

    +

    “Declared”, “observed”, “inferred” and “AI-proposed” describe different origins. A useful evidence record identifies the source and version, responsible agent and time, or keeps missing information explicitly unknown. Approval does not change how the assertion originated; a matching digest does not prove that a document was generated from particular inputs.

    +

    A query also needs a known dataset, date and inference regime. An unavailable or incomplete dataset is unknown, not a successful answer with zero results. A shape pass checks its declared constraints; it cannot by itself admit a fact or certify a model.

    +
    + +
    +

    Requirements and implemented support

    +

    Current Transitrix specifications and validators have their own documented scopes. The semantic profile is a documentation contract, not a bundled RDF exporter, OWL reasoner, SHACL engine or SPARQL endpoint. The standards review supplies evidence and illustrative checks; proposed mappings do not establish released tool capabilities.

    +

    An integration must name its implemented subset, versions, test evidence and unsupported cases before claiming support. Changed identities, relation meanings or required fields also need compatibility and migration evidence. Conceptual alignment, tested interoperability, formal conformance and certification are different claims.

    +

    For the source formats and tools you can use today, see the model examples, installation options and ArchiMate reference sheet.

    +
    +
    + + + + diff --git a/sitemap.xml b/sitemap.xml index 62bc5ad..5e6f177 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -75,6 +75,10 @@ https://transitrix.com/repository-mcp/ + + https://transitrix.com/semantic-standards/ + + https://transitrix.com/strategy-and-behaviour/