Meaning, checks and delivery: four jobs, four contracts

Published RDF keeps its semantics

Suppose inspectionOf has an RDFS domain of Inspection. Using that property supports the conclusion that its subject is an Inspection. It does not reject a subject merely because a type statement is missing. Likewise, an RDFS range states something about values used with the property; it is not a field validator.

Two RDFS domains are not alternatives. If a property has domain Inspection and domain ReportVersion, standard RDFS semantics imply both types for its subjects. Choosing not to materialise that inference in today’s store does not make the exported vocabulary mean “either one”. RDFS 1.1 §§3.1–3.2 defines this conjunctive behaviour.

The selected method therefore allows at most one universally true RDFS IRI on each property side. Alternative intended classes or datatypes use Schema.org inclusion hints. These hints still need clear definitions and documentation; they are neither OWL entailments nor SHACL requirements.

Document both property sides, once per side

Every governed property must explain both its intended subjects and its intended values. On each side select exactly one mechanism family: one safe RDFS assertion; one or more schema:domainIncludes or schema:rangeIncludes values; or an explicit governed waiver. The subject and value sides may use different families.

The families are exclusive on a given side. Do not combine RDFS with inclusion hints there, or add a waiver alongside either. A prose definition, a SHACL path, a targeting rule and disabled inference are not substitutes for this documentation contract.

A waiver is exceptional, not a quick way to make coverage green. An accepted decision must identify the property and side, explain why no truthful useful commitment or hint can be given, and state a review trigger. The waiver has a non-blank English, decision-qualified rationale. A vacuous universal type does not become informative merely because it has an IRI.

A shape checks an explicitly chosen graph

The fictional Harbour Court receiving profile asks each report version to identify exactly one inspection. That is an exchange requirement, not a new definition of Building. A graph missing the link should produce a validation result; it does not establish that no inspection happened.

SHACL targets identify the focus nodes to check. Property paths identify the values. Constraints describe cardinality, datatype, class, permitted values or more complex conditions. A useful result tells the reader the focus node, path, offending value where relevant, and source constraint. SHACL 1.2 Core §§6.5–6.7 specifies validation and its report; its current W3C publication is a Working Draft, distinct from OPDA's selection of the 1.2 standards family.

The validation contract must also identify the input graph, shape version and relevant entailment regime. Are expected types asserted, or made available by a declared processing step? Different answers can change the result. A successful validation means the supplied graph meets the encoded conditions; it proves neither the factual truth of a roof claim nor approval of the whole ontology.

Author a rule that a domain reviewer can challenge

The rule is “each report version identifies exactly one inspection”. Before reviewing syntax, pin the fictional ReportExchangeShape version as teaching-1, the input graph below and its assumptions: report and inspection types are explicitly asserted; no external type lookup, materialisation or advanced target is assumed. The example exercises an ordinary Turtle/SHACL Core subset, not full SHACL 1.2 or the complete ontology-authoring profile.

@prefix ex: <https://example.org/harbour-court/> .
@prefix model: <https://example.org/property-model/> .

ex:inspection a model:Inspection .
ex:report-v2 a model:ReportVersion ;
    model:reportsInspection ex:inspection .

# Adverse case: a typed report missing the required link.
ex:report-missing a model:ReportVersion .

ex:report-v2 has one correctly typed inspection and should yield no result from these constraints. ex:report-missing is selected by the same class target but has zero values on the required path. The expected result is a structural Violation, not a conclusion that the real inspection never occurred. The input vocabulary and shape declarations still need their full documentation and ownership before a package can claim method conformance.

An empty result can mean that the defective node was never selected

Replace sh:targetClass model:ReportVersion with sh:targetSubjectsOf model:reportsInspection. The latter selects only subjects that already have the link. It selects the good report and misses ex:report-missing—the exact absence this rule was intended to detect. On a graph containing only the missing-link report it selects no focus nodes at all.

More constraints can make the rule impossible

Suppose one reviewer asks for at least two inspection links and another keeps the single-inspection maximum. Combining sh:minCount 2 and sh:maxCount 1 on the same path is a contradiction. SHACL requirements are conjunctive: no count can satisfy both. Zero or one link fails the minimum; two or more fail the maximum. This is not “more thorough validation”.

Resolve the intended domain rule with its owner. If one report may describe multiple inspections, review that meaning and the changed profile; if the single-inspection contract is intended, restore the minimum of one. Never delete whichever constraint happens to prevent a green result without recording the reason.

Shape meta-validation alone does not prove arbitrary shapes satisfiable. Alongside declaration checks, use ordinary and adverse data, review target coverage and perform a scoped contradiction check. Comparing the numeric bounds detects this particular contradiction; it does not decide satisfiability for every possible shape or advanced feature.

Put severity where the finding originates

