Languages and profiles: choose the tool for the question

Use established languages for distinct jobs: describing things, organising choices, checking deliveries and preserving evidence. Then state exactly which features the method selects and which the candidate actually uses.

Technical modelling guide

Method basisUpdated 7 September 2026

A partly closed teal tool case holds a wider collection, while a pen, contour template and drawing dividers are selected outside for distinct modelling jobs.

OPDA uses RDF 1.2, SPARQL 1.2 and SHACL 1.2

This is the normative language baseline in OPDA ODR-0043. RDF 1.2 describes the graph, SPARQL 1.2 queries it and SHACL 1.2 Core checks its declared constraints. Each package selects and tests a bounded feature profile; that boundary is not a switch to older standards or a claim of full-family implementation.

Start with a question, not a namespace

At Harbour Court, “what was inspected?”, “what does this finding mean?” and “does this submitted report contain the required date?” are different questions. A graph can connect their answers without making the building, a classification and a delivery rule the same kind of thing. Choosing a language means choosing the commitments appropriate to each question.

In this fictional case, the building at 14 Orchard Road contains Flat 1 and Flat 2. Its title record and address descriptions have separate identities. An inspection occurs on 12 August 2026; report v1 is issued on 14 August and corrected by report v2 on 20 August. The correction does not create another inspection. These are teaching examples, not approved property definitions, legal advice or claims about the implemented candidate.

A profile makes the selection precise: which terms and features are permitted, for which purpose, at which version, with which processing assumptions and evidence. It is neither a list of impressive standards nor a claim to implement everything those standards can express.

Read three statuses independently

External specification maturity: What the specification's owner calls the exact publication: for example a Recommendation, Working Draft or community report. This does not decide OPDA adoption.
Selected OPDA profile: What the recorded decision requires, permits, defers or blocks. A binding method can still have implementation work outstanding.
Actual candidate implementation: What a named package emits and what its recorded checks exercise. A successful parser run is not an entailment, full-profile or semantic-correctness receipt.

This page uses profile 0.5-development, with governance reconciliation dated 2026-09-07. The register's external-publication checks remain dated 2026-08-20. This chapter does not refresh those checks or change Property Pack 0.1's pinned snapshots.

The required method below follows OPDA’s adopted ODR-0046 framework and concerns 1, 2, 5, 7, 8, 9, 10 and 11. The linked local decisions govern their scoped rules and amendments. Upstream revision 67174057e6384b79d0b28b7736fe70a66e112895 is adoption provenance only. The standards and decisions chapter explains the local authority and scope.

Document both property sides; validate separately For the illustrative referenceCode property, subject-side inclusion hints and a truthful value-side RDFS range use different permitted families; SHACL requirements remain a separate contract.

The example property referenceCode is an illustrative datatype property. Its definition and property kind are explicit modelling commitments, not a validation result.
Its subject side uses schema:domainIncludes for intended alternatives Inspection and ReportVersion. Those hints do not entail that a subject has either class, or both classes.
Its value side uses one truthful rdfs:range IRI, xsd:string, which must hold for every value. That is an RDFS entailment, not a field-validation rule.
Every governed property must document both sides. Select exactly one complete mechanism family per side: one truthful single RDFS IRI, useful inclusion hints, or a governed waiver. The two sides may select different families; never mix families on a single side.
Subject mechanisms use rdfs:domain or schema:domainIncludes; value mechanisms use rdfs:range or schema:rangeIncludes. A waiver must identify its property and side, an accepted local ODR and waiver code, a non-blank English rationale and a review trigger.
SHACL separately owns required types, cardinalities, datatypes, conditional branches and per-target differences. A definition, SHACL path or target never substitutes for property-applicability documentation.

RDF 1.2 and Turtle: connect identified things

RDF statements connect a subject, a relationship and an object. The object can be another identified resource or a literal value such as a date. In the illustration, https://example.org/harbour-court/report-v2 identifies the corrected report, while https://example.org/harbour-court/inspection identifies the event it describes. Reusing those identifiers across records makes the connection explicit; using the same address text does not.

Turtle is a way to write an RDF graph. XML Schema datatypes give literal values a declared interpretation, such as a date or decimal. Neither syntax nor datatype selection settles which real thing a record describes. Nor does putting assertions in a named graph establish their authority or semantic owner. Those are decisions to record through identity distinctions and context agreements.

RDF 1.2 Concepts explains the graph model. The register below separately identifies the selected RDF 1.2 profile and candidate syntax pins: a general explanation of RDF is not a new feature-conformance claim.

RDFS and OWL: make meaning commitments carefully

A class describes a set of things; a property describes a relationship or value. Declaring one class a subclass of another says that every member of the first is also a member of the second. It is not merely a way to place a heading in a menu. Calling Harbour Court a building does not make its title record a building, even if both records display “14 Orchard Road”.

RDFS domain and range also make substantive claims. If a property's domain is Inspection, using that property entails that its subject is an Inspection. Two domains mean membership in both classes, not either one. The same all-declarations consequence applies to ranges. These are not lists of allowed form fields. RDFS defines these semantics; disabling a local reasoner does not remove them from exported statements.

Choose exactly one applicability family on each side

OPDA ODR-0037, including its 28 and 30 August 2026 amendments, requires coverage of both the subject side and the value side of every governed property. Decide each side separately. Each must use exactly one of the following families:

