Skip to content

Linked.Archi Tools

The semantic assets documented on this site describe how architecture knowledge is represented. The tools below produce and consume it: converters lift models out of the notation tools that authored them, and agent skills answer questions against the graph that results.

Tool Role Where it lives
Converters Turn ArchiMate, BPMN, PlantUML, Structurizr/C4, Backstage and LeanIX sources into RDF aligned to the https://meta.linked.archi/ namespaces Documented here, with JAR, bundle and Docker downloads
Agent Skills (APM) Give a coding agent the graph's conventions and a tested SPARQL template library, so it can query and investigate the converted graph Documented here, with its own documentation site
WebMCP tools Let an AI agent in the browser look up terms, assets and guides on this site as data Built into every page of this site

The flow, end to end

Nothing in the chain below is a single product. Each stage is a separate tool with a file format between it and the next, which is what lets a step be replaced, re-run, or skipped entirely.

The Linked.Archi toolchain — sources are collected, converted against the ontologies of a semantic set into per-model named graphs, merged into one dataset that keeps those graphs separate, and read by SPARQL, SHACL and the APM agent skills

From authored models to a cited answer. Every arrow is a file or a dataset, not an internal call.

1 · Sources. Each audience models in the notation native to its concerns — architects in ArchiMate, analysts in BPMN, developers in C4, PlantUML and the Backstage catalogue, portfolio managers in LeanIX. No notation is asked to serve everyone, and none is converted into another before it is lifted.

2 · Collect. A Backstage catalogue and a LeanIX workspace are gathered rather than authored in one file. backstage-pull and leanix-pull fetch converter inputs and record where each file came from; they emit no RDF themselves. The other four notations are read straight from the file the modelling tool wrote.

3 · Convert. Six command-line converters lift each notation into RDF against the ontologies published on this site. What each source construct becomes is declared in a type-mapping YAML, not in converter code — which is why a custom metamodel needs no converter change. The alignment target is a whole semantic set, not just an ontology: the arch: core ontology, the notation ontology, its SKOS taxonomy, its SHACL shapes and rules, and the arch:Metamodel manifest that names them all. A converted model declares conformance to that manifest, so a consumer can find the shapes to validate it against and the vocabulary to query it with from the data alone.

4 · Named graphs. One run emits a set of named graphs per model rather than one blob: lifted facts in …/graph/semantic, curated model structure in …/graph/model, diagram geometry in …/graph/views, and PROV-O lineage in …/graph/provenance describing the others. Converters emit only the graphs their input supports — Backstage has no views because its source has no geometry. See Output Conventions and DD-15.

5 · Merge. Loading several runs into one store produces one dataset with one identity. It does not produce one graph.

6 · Query, validate, analyse. SPARQL traverses it, SHACL judges it against the shapes its metamodel names, and the APM agent skills turn a question in natural language into catalogued queries with their evidence attached.

Merging without flattening

The merge step is where most integrations lose the property that makes the rest work. Copying every source into one table produces a landscape you can query and cannot audit: two tools disagreeing about one component leaves two values and nothing pairing either with the source that asserted it.

Keeping the graphs separate inside one dataset is what avoids that. The union across models is a query-time view — a store with a union default graph gives it for free — so nothing has to be rewritten to ask a landscape-wide question, and nothing has to be re-derived to ask a source-specific one.

One dataset holding several models, each keeping its own semantic, model, views and provenance graphs, with cross-cutting reconciliation and derived graphs authored beside them

The graph boundary is the unit of provenance and the unit of trust. A query chooses which of them it reads.

Three things follow:

  • Cross-source identity is authored, not inferred. When the same real system appears as a Backstage bs:Component and an ArchiMate am4:ApplicationComponent, a reviewed skos:exactMatch link relates the two in {base}graph/reconciliation. Correspondence rather than merge, so the nodes keep their native types and no reasoner enters the everyday query path — see DD-11. Because the links live in their own graph, an identity decision can be revoked without touching source data, and a query can decline to trust them.
  • Derived triples stay separable from asserted ones. SHACL rule output lands in {base}graph/derived (DD-28), so "what was modelled" and "what was inferred" remain two different questions.
  • Flattening stays survivable. Turtle, RDF/XML and N-Triples drop graph boundaries, but model membership is asserted on every concept with arch:inModel, so a flattened artifact still reassembles into models.

