tar: vocabulary audit

Every invented term is a federation cost: a peer registry, a DCAT-AP harvester or a generic SPARQL client understands the standard term and not ours. This audit checked each tar: term against the vocabularies above — fetching the actual definitions, domains and ranges rather than working from memory — and replaced, supplemented, or kept-with-evidence accordingly.

Ground rules applied:

• Where a standard term has the same meaning and a compatible domain/range, it replaces the tar: term outright. The old term is marked owl:deprecated true in shapes/vocab.ttl and is still read as a fallback (both in projections and via SPARQL property-path alternation, e.g. prov:wasAssociatedWith|tar:atInstance), so graphs written before the audit stay queryable. It is never written again.
• Where a standard term is coarser than ours but is what harvesters actually read, both are written: the tar: literal stays authoritative for the registry's own logic, the standard triple is the interoperable supplement.
• Where nothing standard fits, the term is kept and its rdfs:comment in shapes/vocab.ttl now states specifically what was checked and why it did not fit.
• The JSON API in src/model.rs is unchanged throughout; this is the RDF underneath.

Replaced terms

Kept, with a standard supplement written beside it

Kept as-is (nothing standard fits)

Each of these now carries an rdfs:comment in shapes/vocab.ttl recording the search, so a reader does not have to redo it.

What a harvester or generic SPARQL client can now understand

Before the audit, the following facts about our records were expressed only in the invented namespace and were invisible to anything that had not read our vocabulary. Now:

• Who performed a run. ?run prov:wasAssociatedWith ?agent — the single most common PROV query pattern — now works against this registry, from any PROV-aware client, alongside the qualified form. Previously only tar:atInstance held the one-hop edge.
• Whether data is accessible. A DCAT-AP harvester reading ?distribution dct:accessRights ?r gets EU authority-table IRIs — the exact value set DCAT-AP mandates — for every distribution and data-serving instance. Open-data portals can correctly file our metadata-only health-data artifacts as NON_PUBLIC instead of displaying them as undescribed.
• Whether a run succeeded. ?run schema:actionStatus schema:FailedActionStatus, with runs typed schema:Action — legible to schema.org consumers with no profile knowledge.
• Which catalog a deployment belongs to. dcat:inCatalog / dcat:resource in both directions; a harvester walking the catalog now discovers instances as DCAT resources.
• Software cards. Short summary (dct:abstract), category (schema:applicationCategory without a proprietary duplicate), development status (codemeta:developmentStatus) and maintainer (codemeta:maintainer) are all in vocabularies that CodeMeta-based tooling (e.g. software heritage/scholarly-infrastructure crosswalks) already consumes.
• External identifiers. Run and artifact keys are dct:identifier, so deduplication and cross-referencing against other systems no longer require our namespace.
• Deletion. A tombstoned record is adms:status WITHDRAWN — a standard, queryable lifecycle statement rather than a proprietary boolean alone.

What still requires our vocabulary: capability matchmaking (tar:produces/tar:consumes), the deployment structure (tar:instanceOf/tar:runsRelease), the fine-grained access descriptor (tar:accessProtocol/tar:authMethod/tar:accessRequestURL/tar:availability's embargoed/metadata-only distinction), and operational/security bookkeeping. Each of those is documented in shapes/vocab.ttl with the reason no standard term fits.

Genuine modelling issues surfaced by the audit (not vocabulary problems)

1. availability conflates two axes. public/restricted is an access level; embargoed/metadata-only is an existence/temporal statement. This is why no single standard value set maps onto it. An embargo also has no end date in the model — if embargoes matter, dct:available (date the resource becomes available) is the standard carrier and would let embargoed→PUBLIC-from-date be said properly.
2. A "metadata-only distribution" is a slightly odd object — a dcat:Distribution that distributes nothing. The artifact-level absence of any distribution already encodes metadata-only (and overall_availability treats it so); the explicit metadata-only distribution row exists mainly to carry tar:accessRequestURL. Consider allowing access_request_url at artifact level and dropping the empty distribution.
3. Capability cannot express constraints, only type chips — already spec Q5. When that remodel happens, the Bioschemas FormalParameter shape is the natural target and would make tar:produces/tar:consumes replaceable after all.
4. Catalog membership is asserted for Instances but not for Artifacts/Software. A DCAT-AP harvester walking dcat:resource from the catalog finds deployments but not the datasets themselves; adding dcat:dataset edges on artifact registration would complete the DCAT catalog picture at one triple per artifact.

Addendum: kind gained a desktop value

Registering RDFCraft — a Nuitka-packaged executable that opens a local pywebview window — showed the kind list had no honest value for it. service was wrong (it is not hosted), library was wrong (it is an application, not something you import), workflow was wrong, and cli asserted a command-line interface it does not have. desktop was added.

Worth recording why this bit: schema:applicationCategory, which now carries this value, is free text in schema.org. The closed sh:in list is ours, not the vocabulary's. Closing an open term buys validation and costs expressiveness, and every value we failed to anticipate becomes a write the registry rejects for no good reason. capability deliberately went the other way with a free-IRI escape hatch (D11); kind has none, and that asymmetry is a deliberate trade rather than an oversight — but it is one to revisit if a third case appears.

Addendum: EuroSciVoc replaces EDAM for software topics

EDAM stays for artifact types and the biotoolsSchema export. It no longer classifies the software, because it could not: asked to describe a SHACL validator, an ontology browser, a schema builder and a CSV-to-RDF mapper, it returned the same two topics — "Ontology and terminology" and "Data management" — for all four. Four agents classified independently and each reached the same pair, because those are the only EDAM topics that fit a semantic-web estate. A facet where every value has the same count as every record is not classifying anything.

EDAM is "an ontology of concepts prevalent within bioinformatics and computational biology". These tools are not that. The mismatch showed up in the data branch too: data_2600, used here for "an RDF graph", actually means Pathway or network.

The Software Ontology (SWO) was considered and rejected: it imports GO wholesale (its roots are molecular_function and biological_process, and searching it for "validation" returns valid_for_go_annotation_extension), and it has no term for SPARQL, SHACL or the semantic web. Its genuine strength — 145 licence classes — is ground already covered by SPDX and CodeMeta.

EuroSciVoc, the EU Science Vocabulary, has semantic web, ontology (under knowledge engineering), databases, software and software development. It is what DCAT-AP uses for dct:subject, so a harvester understands these records without knowing anything about us — the same argument that put dct:accessRights on EU authority IRIs. 1064 concepts, generated by build.rs from the Publications Office SPARQL endpoint.

The result, on the same four records:

The facet went from two values covering everything to five that separate: filtering on semantic web returns RDFCraft and OntoExplorer; on software, RDFCraft and shacl-rust.

EDAM's topic branch is still bundled, typed tar:LegacyTopic so it is not offered in the picker but any record still citing an EDAM topic — ours or a federated peer's — keeps rendering a label. (It was a tar:conceptBranch "topic-edam" literal when this was written; ?branch=topic-edam still selects it, and now names the class rather than a literal on the concept.) The JSON field is still named edam_topics; renaming it would break every existing caller for a cosmetic gain, and it has always accepted any IRI (D11).