One universally true RDFS IRI. Use a single domain or range commitment only when its typing consequence is always warranted.
One or more Schema.org inclusion hints. Use schema:domainIncludes or schema:rangeIncludes to document intended applicability without asserting those RDFS type consequences. Hints do not enforce constraints.
An explicit governed waiver. Record the exception under an owning ODR. Leaving the side unexplained is not a waiver.

Do not mix these families on the same side. SHACL shapes and explanatory prose do not, by themselves, discharge the applicability contract. A property's subject and value sides can legitimately choose different families when their evidence warrants it.

Review a hard case: “issued on” for reports and title records

Suppose an illustrative property is intended for both a report and a title record. Adding Report and TitleRecord as two RDFS domains would say that each subject using it belongs to both classes. That is stronger than the proposed “either kind of document” intention.

Ask whether one universally true superclass is genuinely justified, whether inclusion hints express the intended alternatives, or whether a governed waiver is necessary. Do not invent a superclass merely to make the declaration pass. Then decide the value side independently: a date requirement in one delivery shape does not settle the property's universal range.

This is a review exercise, not a conformance result for a current candidate. Its useful output is the intended meaning and counterexample, not a guessed technical answer.

Use a bounded OWL profile, not unrestricted reasoning

OWL supplies formal axioms, but OPDA ODR-0043 deliberately excludes restrictions, Boolean class constructors, cardinality restrictions, closed OWL enumerations and keys from the documentation profile. Their delivery-validation requirements belong in SHACL. Under open-world semantics, missing information is not automatically false.

ODR-0044 selects a Safe Group of processing features: class and property hierarchies, inverse links, transitivity, symmetry and disjointness checks. Domain/range inference, identity merging and equivalence propagation are outside that local runtime ruleset, not outside the standards' semantics. This selection is neither full OWL reasoning nor evidence that every candidate already runs it. See classes and relationships and the OWL structural specification.

SKOS: distinguish a choice from its label

A finding might use a reviewed classification such as “urgent attention”. The classification needs a definition and scope, not just display text. SKOS gives concepts stable identifiers, preferred and alternative labels, notes and membership in concept schemes. A label can change without silently replacing the concept or the thing being classified.

Three relationships must remain distinct: Flat 1 is contained in a building; a particular thing may belong to a class; a controlled concept may have a broader concept. skos:broader does not mean physical containment or rdfs:subClassOf. It is not itself transitive; skos:broaderTransitive supports ancestry through the concept hierarchy. A SKOS concept is not automatically an OWL class.

Mapping predicates are consequential too. skos:exactMatch is transitive; skos:closeMatch is not. An exact match between concepts is not individual identity through owl:sameAs or OWL class equivalence. Calling SKOS “annotation” must not imply that its relations have no semantics. Compare the SKOS Reference with the worked names and choices chapter.

For the authoring decision, use vocabularies and classification: distinguish closed domain outcomes, open taxonomies, growing resource populations and infrastructure facets, then select their representation and validation together.

SHACL 1.2 and SPARQL 1.2: check a delivery and ask a question

A completed inspection delivery might require an inspection date and a report reference, if participants agree that rule. A draft delivery might allow them to be missing. SHACL can express supported datatype, class, count and pattern requirements in separate delivery shapes without redefining what an inspection is. The supplied graph, supplied shapes, supported features and processing assumptions must all be named.

A conforming report record does not prove that Harbour Court is safe, the inspection happened or the author was authorised. It means the supplied data met the supplied constraints under the declared conditions. Evidence and human review answer different questions. SHACL 1.2 Core does not require full RDFS inference; any inference expectation must be explicit.

SPARQL turns a reviewable question into graph patterns. “Is a date recorded for this inspection?” can become an ASK query, which returns a boolean about the matched pattern. “Which report versions describe it?” calls for a different query. Neither query establishes the truth of the underlying assertions. The language supports more query forms than Property Pack 0.1 currently uses; see the SPARQL 1.2 Query specification.

A derived answer needs its own execution evidence

OPDA ODR-0044 selects SHACL-AF TripleRule and SPARQLRule features for derivation, with rules kept separate from validation constraints. Asserted and derived statements must remain distinguishable through graph separation or provenance. Passing a shapes check does not prove that a rule executed, and selecting these rules does not adopt every SHACL-AF function or target.

At Harbour Court, do not derive a new inspection merely because a new report version exists. That would manufacture an event from a document change. Review the intended rule and its counterexample before implementation. The meaning, checks and delivery chapter separates these receipts in detail.

Metadata, provenance and time: make the answer inspectable

“The report has a date” is too vague to support a buyer's question. In the illustration, 12 August is the inspection event date; 14 August is report v1's issue date; 20 August is report v2's correction date. When a claim is valid and when a receiving system records it are further questions. One generic timestamp must not quietly stand for all of them.

Dublin Core Terms — describe the resource: The applicable concern and package profile determine the term list, not the fact that the namespace is familiar. The bounded Category 5 administrative profile selects title, creator, issued, modified and identifier, with distinct severities and a conditional subject term; it supplements the classification facets.
PROV-O — explain origins and responsibility: Connect entities, activities and agents through the selected attribution and derivation profile. Report v2's relationship to its source is different from the inspection's occurrence. Attribution identifies responsibility; it does not prove accuracy.
OWL-Time — distinguish temporal questions: Use the selected instants, intervals and temporal relationships where needed. Keep valid time, event time and recorded time distinct instead of treating a document revision as a new event.
DCAT and DQV — describe discovery and quality: A catalogue can describe a dataset, distribution or service; a quality record can state a measure and its purpose. Neither a catalogue entry nor a quality score supplies the domain meaning of “inspection”. These are candidate concerns, not claims of current Property Pack use.

