Deontic Knowledge Graph Framework

• Deontic Knowledge Graphs are structured, semantically rich frameworks that encode permissions, prohibitions, and obligations using RDF, OWL, and SPARQL.
• They integrate dual knowledge graphs—one for factual data and one for policy rules—to enable automated compliance and conflict detection in domains such as disaster management and legal informatics.
• The reasoning engine employs formal decision semantics and SPARQL rules to enforce normative rules, ensuring traceable, audit-ready operations even in the presence of conflicting policies.

A deontic knowledge graph-based framework is a structured, semantically rich approach for representing, reasoning, and enforcing permissions, prohibitions, and obligations over knowledge artifacts. Leveraging the expressivity and inferential capabilities of RDF, OWL, and SPARQL, such frameworks operationalize deontic logic—modal logic concerned with normative concepts—at the knowledge representation level, enabling automated compliance and conflict detection across complex, realistic domains such as disaster data sharing and legal informatics (Echenim et al., 7 Jan 2026, Robaldo et al., 2024).

1. Architectural Principles and Components

Deontic knowledge graph frameworks are characterized by the modular integration of knowledge graphs for facts and for policies, semantic layering, and a formally specified reasoning pipeline.

Dual Knowledge Graphs:

• Disaster Management KG (DKG): An RDF dataset (e.g., TDB2-backed Fuseki) capturing multimodal artifacts (e.g., tables, imagery, geospatial features), provenance (PROV-O), and fine-grained privacy flags (e.g., dm:containsPII, iot-reg:isAnonymized, iot-reg:isEncrypted).
• Policy KG (PKG): An OWL/RDF graph, frequently rooted in the IoT-Reg ontology, encoding explicit permissions, prohibitions, and obligations, usually derived from regulatory documents and extended with custom policy-aligning namespaces (e.g., policy-ext).

Reasoning Engine:

An enforcement layer implements a deterministic release-decision function, typically: $\delta : (DKG, PKG, r) \rightarrow (v, T)$ where $r$ is a normatively relevant request, $v$ an access verdict (\textsc{Allow}, \textsc{Block}, \textsc{Allow-with-Transform}), and $T$ an ordered set of compulsory data transforms (e.g., anonymization, encryption) (Echenim et al., 7 Jan 2026).

Semantic Layering:

In frameworks like Robaldo & Pozzato (Robaldo et al., 2024), representation spans:

• Eventuality Layer: Encodes events, actions, modalities, and thematic roles.
• Statement Layer: Reifies actions as statements with Boolean and modal operators.
• Abnormality Layer: Explicitly marks contradictions, conflicts, violations, etc.

2. Deontic Vocabulary and Ontological Encoding

Deontic modalities are core to the framework’s representational power.

Standard Modalities:

• Permission: $P(p)$: action $p$ is permitted.
• Obligation: $O(p)$: action $p$ is obligatory.
• Prohibition: $F(p)$: action $p$ is forbidden.

Policy KG Representation:

Permissions, obligations, and prohibitions are individuals in the PKG, with contextual bindings:

• Recipients (audiences): iot-reg:hasRecipient
• Activities: iot-reg:hasActivity
• Data types: policy-ext:concernsData
• Obligations: iot-reg:hasObligation
• Obligation Transform & Verification: policy-ext:requiresTransform, policy-ext:checksFlag

Example PKG triple:

:Permit_PII_To_Partner a iot-reg:Permission; iot-reg:hasRecipient policy-ext:PartnerAgency; iot-reg:hasActivity iot-reg:DataSharing; policy-ext:concernsData iot-reg:PersonalData; iot-reg:hasObligation :Oblig_EncryptAndLog. :Oblig_EncryptAndLog a iot-reg:Obligation; policy-ext:requiresTransform "encrypt_file"; policy-ext:checksFlag "iot-reg:isEncrypted".

(Echenim et al., 7 Jan 2026)

Conflict-Tolerant Encoding:

The conflict-tolerant scheme (Robaldo et al., 2024) encodes:

• Deontic modality classes: :Obligatory, :Permitted, :Optional
• Statement reification for logical operators and negations
• Abnormality properties for explicit contradiction and conflict tracking

3. Formal Reasoning Semantics and Inference Rules

Robust reasoning in these frameworks is based on formal decision semantics and compositional rule application.

Release-Decision Function:

• Prohibition Dominance: If a matching prohibition $F(r)$ exists, block the request.
• Fail-Closed Default: If there is no matching permission $P(r)$, block the request.
• Obligation Consistency: For each matching obligation, check DKG flags; if unmet but the obligation specifies a transformation, collect transforms; otherwise, block.

Rule sketch ((Echenim et al., 7 Jan 2026), LaTeX):

• $$F(u, \alpha, \tau) \implies \delta = (Block, \varnothing)$$
• $$P(u, \alpha, \tau) \wedge \forall O_i~f_i(a)~holds \implies \delta = (Allow, \varnothing)$$
• $$P(u,\alpha,\tau) \wedge \exists O_i~(\neg f_i(a) \wedge requiresTransform(t_i)) \implies \delta = (Allow\text{-}with\text{-}Transform, \{t_i,...\})$$