ODR-0050 distinguishes structural Violation, governance/documentation Warning and suggested improvement Info. This additional teaching rule asks for a creator as a documentation-review signal. Its sh:Warning is on the property shape owning sh:minCount; it is not assumed to flow down from the containing NodeShape.

@prefix model: <https://example.org/property-model/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix dct: <http://purl.org/dc/terms/> .

model:ReviewMetadataShape a sh:NodeShape ;
    sh:targetClass model:ReportVersion ;
    sh:property model:CreatorReviewProperty .
model:CreatorReviewProperty a sh:PropertyShape ;
    sh:path dct:creator ;
    sh:minCount 1 ;
    sh:severity sh:Warning .

With no dct:creator, the reports above receive a Warning from this additional shape even when their inspection links are correct. Display the warning and review it. Do not silently relabel it a Violation or assume a processor's overall conformance flag defines the publication gate. Advisory-to-blocking escalation needs an explicit rule; authored and generated content retain the same severity semantics. Category 5's exact metadata requirements are explained in the administrative profile.

Check the shapes as authored model resources

The adopted method supports inline property constraints on the selected dual-typed ShapeClass/OWL resource pattern, as well as independent NodeShapes for cross-cutting or external targets. The example here deliberately uses a separate NodeShape. It does not claim to demonstrate ShapeClass support, advanced targets or the complete authoring method. An authoring package using those features must name them and supply processor evidence separately.

ODR-0042 favours flat per-class validation and modest, justified sh:node composition. Arbitrary class inheritance does not copy constraint declarations or establish a shape-inheritance system. An explicit class target may select subclass instances according to SHACL's target semantics; that is a targeting behaviour, not automatic propagation of authored shapes.

Review typed sh:NodeShape, sh:PropertyShape and sh:ConstraintComponent declarations for coherence, documentation and ontology ownership; check generated declarations as well as hand-authored ones. Select declarations in a way that catches missing ownership, not only resources already linked to an owner. Do not claim concern-specific provenance, temporal or sensitivity shapes that their governing records still defer.

DASH editor/viewer hints, ordering and grouping belong to presentation. A required-looking widget is not a constraint. A deliberately selected DASH constraint component needs its own feature justification; a display annotation cannot quietly activate it. Editor settings and processor setup are informative tooling details, not new requirements on every consumer of the ontology.

Use the bounded OWL profile without calling it a new semantics

ODR-0043 defines the permitted documentation constructs and exclusions. ODR-0044 separately selects runtime materialisation. The selected group covers subclass and subproperty propagation, inverse, transitive and symmetric relationships, and disjointness checks. “Safe Group” is the OPDA method’s profile name, not a guarantee that every use of those constructs is safe.

The runtime group excludes domain/range materialisation, functional and inverse-functional identity effects, and class/property equivalence propagation. Those operational omissions do not suspend standard semantics. In particular, paired subclass links across contexts recreate bidirectional type propagation; they are not a safe workaround for an excluded equivalence rule.

The bounded documentation profile excludes OWL restrictions, Boolean class constructors, cardinality restrictions, owl:oneOf, owl:hasKey and owl:disjointUnionOf. Put required cardinalities and conditional checks in SHACL; use governed SKOS choices and explicit validation for closed lists. This is a selected profile, not a claim that these OWL constructs are invalid in OWL generally.

Enrichment produces data; validation judges supplied data

ODR-0044 adopts simple triple-template rules and SPARQL CONSTRUCT rules for derived values, in separate rules artefacts. For Harbour Court, a rule might generate a display heading from a supplied address label and inspection date. The heading is derived from those inputs. It is not an independent observation of the building and cannot supply missing professional judgement.

Keep asserted and derived triples distinguishable through declared graph or provenance conventions. Identify which rules ran and which input version they used. Turning a rule off should be an inspectable configuration decision, not a change hidden inside a validator. A generated default must not be presented as a value observed or supplied by a practitioner.

Rules and constraints can use related machinery without sharing the same job. SHACL Advanced Features §8 describes rules; the OPDA method’s adoption of those capabilities does not demonstrate that current OPDA candidates execute them.

Generated outputs preserve the ontology's distinctions

JSON-LD artefacts are generated from the ontology. They must preserve the meaning and declared requirements they represent; generation does not create a second semantic authority. The subject here is the ontology's model and constraints, not payload or pipeline design.

Source contract

Required method: OPDA ODR-0037 R1–R6 as amended 28 and 30 August 2026; ODR-0043 Core Principle and permitted/excluded tables; ODR-0044 Normative Rules, including its later cross-context equivalence correction. ODR-0050 supplies the validation concern. These adopted OPDA records govern the method, not candidate implementation.

Adoption provenance: upstream revision 67174057e6384b79d0b28b7736fe70a66e112895, 5 September 2026. See standards and decisions. These are required method distinctions with fictional examples, not evidence that a current runtime or candidate already implements them.