OPDA ODR-0052 and ODR-0053 require bounded canonical-IRI PROV-O and OWL-Time profiles, without owl:imports. Their selection does not mean they have been implemented in Property Pack 0.1. Follow evidence and time for the worked distinction.

SSSOM: preserve the argument behind a correspondence

A mapping is another claim requiring evidence. The selected contract retains the SKOS statement and attaches SSSOM 1.0 metadata on a named RDF 1.2 reifier. Pin both endpoint sources and their versions, the mapping-set release, date and matching-process justification. SEMAPV supplies the matching-process values; that process classification does not replace the semantic argument. Confidence is optional.

This applies to internal cross-context as well as external vocabulary mappings under OPDA ODR-0051, ODR-0056, ODR-0058 and ODR-0059 R11. The RDF 1.2 triple-term layer requires its own feature evidence; it does not expand the older Basic-compatible candidate claim. Read mapping records for the exact scoped profile, amendment exclusions and illustrative syntax.

Privacy classification is not an access-control decision

A report may contain personal information. Describing its sensitivity, deciding who may use it and enforcing that decision are three different responsibilities. Linking the report into a model does not make it public, and a classification label does not grant permission to read it.

OPDA ODR-0054 uses local classification annotations with reviewed mappings to DPV concepts. It does not impose DPV's processing-activity semantics on domain classes. ODR-0057 conditionally selects the ODRL 2.2 Common Vocabulary through the DPV Profile of ODRL for retention, dynamic-state access and cross-border policies. Policies are human-curated; no automatic policy generation or enforcement is claimed.

ORG addresses organisational structures and memberships when those are the relevant relationships; it is not a substitute for every kind of role. FIBO, GeoSPARQL, credentials and DID references likewise need an actual use case and a selected term or feature boundary before use. Familiarity with their names is not selection evidence. Continue with sensitivity and policy; the register below states each technology's disposition.

Reuse, reference, map or mint — decide the relationship

Once the question is clear, decide how the model relates to the external source. These are the profile's four allowed relationship mechanisms, not four stages that every term must pass through.

Reuse the exact governed term when its meaning fits. Record the selected version, term list, licence and governance fit, and feature evidence. Reusing a canonical PROV-O term does not require importing the entire ontology.
Reference a contract or method when vocabulary adoption is not the job. A Turtle syntax profile or an analytical method can guide implementation without contributing a new property-domain term. Name the edition, question addressed and explicit conformance boundary.
Map when distinct meanings need a reviewed correspondence. Preserve both meanings and select the relation actually warranted. Record source identities and versions, relation strength, process and semantic justification, mapping date and release. Similar labels are not enough.
Mint only for a reviewed gap. A new locally governed identifier needs a defined meaning, semantic owner and source evidence. ODR-0065 now selects the OPDA namespace policy; that selection does not approve an individual term or migrate the candidate. Meaning and minting still require the responsible review. Machine-proposed candidate IRIs are not adopted terms.

owl:imports is not a citation: it brings the imported ontology's axioms through its import closure into scope. A prefix declaration is not term use, and term use is not full-vocabulary conformance. Record the actual act and its consequences.

Analytical methods do not require foundational inheritance

UFO-informed identity, role, phase and introducing-class analysis, together with OntoClean's rigidity, identity, dependence and unity checks, are selected disciplines. Their OPDA decision basis is ODR-0041 / ODR-0042, ODR-0061 / ODR-0062 and ODR-0063. They guide whether a hierarchy makes sense; ODR-0063 explicitly prohibits subsuming domain classes under external upper-ontology classes within the selected scope. This is analytical use, not foundational inheritance.

gUFO is a separate OWL implementation, not selected simply because UFO analysis is selected. DOLCE remains historical comparison evidence. Property Pack 0.1 has no separate analytical-method conformance receipt. The new foundations and modelling judgement chapter explains the four axes, their counterexamples and what the selected checks can establish. Identity through roles and change then applies the local encoding policy.

What Property Pack 0.1 actually exercises

The existing profile records Property Pack 0.1 as the current implementation example, still machine-proposed. Its small surface uses RDF 1.2 Basic-compatible Turtle, RDFS and bounded OWL vocabulary, XML Schema datatypes, SKOS, bounded SHACL 1.2 Core, limited Dublin Core Terms and four ASK/basic-graph-pattern queries tested only in ARQ 6.1.0. This is the recorded baseline, not a fresh execution result from this chapter.

Every candidate graph passes recorded Jena RIOT parsing. The complete shapes graph is exercised against one conforming and one non-conforming fixture. Those facts do not establish per-feature, cross-processor, entailment, full-profile or semantic-correctness conformance. Exact candidate snapshots remain pinned until a deliberate update supplies new evidence.