Deontic Traditional Scheme Implementation (Robaldo et al., 2024):

• $PE(p) \leftrightarrow \neg OB(\neg p)$
• $$OP(p) \leftrightarrow (\neg OB(p) \wedge \neg OB(\neg p))$$
• $OB(p) \rightarrow PE(p)$
• SPARQL rules implement these equivalences at the statement reification level.

Conflict/Contradiction Detection:

• Conflict: If two deontic statements are both asserted, one is more specific, and they are oppositely permitted, a conflict is declared.
• Contradiction: If the same action is both asserted and negated under the same modality, a contradiction is flagged.

4. Policy Encoding and Population Methodologies

Policy KGs are systematically populated from regulatory and policy sources:

Population Pipeline (Echenim et al., 7 Jan 2026):

1. Ontology Alignment: Map domain and regulatory concepts to ontology classes (e.g., FEMA/DHS → IoT-Reg).
2. Rule Extraction: For each relevant policy clause, generate an individual of type iot-reg:Permission/Obligation/Prohibition.
3. Binding: Attach transformation requirements and flag-checks to enable operational enforcement.

• Example sources: NISTIR 8228 (IoT privacy), FEMA SORN, FEMA UAS PIA-055.
• Result: A compact PKG (e.g., 15 deontic individuals capturing coverage of core policies).

Abnormality Tracking (Robaldo et al., 2024):

• Conflict, violation, and contradiction relationships are expressed explicitly in the KG via abnormality properties, supporting meta-reasoning and legal auditability.

5. Operational Workflow and Exemplification

Release decisions and compliance are enforced through a SPARQL-driven, provenance-attached workflow.

Operational Steps (Echenim et al., 7 Jan 2026):

1. Prohibition Check: Query PKG for matching prohibitions.
2. Permission and Obligation Check: Retrieve permissions and associated obligations/flags.
3. Flag Resolution: If required flags are missing but transforms are specified, assemble a transformation set.
4. Transformation Pipeline: Apply each transform, instantiate a derived artifact in the DKG (linking with prov:wasDerivedFrom and new privacy flags), and rerun the decision procedure on the derivative.
5. Audit Logging: All Block verdicts involving personal data are logged as semantic privacy incidents.

Detailed Example:

• Share request for dm:Image_1234 with the public:
  1. Prohibition: None found.
  2. Permission: :Permit_Image_To_Public found.
  3. Obligation: Requires iot-reg:isAnonymized; transform is strip_exif.
  4. Since the flag is not present, transform is applied, artifact is updated and rechecked.
  5. Upon satisfaction, access is allowed.

Conflict Example (Robaldo et al., 2024):

• If one rule obligates an agent to an action (e.g., to pay by cash), and another generically prohibits that action under the same context, the framework asserts a conflict, reified via :is-in-conflict-with property.

6. Performance, Scalability, and Practical Applicability

Empirical Results (Echenim et al., 7 Jan 2026):

• Dataset: DKG of 5.1M triples, including 316K images.
• Policy KG: 15 deontic individuals representing extracted policy rules.
• Verdict correctness: 24/24 (1.0) on a gold-set spanning all data, audience, and compliance combinations.
• Latency: Mean 0.10s, median 0.06s, 95th percentile 0.18s per release decision.
• Query performance:
  • Single-KG templates: 100% success, mean 0.05s.
  • Federated DKG+PKG queries: 100% success, mean 7.0s.
• No referential integrity violations; semantic consistency assured.

Technical Features (Robaldo et al., 2024):

• Full implementation in W3C standards (RDF, SPARQL); leverages Apache Jena for reasoning.
• Explicit normalization of conflicts, supporting consistent meta-reasoning in presence of irresolvable deontic contradictions.
• Example Java reasoner and complete ontology available for reproducibility.

7. Strengths, Limitations, and Extensions

Strengths:

• First-order expressivity with RDF reification enables granular, contextualized representation and compliance reasoning.
• Explicit semantic tracking of abnormalities distinguishes between genuine contradictions and permissible conflicts.
• Operationalizes legal logic (deontic modalities) directly at the knowledge graph level, facilitating automatable compliance, provenance, and audit.

Limitations:

• No native support for generalized quantification or advanced temporal reasoning; enumeration is required for sets and deadlines.
• Verbose reification and complex SPARQL patterns may impact scalability and maintainability for very large ontologies.
• Higher-order and non-material implication logics are not yet fully integrated.

Planned Extensions (Robaldo et al., 2024):

1. Representation of sets and quantifiers for meta-normative reasoning.
2. Integration of the W3C Time Ontology and Allen interval calculus for temporal constraints.
3. Adoption of non-material implication logics (e.g., relevance logic) to avoid paradoxical inferences.
4. Migration to Datalog backends for big data scalability and addition of priorities for defeasible reasoning.

This suggests the deontic knowledge graph-based framework is a foundational technology for scalable, transparent, and context-aware normative systems—critical in domains like disaster response, privacy compliance, and legal informatics—while ongoing enhancements will expand their expressivity and operational reach (Echenim et al., 7 Jan 2026, Robaldo et al., 2024).