· 5 min read
An Ontology of Obligations for Standards Compliance
An Ontology for compliance obligations identified in regulatory documents
All regulatory documents like ISO standards, FDA guidance, NIST frameworks, or IEC specifications are all written in natural language. They contain obligations: things that systems, organizations, and actors shall, should, or may do. Identifying, referencing, modeling and representing the obligations contained in regulatory text is the problem addressed by this ontology.
The Obligation Extraction Ontology v0.1 is a small, focused vocabulary built on three W3C standards: ODRL (Open Digital Rights Language) for expressing duties and permissions, SKOS for organizing requirement concepts, and PROV-O for tracing the provenance of compliance artifacts. Together they form a graph that connects a regulatory document through to evidence of compliance.
Classes
| Class | RDF Term | Role | Key Properties |
|---|---|---|---|
| Standard | dct:Standard | Top-level anchor. A regulatory document, specification, or guidance publication — ISO 21434, IEC 62443-4-2, FDA Premarket Cybersecurity Guidance, NIST SP 800-53. Every clause, obligation, and control traces back here. | dct:title, dct:identifier |
| Clause | dct:clause | A numbered section within a standard. One clause may contain multiple obligations; one obligation may appear in multiple clauses across different standards. | dct:source, position |
| Obligation | odrl:Duty | The core unit. A normative requirement expressed in deontic terms: shall (mandatory), should (recommended), or may (permitted). Deontic strength is explicitly modeled rather than left implicit in prose. | deontic strength, target actor |
| Requirement | skos:Concept | The technical or operational interpretation of an obligation. Where an obligation is the normative statement, the requirement is the functional decomposition. Requirements bridge regulatory language and engineering specifications. | skos:broader, skos:related |
| Control | oblig:Control | The countermeasure, safeguard, or process that satisfies a requirement. Concrete examples: cryptographic protocols, access control policies, audit logging configurations. A control may satisfy multiple requirements. | satisfies Requirement |
| Implementation | oblig:Impl | The specific instantiation of a control in a system. Where a control is abstract ("implement TLS"), an implementation is concrete ("TLS 1.3 on Gateway API, configured in Caddyfile"). Versioned and system-specific. | version, system, config ref |
| Artifact | prov:Entity | Evidence. A document, test result, configuration file, scan report, or audit log that demonstrates an implementation exists and functions correctly. wasGeneratedBy links it to the producing process. | prov:wasGeneratedBy, timestamp |
| Compliance Assertion | oblig:Assertion | The formal claim that a control satisfies a requirement, backed by one or more artifacts. The closure of the graph: Standard → Clause → Obligation → Requirement → Control → Implementation → Artifact → Assertion. | cites Artifact, asserts Requirement |
The logical flow from standard to assertion matches the flow of a compliance audit
- An auditor selects a standard and identifies clauses in scope.
- Obligations are extracted from those clauses.
- Requirements are derived from obligations.
- Controls are selected to address requirements.
- Implementations of those controls are documented.
- Artifacts are produced as evidence of implementation.
- Assertions are made that the evidence satisfies the requirement.
By representing each step as a typed node in a graph, the chain is machine-traversable. SPARQL queries can identify which requirements lack controls, which controls lack implementations, which implementations have no artifacts, and which assertions are unsupported by current evidence.
Vocabulary Choices
ODRL was chosen for Obligation rather than a custom class because deontic modality — shall, should, may — is already modeled in ODRL’s permission/duty/prohibition framework. Reusing it avoids reinventing a wheel that has been standardized.
SKOS was chosen for Requirement because requirements form taxonomies and thesauri. ISO 21434 and IEC 62443 share overlapping requirement concepts. SKOS broader, narrower, and related relations let those mappings be expressed without conflating the source standards.
PROV-O was chosen for Artifact because provenance is the heart of compliance evidence. It is not enough to say “we have a test report.” The report must be traceable: who ran the test, on which system version, with which tool, at what time, producing what output. PROV-O provides that vocabulary without custom extension.
Known Limitations:
- Actor modeling is absent. Obligations are directed at actors (the developer, the integrator, the operator) but Actor is not yet a class in this ontology.
- Deontic strength propagation is not formalized. If a shall at the standard level becomes a should at the requirement level, that weakening is not constrained by the current model.
- Cross-standard mapping relies on SKOS but no alignment rules have been written.
- Temporal validity of assertions is not modeled. A compliance assertion based on a 2023 test report may not be valid against a 2026 system.
References
W3C Standards
- ODRL Information Model 2.2 — Open Digital Rights Language; source of
odrl:Dutyand deontic permission/prohibition framework - SKOS Simple Knowledge Organization System — source of
skos:Concept,skos:broader,skos:narrower,skos:related - PROV-O: The PROV Ontology — source of
prov:Entityandprov:wasGeneratedBy - DCMI Metadata Terms — source of
dct:title,dct:identifier,dct:source
Regulatory Standards
- ISO/SAE 21434:2021 — Road vehicles: Cybersecurity engineering
- IEC 62443-4-2 — Security for industrial automation and control systems: Technical security requirements for IACS components
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
- FDA Cybersecurity Premarket Guidance — Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
Deterministic Obligation Ontology v0.1 — February 2026 — 4 min read