Recorded Property Pack 0.1 feature boundary — not the full selected method
Technology	Included terms or features	What is not established
RDF	`type`, written as `a` in Turtle.	No RDF feature claim beyond the declared Basic-compatible surface.
RDFS	`label`, `subClassOf`, `domain`, `range`.	No entailment receipt.
OWL	`Ontology`, `Class`, `ObjectProperty`, `DatatypeProperty`, `AnnotationProperty`, `versionInfo`.	No OWL profile or reasoner receipt; `sameAs` occurs only in a negative query.
XSD	`string`, `integer`, `anyURI`, `boolean`, `date`, `dateTime`, `decimal`.	No other datatype declared.
SKOS	`ConceptScheme`, `Concept`, `prefLabel`, `definition`, `inScheme`, `notation`.	No hierarchy, mapping, integrity or SKOS-XL claim.
SHACL	`NodeShape`, `targetClass`, `property`, `path`, `datatype`, `class`, `minCount`, `maxCount`, `pattern`.	No closed shapes, value lists, Union, AF or SPARQL constraints.
SPARQL	Four `ASK` queries using basic graph patterns.	No other query form or feature; no cross-engine portability demonstration.
Dublin Core Terms	`description`, `source`, `PhysicalResource`.	No whole-vocabulary adoption.

PROV-O has a prefix declaration only: no PROV term is emitted. There is no recorded Property Pack use of DCAT, DQV, OWL-Time, DPV, ODRL, SSSOM, FIBO, GeoSPARQL, Schema.org, Verifiable Credentials, DID, ORG, gUFO or DASH. Cross-context mappings remain empty pending working-group evidence. An empty set does not suspend the required mapping contract for future internal mappings.

The package emits RDF/OWL and SKOS graphs, SHACL shapes, JSON registers and model views, HTML documentation, ASK queries and a validation report. Possible future forms, APIs, JSON Schema, JSON-LD, PDF and Markdown projections are not all implemented outputs. Each projection needs its own purpose, package version and validation in the outputs register; “projection” is not a fifth standards relationship mechanism.

The complete standards register

All 32 records are retained below, including deferred, blocked and historical entries. Read a record to compare the selected boundary with external maturity and actual implementation. The external sources were last checked on 2026-08-20; the later governance reconciliation is not a new publication check.

Stable standard-* anchors identify individual records. A link to an external specification identifies its source, not a claim to implement its latest version.

SPDTF context-owned terms

Purpose: Terms for reviewed meaning not supplied by a suitable governed source
Selected profile boundary: OPDA ODR-0065: opda.org.uk/ns/ vocabulary topology and opda.org.uk/id/ instance convention (profile source)
OPDA governance status: Namespace policy accepted; individual term approval and implementation pending
External specification maturity: Internal governance decision · ODR-0065 · 2026-09-07. Primary specification or method source.
Actual implementation status: governed terms not yet minted
Implementation evidence: Namespace policy selected; existing machine-proposed Property Pack IRIs remain in their isolated candidate namespace
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Stable logical identifier, semantic owner and evidence required; policy adoption is not term approval or candidate migration
Relationship mechanism: mint
Semantic or technical owner: Owning domain group with Interoperability
Decision evidence: OPDA ODR-0065; ADR-0067 resource-home rule
Re-open trigger: A reviewed candidate needs a term that cannot be reused, or a namespace change would affect existing identifiers
External publication last checked: 2026-09-07

RDF 1.2 Basic

Purpose: Graph data model and serialisation substrate
Selected profile boundary: RDF 1.2 Basic profile named by ADR-0067 (profile source)
OPDA governance status: Accepted SPDTF modelling target; not a release claim
External specification maturity: W3C Candidate Recommendation Snapshot · 2026-04-07. Primary specification or method source.
Actual implementation status: used and tested in Property Pack 0.1
Implementation evidence: Turtle declares VERSION 1.2-basic and passes Jena RIOT parsing
Property Pack 0.1 pin: RDF Concepts CR snapshot · 2026-04-07
Feature and conformance boundary: Property Pack 0.1 uses Basic only. The selected mapping-record layer additionally requires RDF 1.2 triple terms and its own feature receipt; this does not extend the older candidate conformance claim
Relationship mechanism: reference
Semantic or technical owner: Interoperability
Decision evidence: OPDA ODR-0043 baseline; ADR-0067 §5.4; OPDA ODR-0058 mapping representation
Re-open trigger: A required RDF feature outside the Basic profile
External publication last checked: 2026-08-20

RDF 1.2 Turtle

Purpose: Human-readable exchange syntax for candidate RDF graphs
Selected profile boundary: Turtle syntax snapshot pinned by each candidate package (profile source)
OPDA governance status: Accepted serialisation target; snapshot is package-specific
External specification maturity: W3C Working Draft · 2026-08-12. Primary specification or method source.
Actual implementation status: used and tested in Property Pack 0.1
Implementation evidence: Every candidate graph is emitted as Turtle and passes Jena RIOT parsing
Property Pack 0.1 pin: Turtle Working Draft · 2026-05-28
Feature and conformance boundary: Parsing proves syntactic compatibility, not semantic correctness
Relationship mechanism: reference
Semantic or technical owner: Interoperability
Decision evidence: OPDA ODR-0043 baseline; ADR-0067 §5.4 and Property Pack candidate manifest
Re-open trigger: The candidate needs syntax outside the tested Turtle snapshot
External publication last checked: 2026-08-20

RDFS 1.2