Converters — models to RDF

Each converter is a self-contained command-line tool. Dataset-aware output formats preserve named graphs, triple-only formats flatten them, and a provenance graph records the run, its inputs and the graphs it emitted. Because every notation is aligned to the same foundational ontology, the landscape can be queried through common core types while each source language keeps its own semantics.

Type mappings are configuration rather than code, so a custom metamodel needs no converter change. See Converters for the available converters, output conventions, downloads and the RDF contract they share.

Agent Skills (APM) — questions against the graph

linked-archi-apm packages the graph's conventions as agent skills. There is no application: the artifact is the context and the query templates, so a coding agent in an ordinary IDE can work as an architecture analyst against converter output.

Skill Use it to
linked-archi-source Materialize verified RDF from HTTPS, a pinned Git revision, or a read-only GitLab MCP into an immutable local cache
linked-archi-profile Establish, verify and derive the profile that tells the other skills what a dataset calls things
linked-archi-connect Attach local RDF files or a read-only SPARQL endpoint, and report honestly what loaded
linked-archi-query Answer a question from a tested, profile-resolved template library
linked-archi-analyse Run a multi-query investigation and answer as a traceable evidence bundle
linked-archi-validate Run SHACL in-process, or summarize a report somebody else produced, and report coverage beside the verdict

Three properties matter for architecture work:

  • Refusal over silence — every template declares the roles and capabilities it needs. When a dataset cannot support one, the answer names the reason and suggests alternatives instead of returning an empty result that reads like a finding. Qualified relationships, named graphs, and absent ownership or cross-source identity all trip up generic text-to-SPARQL quietly, producing queries that run and mislead.
  • Vocabulary as data — profiles bind semantic roles to concrete terms, prefixes, graph layout and taxonomy terms. A profile can be derived from a converter type-mapping file or a published arch:Metamodel manifest, so a custom ontology needs no code change. la-profile verify probes the dataset and reports drift between claimed and observed terms.
  • Read-only and traceable — update, insert, delete and load are rejected before any backend is touched, and every result carries a provenance footer naming the template, query hash, dataset, profile version, timestamp and row count.

Installation, the template catalogue and the analysis patterns are summarized on the Agent Skills (APM) page and documented in full on the APM documentation site.

WebMCP tools — for agents in the browser

The converters and skills above work on a graph you have loaded. The site itself is usable by an agent too: every page of meta.linked.archi registers WebMCP tools, the draft browser API through which a page tells an AI agent in the browser what it can do. An agent helping someone through an ontology page or a guide calls these instead of scraping the page:

Tool Answers
search_terms Which classes, properties, SKOS concepts, shapes or viewpoints match some words, in one asset or across all of them
get_term Everything about one term: definition and source, hierarchy, the relationships and attributes it takes (grouped by the superclass they are inherited through), qualified forms, the SHACL shapes that target it, and its cross-language mappings
list_assets, get_asset Which ontologies, shapes, taxonomies and metamodels are published, and what a metamodel manifest brings together
search_docs, read_doc Which guide sections cover a topic, and their text
open_page Shows the reader a term's definition, an asset page or a guide section

Asked what an ArchiMate 4.0 application component can serve, for example, an agent calls get_term with am4:ApplicationComponent, finds am4:serves among the relationships inherited through am4:ActiveStructureElement, and shows the reader its definition with open_page.

The answers come from the published Turtle, not from a copy of it: the build indexes the same ontology.ttl files that content negotiation serves, so an agent sees what an RDF client would fetch. Every tool is read-only except open_page, which only navigates the tab. As of September 2026 browsers expose WebMCP only behind Chrome's origin trial or the chrome://flags/#enable-webmcp-testing flag; everywhere else the pages behave as before.