Purpose: Class/property hierarchies and safe universally true domain/range declarations
Selected profile boundary: RDF Schema vocabulary with the OPDA ODR-0037 / ODR-0043 / ODR-0044 boundaries (profile source)
OPDA governance status: Normative bounded method; implementation coverage is separate
External specification maturity: W3C Working Draft · 2026-03-28. Primary specification or method source.
Actual implementation status: used in Property Pack 0.1
Implementation evidence: Labels, hierarchies, domains and ranges are emitted; no entailment-profile receipt
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Standard RDFS semantics remain intact; repeated domain/range declarations are not alternatives. Property Pack 0.1 has no entailment receipt
Relationship mechanism: reuse
Semantic or technical owner: Interoperability
Decision evidence: OPDA ODR-0037, ODR-0043 and ODR-0044; ADR-0067
Re-open trigger: A competency question requires an inference outside the selected Safe Group
External publication last checked: 2026-08-20

OWL 2

Purpose: Context-owned classes, properties and ontology metadata
Selected profile boundary: W3C Recommendation, 11 December 2012; bounded vocabulary and selected Safe Group inference (profile source)
OPDA governance status: Normative bounded method; implementation coverage is separate
External specification maturity: W3C Recommendation · 2012-12-11. Primary specification or method source.
Actual implementation status: used in Property Pack 0.1
Implementation evidence: Bounded OWL vocabulary surface is emitted; no OWL-profile conformance claim
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Selected inference is not full OWL reasoning; no restrictions, anonymous class expressions or runtime DL reasoner. Property Pack 0.1 has no OWL-profile, consistency or entailment receipt
Relationship mechanism: reuse
Semantic or technical owner: Interoperability with each domain owner
Decision evidence: OPDA ODR-0043 and ODR-0044; ADR-0067 §5.4
Re-open trigger: A required construct falls outside the selected method or a package lacks its feature receipt
External publication last checked: 2026-08-20

XML Schema datatypes

Purpose: Literal datatype identifiers used by RDF and SHACL
Selected profile boundary: XML Schema Definition Language 1.1 Part 2 (profile source)
OPDA governance status: Actual supporting use; bounded per candidate
External specification maturity: W3C Recommendation · 2012-04-05. Primary specification or method source.
Actual implementation status: used in Property Pack 0.1
Implementation evidence: Candidate datatype properties use bounded XSD literal datatypes
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Only datatypes emitted by a candidate package
Relationship mechanism: reuse
Semantic or technical owner: Interoperability with Validation maintainers
Decision evidence: Property Pack 0.1 generator and ontology corpus
Re-open trigger: A reviewed value needs a datatype outside the declared set
External publication last checked: 2026-08-20

SKOS

Purpose: Controlled vocabularies, taxonomies and conceptual mapping relations
Selected profile boundary: W3C Recommendation, 18 August 2009 (profile source)
OPDA governance status: Accepted bounded target
External specification maturity: W3C Recommendation · 2009-08-18. Primary specification or method source.
Actual implementation status: used in Property Pack 0.1
Implementation evidence: Concept schemes, concepts, labels, definitions, notations and inScheme are emitted; hierarchy and mapping predicates are absent
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Plain SKOS, including reviewed conceptual correspondence on class IRIs; standard concept semantics still apply without requiring extra explicit type assertions. SKOS-XL is not selected
Relationship mechanism: reuse
Semantic or technical owner: Vocabulary owner with Interoperability
Decision evidence: ADR-0063/0067; OPDA ODR-0036 / ODR-0051
Re-open trigger: Label modelling requires a separately governed lexical model
External publication last checked: 2026-08-20

SPARQL 1.2

Purpose: Competency and conformance queries
Selected profile boundary: Portable-design SPARQL 1.2 subset; feature manifest required per package (profile source)
OPDA governance status: Accepted portable design target; cross-engine portability is not yet demonstrated
External specification maturity: W3C Working Draft · 2026-08-20. Primary specification or method source.
Actual implementation status: used and ARQ-tested in Property Pack 0.1
Implementation evidence: Four ASK competency queries using basic graph patterns pass ARQ 6.1.0; cross-engine portability is not demonstrated
Property Pack 0.1 pin: SPARQL Query Working Draft · 2026-06-05
Feature and conformance boundary: ASK with basic graph patterns; Property Pack 0.1 is tested only with ARQ 6.1.0
Relationship mechanism: reference
Semantic or technical owner: Validation maintainers
Decision evidence: OPDA ODR-0043 baseline; ADR-0067 §5.4; Property Pack competency-query receipt
Re-open trigger: A query requires a feature outside the portable design subset
External publication last checked: 2026-08-20

SHACL 1.2 Core

Purpose: Structural and business-rule validation
Selected profile boundary: SHACL 1.2 Core target named by ADR-0067 (profile source)
OPDA governance status: Accepted bounded target
External specification maturity: W3C Working Draft · 2026-08-03. Primary specification or method source.
Actual implementation status: used and exercised in Property Pack 0.1
Implementation evidence: The complete shape graph runs against one conforming and one non-conforming fixture; no per-feature, cross-processor, Union, AF or SPARQL conformance claim
Property Pack 0.1 pin: SHACL Core Working Draft · 2026-05-16
Feature and conformance boundary: Current run fails on missing tools or failed checks; unsupported-feature rejection needs a future allow-list receipt
Relationship mechanism: reuse
Semantic or technical owner: Validation maintainers and domain owner
Decision evidence: OPDA ODR-0043 baseline; ADR-0067 §5.4; package validation receipt
Re-open trigger: A confirmed rule cannot be expressed in the Core subset
External publication last checked: 2026-08-20

SHACL Advanced Features

Purpose: Explicit rule-based materialisation, separate from validation constraints
Selected profile boundary: 2017 W3C Note; TripleRule and SPARQLRule selected by OPDA ODR-0044 (profile source)
OPDA governance status: Normative selected rules; not implemented in Property Pack 0.1
External specification maturity: W3C Working Group Note · 2017-06-08. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No SHACL-AF feature occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Only the selected rule layer is adopted, not every AF function or target; absent from Property Pack 0.1 and no processor conformance claimed
Relationship mechanism: reuse
Semantic or technical owner: Validation maintainers with domain owner
Decision evidence: OPDA ODR-0044; Property Pack 0.1 implementation boundary
Re-open trigger: A required rule needs a feature outside the selected rule profile
External publication last checked: 2026-08-20

DASH

Purpose: Possible reusable SHACL UI and constraint patterns
Selected profile boundary: Community vocabulary; version not selected (profile source)
OPDA governance status: Deferred / unselected
External specification maturity: Community vocabulary · version not selected. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No DASH term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Not selected and no conformance claim
Relationship mechanism: reference
Semantic or technical owner: Validation maintainers
Decision evidence: ADR-0063 candidate list; absent from Property Pack 0.1
Re-open trigger: A governed UI or validation requirement selects an exact DASH term
External publication last checked: 2026-08-20

Dublin Core Terms

Purpose: Source, title, dates and administrative metadata
Selected profile boundary: DCMI Terms namespace; version 2020-01-20 (profile source)
OPDA governance status: Bounded metadata reuse; additional terms require a scoped profile
External specification maturity: DCMI Recommendation · 2020-01-20. Primary specification or method source.
Actual implementation status: used in Property Pack 0.1
Implementation evidence: dcterms:description, dcterms:source and dcterms:PhysicalResource are emitted
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Reuse only the terms named by the applicable concern and package profile
Relationship mechanism: reuse
Semantic or technical owner: Provenance owner
Decision evidence: OPDA ODR-0055; ADR-0067 and Property Pack candidate
Re-open trigger: A required metadata meaning is absent or mismatched
External publication last checked: 2026-08-20

DCAT 3

Purpose: Dataset and distribution catalogue metadata
Selected profile boundary: W3C Recommendation, 22 August 2024 (profile source)
OPDA governance status: Conditional candidate
External specification maturity: W3C Recommendation · 2024-08-22. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No DCAT term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: No catalogue conformance claimed until a publishing use case exists
Relationship mechanism: reference
Semantic or technical owner: Resources and Governance
Decision evidence: PDTF schema adoption catalogue; ADR-0067
Re-open trigger: A governed dataset catalogue or external registration is required
External publication last checked: 2026-08-20

PROV-O

Purpose: Attribution, derivation, activity and agent provenance
Selected profile boundary: W3C Recommendation, 30 April 2013; Category 9 canonical-IRI profile, without owl:imports (profile source)
OPDA governance status: Normative Category 9 method; prefix-only Property Pack use is not implementation
External specification maturity: W3C Recommendation · 2013-04-30. Primary specification or method source.
Actual implementation status: not used; prefix declaration only
Implementation evidence: No PROV-O predicate or class occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Resource-level attribution only when origins are consistent; selective statement provenance for mixed origins. Local confidence annotations do not become PROV-O terms
Relationship mechanism: reuse
Semantic or technical owner: Provenance owner
Decision evidence: OPDA ODR-0052; ADR-0063/0067
Re-open trigger: A provenance competency question cannot be answered by the selected profile
External publication last checked: 2026-08-20

OWL-Time

Purpose: Instants, intervals and ordering; distinct valid time and recorded time
Selected profile boundary: W3C Recommendation, 19 October 2017; Category 10 canonical-IRI profile, without owl:imports (profile source)
OPDA governance status: Normative Category 10 method; not implemented in Property Pack 0.1
External specification maturity: W3C Candidate Recommendation Draft · 2022-11-15. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No OWL-Time term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Bounded temporal terms only; local state-transition semantics are not SKOS hierarchy. No Property Pack 0.1 implementation
Relationship mechanism: reuse
Semantic or technical owner: Temporal concern owner
Decision evidence: OPDA ODR-0053; ADR-0063/0067
Re-open trigger: A reviewed temporal question needs a construct outside the selected subset
External publication last checked: 2026-08-20

Data Privacy Vocabulary 2.0

Purpose: Purpose, processing, legal-basis and sensitivity classifications
Selected profile boundary: DPV 2.0 profile boundary; Category 11 local classifications mapped to canonical DPV concepts (profile source)
OPDA governance status: Normative Category 11 classification method
External specification maturity: Final Community Group Report — not a W3C Standard · 2.3 · 2026-02-25. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No DPV term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Local annotations describe model elements; DPV activity semantics are not imposed on ontology classes. No owl:imports or runtime authorisation claim
Relationship mechanism: map
Semantic or technical owner: DBT Smart Data group with Governance
Decision evidence: OPDA ODR-0054; ADR-0063/0067
Re-open trigger: A reviewed classification requires a new concept or a qualified policy rather than a simple value
External publication last checked: 2026-08-20

DPV Personal Data 2.0

Purpose: Personal-data categories used by local sensitivity annotations
Selected profile boundary: DPV-PD 2.0 profile boundary; reviewed local concept mappings (profile source)
OPDA governance status: Normative Category 11 classification method
External specification maturity: Final Community Group Report — not a W3C Standard · 2.3 · 2026-02-25. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No DPV-PD term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Local controlled values reference canonical DPV-PD concepts through reviewed mappings; no import or automatic classification claim
Relationship mechanism: map
Semantic or technical owner: DBT Smart Data group with Governance
Decision evidence: OPDA ODR-0054; ADR-0063/0067
Re-open trigger: A reviewed personal-data category is missing from the selected vocabulary
External publication last checked: 2026-08-20

DPV Legal 2.0

Purpose: Jurisdictional legal concepts for reviewed classifications
Selected profile boundary: DPV-LEGAL 2.0 profile boundary; applicable local concept mappings (profile source)
OPDA governance status: Normative Category 11 method; individual applicability requires review
External specification maturity: Final Community Group Report — not a W3C Standard · 2.3 · 2026-02-25. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No DPV-LEGAL term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: No legal conclusion or statutory authority implied; mappings require applicability review and do not import the vocabulary
Relationship mechanism: map
Semantic or technical owner: Governance with legal review
Decision evidence: OPDA ODR-0054; ADR-0063/0067
Re-open trigger: Legal review identifies a missing or changed applicable concept
External publication last checked: 2026-08-20

ODRL 2.2

Purpose: Human-curated permissions, prohibitions and duties for retention, dynamic-state access and cross-border policies
Selected profile boundary: ODRL 2.2 Common Vocabulary only, through the DPV Profile of ODRL (profile source)
OPDA governance status: Conditionally adopted normative method; no Property Pack 0.1 policy instances
External specification maturity: W3C Recommendation · 2018-02-15. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No ODRL term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Conditional Category 11 use only; DPV owns privacy classification and ODRL expresses policy. No standalone ODRL profile, automatic policy generation or enforcement claim
Relationship mechanism: reuse
Semantic or technical owner: DBT Smart Data group with Governance
Decision evidence: OPDA ODR-0057, qualifying ODR-0054; https://w3id.org/dpv/dpv-odrl
Re-open trigger: A reviewed policy falls outside the three permitted uses or needs a different ODRL profile
External publication last checked: 2026-08-20

SSSOM

Purpose: Required provenance for reviewed internal cross-context and external vocabulary mappings
Selected profile boundary: SSSOM 1.0 with canonical SEMAPV matching-process values; no owl:imports (profile source)
OPDA governance status: Normative Category 8 mapping profile; implementation remains outstanding
External specification maturity: Community specification · 1.0. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: Cross-context mapping set is empty; no implemented SSSOM or SEMAPV artefact or conformance receipt exists
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Assert the SKOS mapping and attach a named RDF 1.2 reifier; pin both sources, their versions and mapping-set release, justification and date. Confidence is optional; no Property Pack 0.1 artefact or conformance claimed
Relationship mechanism: reuse
Semantic or technical owner: Interoperability with the mapping owners
Decision evidence: OPDA ODR-0051, ODR-0056, ODR-0058 and ODR-0059 R11
Re-open trigger: A mapping needs a relation or provenance field outside the selected profile; do not substitute an external-only deferral
External publication last checked: 2026-08-20

FIBO

Purpose: Comparison with finance-domain meanings
Selected profile boundary: Version not selected; selection is a precondition to use (profile source)
OPDA governance status: Reference candidate only
External specification maturity: EDM Council / OMG production ontology · release not selected. Primary specification or method source.
Actual implementation status: not used or imported
Implementation evidence: No FIBO term or import occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: No import or conformance
Relationship mechanism: reference
Semantic or technical owner: Finance and Banking
Decision evidence: PDTF schema rejection register
Re-open trigger: A finance competency question would otherwise reinvent a FIBO concept
External publication last checked: 2026-08-20

GeoSPARQL

Purpose: Geometry and spatial-query semantics
Selected profile boundary: Version not selected; selection is a precondition to use (profile source)
OPDA governance status: Conditional/deferred candidate
External specification maturity: OGC Standard · 1.1 · OGC 22-047r1. Primary specification or method source.
Actual implementation status: not used or imported
Implementation evidence: No GeoSPARQL term or import occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: No reuse or conformance
Relationship mechanism: reference
Semantic or technical owner: Property Data Services
Decision evidence: PDTF schema rejection register
Re-open trigger: Title extents, search polygons or radius queries enter scope
External publication last checked: 2026-08-20

Schema.org

Purpose: Document intended alternative subject and value applicability without RDFS type entailment
Selected profile boundary: domainIncludes and rangeIncludes selected by OPDA ODR-0037; vocabulary release not separately pinned (profile source)
OPDA governance status: Normative applicability-documentation method; not emitted by Property Pack 0.1
External specification maturity: Community vocabulary · version not selected. Primary specification or method source.
Actual implementation status: not used or imported
Implementation evidence: No Schema.org term or import occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Each property side uses one safe RDFS declaration, Schema.org inclusion hints, or a governed waiver; never mix families on the same side. No blanket Schema.org import or publication mapping adoption
Relationship mechanism: reuse
Semantic or technical owner: Interoperability with domain owners
Decision evidence: OPDA ODR-0037, amended 2026-08-28 and 2026-08-30; ODR-0043 / ODR-0044
Re-open trigger: A reviewed applicability case is not expressible within the selected per-side contract
External publication last checked: 2026-08-20

W3C Verifiable Credentials Data Model 2.0

Purpose: Portable credential presentation and verification semantics
Selected profile boundary: W3C Recommendation, 15 May 2025 (profile source)
OPDA governance status: Deferred candidate
External specification maturity: W3C Recommendation · 2025-05-15. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No VC term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Reference only; no wallet or trust-scheme conformance
Relationship mechanism: reference
Semantic or technical owner: DBT Smart Data group
Decision evidence: PDTF schema adoption catalogue
Re-open trigger: A real wallet or credential consumer enters scope
External publication last checked: 2026-08-20

W3C Organization Ontology

Purpose: Organisational structures and roles
Selected profile boundary: W3C Recommendation, 16 January 2014 (profile source)
OPDA governance status: Candidate by concern
External specification maturity: W3C Recommendation · 2014-01-16. Primary specification or method source.
Actual implementation status: not used
Implementation evidence: No ORG term occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Reference candidate; exact reused terms must be declared
Relationship mechanism: reference
Semantic or technical owner: Relevant domain owner
Decision evidence: PDTF schema evidence; ADR-0067
Re-open trigger: A participant or organisation competency question selects terms
External publication last checked: 2026-08-20

ISO 23386

Purpose: Data-dictionary definition and governance method
Selected profile boundary: ISO 23386:2020 (profile source)
OPDA governance status: Method candidate
External specification maturity: ISO International Standard · ISO 23386:2020. Primary specification or method source.
Actual implementation status: not used as an ontology dependency
Implementation evidence: Candidate glossary and dictionary governance method only
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Method reference; no ISO certification claim
Relationship mechanism: reference
Semantic or technical owner: Governance and glossary owners
Decision evidence: ADR-0063 methodology candidate
Re-open trigger: The glossary process adopts or rejects its governance pattern
External publication last checked: 2026-08-20

UFO

Purpose: Distinguish what something is from roles it plays and phases it passes through
Selected profile boundary: OPDA analytical profile for identity, roles, phases and introducing-class placement; no upper-ontology import (profile source)
OPDA governance status: Normative analytical method; not an imported ontology
External specification maturity: Design-time analytical framework · edition not selected. Primary specification or method source.
Actual implementation status: not used or imported
Implementation evidence: No Property Pack 0.1 import or analytical-method implementation is evidenced; normative method selection is separate
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Required analytical discipline, not foundational grounding by subsumption; no runtime dependency or Property Pack 0.1 method conformance claimed
Relationship mechanism: reference
Semantic or technical owner: Ontology facilitators with domain review
Decision evidence: OPDA ODR-0041, ODR-0042, ODR-0062 and ODR-0063; ADR-0074 non-inheritance rule
Re-open trigger: A reviewed example exposes a gap in the selected identity or placement distinctions
External publication last checked: 2026-08-20

gUFO

Purpose: Possible OWL implementation of selected UFO distinctions
Selected profile boundary: Version 1.0.0 is available; no term-level profile selected (profile source)
OPDA governance status: deferred — not adopted
External specification maturity: OWL implementation of UFO · 1.0.0. Primary specification or method source.
Actual implementation status: not used or imported
Implementation evidence: No gUFO term or import occurs in Property Pack 0.1
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Deferred; no import or term reuse
Relationship mechanism: reference
Semantic or technical owner: Ontology facilitators with Interoperability
Decision evidence: PDTF schema annotation precedent only
Re-open trigger: A selected UFO method requires reviewed reusable terms
External publication last checked: 2026-08-20

OntoClean

Purpose: Check whether class placement and subsumption preserve the intended identity commitments
Selected profile boundary: OPDA four-axis quality profile: rigidity, identity, dependence and unity (profile source)
OPDA governance status: Normative analytical quality method; implementation coverage is separate
External specification maturity: Design-quality method · publication edition not separately pinned. Primary specification or method source.
Actual implementation status: not used as a runtime dependency
Implementation evidence: No Property Pack 0.1 method-specific validation receipt is claimed; normative method selection is separate
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: Normative design-quality discipline with SHACL-oriented checks, not a foundational import or full DL requirement; no Property Pack 0.1 method-specific validation receipt claimed
Relationship mechanism: reference
Semantic or technical owner: Ontology facilitators with domain review
Decision evidence: OPDA ODR-0061 and ODR-0062, with ODR-0041 / ODR-0042 and ODR-0063
Re-open trigger: A reviewed placement rule requires an extension to the selected quality profile
External publication last checked: 2026-08-20

DOLCE

Purpose: Historical comparison for foundational distinctions
Selected profile boundary: No edition selected (profile source)
OPDA governance status: historical PDTF schema reference only
External specification maturity: Foundational ontology · edition not selected. Primary specification or method source.
Actual implementation status: not used or imported
Implementation evidence: PDTF schema comparison only; no SPDTF disposition
Property Pack 0.1 pin: No implementation snapshot pinned
Feature and conformance boundary: No SPDTF disposition, import or conformance claim
Relationship mechanism: reference
Semantic or technical owner: Ontology facilitators
Decision evidence: PDTF schema methodology evidence
Re-open trigger: A new competency question justifies a separately reviewed comparison
External publication last checked: 2026-08-20

Make the next proposal inspectable

Bring one question, one ordinary case and one counterexample. Name the resource being described, the intended meaning, the language job and the precise feature needed. Then point to the selected profile and state what implementation evidence exists or is still missing. This is more useful than adding a namespace without explaining its responsibility.

A practitioner can supply that argument without writing RDF. Use review a definition to frame it in ordinary language, or follow from question to candidate for the technical handoff. A standards record supports that review; it does not replace it.