PaperlayerView exact revision on arXiv

Source-linked AI summary

Rewrite Once, Validate Anywhere: Producing OWL-Aware SHACL Constraints (Extended Version)

Anouk Oudshoorn, Piotr Gorczyca, Dörthe Arndt

arXiv:2608.14104v1cs.LOcs.AI

TL;DR

SHACL validators vary in their support for OWL’s implicit knowledge, even though RDF graphs often use OWL ontologies. ShacOWL rewrites SHACL shapes using OWL EL− axioms, and the rewriting was successful in all evaluation cases.

  • Problem

    Because RDF graphs carry OWL implicit knowledge while SHACL validators need only support subclass reasoning, support for ontology-aware validation varies across systems.

    Source: §1 · p. 1

  • Method

    ShacOWL rewrites shapes using an OWL EL− ontology into SHACL constraints, allowing core validators to perform ontology-aware validation without built-in reasoning.

    Source: §1 · pp. 2–3

  • Results

    The rewriting approach was successful in all evaluation cases, while reasoning-plus-validation runs included materialization failures and timeouts.

    Source: §6 · p. 13

  • Takeaways & Limitations

    Rewritten validation results are independent of a validator’s reasoning support, making them suitable for sharing through the Web.

    Source: §1 · p. 2

    The evaluation is limited to non-recursive SHACL and acyclic TBoxes, although cyclic cases would require recursive constraints interpreted under least fixed-point semantics.

    Source: §3 · p. 6

Abstract

from arXiv · show

The Shapes Constraint Language (SHACL) is a W3C recommendation to express syntactic constraints, called shapes, on RDF graphs. SHACL validators are used to test whether a given graph adheres to such a shape. However, RDF graphs often come with OWL ontologies, whose implicit knowledge needs to be taken into account. This is classically handled by first applying reasoning and then performing the constraint checking on the results, often using different technologies which makes the process inefficient and vulnerable for mistakes. To overcome this, we propose to internalise the OWL axioms in the SHACL constraints; we construct a rewriting which takes as input both shapes and an OWL EL$^-$ ontology -- a fragment of OWL EL restricting the usage of existential restrictions -- and produces SHACL constraints. This output can then be evaluated by any validator supporting SHACL core regardless of its reasoning support, while yielding the same results as the traditional approach. The implementation of our translation is evaluated both against applying state-of-the-art reasoners and validators consecutively, as against validators with built-in reasoning support. For our benchmark, we show that our approach is in general more efficient in finding violations compared to the sequential approach, thus providing a powerful tool which simplifies combining reasoning with validation.

1 Introduction

The paper presents ShacOWL, a practical rewriting that incorporates OWL EL− axioms into SHACL shapes so ordinary SHACL validators can perform ontology-aware validation. It motivates this approach as a way to avoid separate reasoning and validation steps and develops a fragment and algorithm intended for implementation.

1 Introduction

  • Because SHACL requires only subclass reasoning, validators differ in their reasoning support, often leaving complex reasoning and validation to separate systems.This separation creates technical overhead, and some reasoning results are not relevant to validation.Source: §1 · pp. 1–2
  • Rewriting targets and constraints lets violations detectable by reasoning followed by validation be found through validation against rewritten shapes alone.For example, a subclass axiom can extend a shape’s target class, while a subproperty axiom can be represented with an alternative path.Source: §1 · p. 2
  • The approach does not focus on OWL RL, whose rules may be handled by engines with rule support or incorporated into shapes using an existing rewriting.The paper argues that planned SHACL rule support would let engines cope with RL using the corresponding rules [23, Section 4.3].Source: §1 · p. 3
  • Unlike prior theoretical SHACL rewritings for OWL QL and related logics, ShacOWL takes a step toward practice with an implementable algorithm and tool.The paper notes that some earlier algorithms are best-case exponential, while the ELHI rewriting is only worst-case exponential.Source: §1 · p. 3
  • ShacOWL rewrites shapes using OWL EL−, extending the considered axioms while restricting right-hand-side existential restrictions to avoid exponential blow-ups.The paper identifies the fragment, adapts rewriting techniques including a new approach to rewriting targets, and implements and evaluates the method.Source: §1 · p. 3

2 Preliminaries

The preliminaries define data graphs and their interpretations, then specify a non-recursive SHACL language and how shapes graphs are validated. Together, these definitions establish the graph and constraint semantics used in the paper.

Data Graphs

  • A data graph is a finite set of class or role assertions over countable, disjoint sets of concept names, role names, and individuals.Role names include inverses, and concept names include ⊤ and ⊥.Source: §2 · p. 4
  • The canonical interpretation of a data graph uses its occurring individuals and assertions, while the standard name assumption also enforces unique names.An interpretation maps concepts to domain subsets, roles to binary relations, and individuals to domain elements.Source: §2 · p. 4

(Non-recursive) SHACL

  • The non-recursive SHACL language, based on Corman et al., combines constants, shapes, classes, negation, conjunction, cardinality restrictions, and regular path expressions.It also includes path-set equality and inequality; universal restrictions and disjunction are defined as shorthands.Source: §2 · p. 4
  • A shapes graph pairs an acyclic constraint set with targets, and an interpretation validates it when every targeted node validates its assigned shape.A constraint set has at most one definition per shape name; the canonical interpretation is intended when validating a set of atoms.Source: §2 · pp. 4–5

3 Ontology Language OWL EL−

OWL EL− is the ontology language used in the paper’s rewriting: a fragment corresponding to EL++ that disallows existential restrictions on the right-hand side. Its syntax and restrictions define the ontology forms and assumptions considered.

3 Ontology Language OWL EL−

  • OWL EL− corresponds to EL++ [5,6] but disallows existential restrictions on the right-hand side.It is the fragment used for the ontology axioms in the rewriting.Source: §3 · p. 5
  • OWL EL− TBoxes contain axioms r ⊑ p or C ⊑ B, where r is p′ or p′ ◦ p for p′ ∈ NR; concepts use ⊤, A, c, ran(p), C ⊓ C, and ∃p.C.Source: §3 · p. 5
  • To ensure tractability, role-chain axioms are restricted to p ◦p ⊑p, which can still express transitivity.For counting to at least two on complex path expressions, the role must be simple: neither a role-chain inclusion nor a role inclusion into it may occur in the TBox.Source: §3 · pp. 5–6
  • OWL EL− semantics interprets concept inclusion C ⊑D as CI ⊆DI and defines conjunction, existential restrictions, role ranges, and role composition through interpretations.An interpretation satisfying every axiom in T is a model of T.Source: §3 · p. 6
  • The paper restricts its rewriting to acyclic TBoxes and non-recursive SHACL, although cyclic TBoxes and recursive SHACL do not invalidate the theory or rewriting’s correctness.Capturing cyclicity would require stratified recursive SHACL interpreted under least fixed point semantics; the paper avoids this to enable a more extensive evaluation.Source: §3 · p. 6

4 Combining SHACL and OWL

The section defines OWL-aware SHACL validation over a minimal canonical model and establishes a shape rewriting that preserves validation results on every data graph. The rewritten shapes can be computed once and reused for validation.

4 Combining SHACL and OWL

  • OWL-aware validation is defined by checking the shapes against AT, whose canonical interpretation is a model of (T, A) with no smaller model.Because existential restrictions on axiom right-hand sides are disallowed, the individuals affected by derived information are known.Source: §4 · pp. 6–7
  • Theorem 1 guarantees a rewritten shapes graph whose validation on any data graph is equivalent to validating the original shapes over the ontology-expanded graph.For every data graph A, AT validates (C, G) iff A validates (CT, GT).Source: §4 · p. 7
  • The rewritten shapes need to be computed only once, then can be reused to validate any data graph and any update to those graphs.Source: §4 · p. 7
  • The rewriting uses constraint rewriting to integrate axioms into constraints and target rewriting to include targets implied by T.In the example, the axioms derive B(a) and q(a, b), and the constraint is updated to s ← ∃(p ∪ q).⊤ so that a validates s.Source: §4 · p. 7

5 Rewriting Techniques

The rewriting encodes ontology-derived concepts and role paths in SHACL shapes, then uses those shapes to update targets and rewrite constraints. Its correctness is supported by equivalence results, and its size is independent of the data graph.

5 Rewriting Techniques

  • For each concept C, a node belongs to shape sC exactly when C is derivable for that node under T.The construction of shape(X, T) encodes the axioms so that sC captures the nodes satisfying C under the ontology.Source: §5 · p. 8
  • Bridge-shapes update targets by universally targeting nodes, filtering for those satisfying X, and requiring those nodes to validate s.Class, property, and individual declarations support universal targeting; property declarations can add sh:targetSubjectOf and sh:targetObjectOf targets.Source: §5 · p. 8
  • Role inclusions and chains are compiled into path expressions using role dependencies, with simultaneous substitutions avoiding termination issues.The example excludes a role from the repeated prefix when it is not transitive, preventing repeated steps along that role.Source: §5 · p. 9
  • Constraint rewriting substitutes each concept name B in the constraints with sB, which captures nodes for which B can be derived under T.For an axiom r ⊑ p, the lemma states that replacing p in a shape expression preserves its interpretation under T for every data graph.Source: §5 · p. 9
  • The rewriting is justified by combining the concept and role lemmas with the bridge-shape construction, and its size is data-independent with linearly many new shapes in the TBox size.Rewritten constraints can grow when roles are replaced by regular expressions; that growth depends on the amount of role hierarchies in the TBox.Source: §5 · p. 10

6 Implementation and Evaluation

The section presents ShacOWL, an implementation that rewrites OWL EL− knowledge into SHACL constraints, and evaluates it against reasoner-plus-validator pipelines and pySHACL inference. In the benchmarks, rewriting was fast and completed every case, while results also exposed a pySHACL depth limitation and differences in approach coverage.

Implementation

  • ShacOWL is a JavaScript tool using rdflib.js to rewrite an OWL EL− TBox and SHACL shapes into constraints that encode the ontology’s knowledge directly.The resulting constraints can be validated without a reasoner while providing the same validation results as the traditional approach.Source: §6 · p. 10

Results Analysis

  • Rewriting averaged 2.53s and took just over one hour total, versus Pellet’s almost 44 hours; with TopBraid, Isaitb, or Jena it solved all cases in under 25s.Reasoners used were OWL DL reasoners while ShacOWL supports OWL EL−, so the runtime comparison should be treated with care; rewriting is independent of the data graph and can be reused for each ontology-and-shapes combination.Source: Table 1 · p. 11, §6 · pp. 12–13

Related Systems

  • The evaluation compared reasoner materialisation followed by validation, ShacOWL rewriting followed by validation, and pySHACL’s OWL RL or OWL RL+RDFS inference modes across four validators.The baseline used Pellet, HermiT, or JFact with Jena, TopBraid, Isaitb, or pySHACL; rewriting was tested with each of the four validators.Source: §6 · pp. 11–12

Benchmarks and Experiments Setup

  • The team generated 1,500 benchmarks across 15 difficulty levels and restricted evaluation to acyclic TBoxes because current validators do not support recursive shapes.Each benchmark had a 1,200-second limit, split between reasoning or rewriting and validation; pySHACL inference received the full limit, and jobs used 64 GB of memory.Source: §6 · p. 12

Results Analysis

  • pySHACL reported significantly more validation errors because the tested version limited shape depth to 30, while rewriting can create deeply nested shape dependencies.The example rewriting creates a chain of four dependent shapes from one initially unconnected shape.Source: §6 · p. 13

7 Discussion: towards OWL EL

The discussion identifies two obstacles to extending the OWL EL− rewriting to full OWL EL: generating edges to existing nominals and handling existential edges whose objects are unspecified.

Existential restrictions to nominals

  • For C ⊑ ∃p.c, rewriting must simulate jumps to c when p occurs; universal roles are generally unavailable, while axiom-triple paths can encode those jumps.Such paths become more complicated when type C at a must itself be derived. Alternatively, validation can move to c while depending on conditions at a, using Boolean combinations of targets.Source: §7 · p. 14
  • SHACL 1.2 shape targets do not support Boolean combinations across shapes, so support for this natural approach remains unclear.The approach needs combinations such as s(a) ∨ (s′(a) ∧ s′′(c)).Source: §7 · p. 14

Existential restrictions

  • Prior rewriting work handles unrestricted existential restrictions without nominals, but can be ExpTime-complete even for OWL QL.The blow-up comes from considering every possible data configuration; restricting attention to settings that may occur in the data can help, but sacrifices data independence.Source: §7 · p. 15

8 Conclusion and Outlook

The paper moves ontology-aware shape rewriting toward practical use by implementing OWL EL− to SHACL rewriting and evaluating it against sequential reasoning and validation and a validator with built-in reasoning. The authors report that the approach solved all test cases and was faster in most cases, while noting report complexity and outlining future work.

8 Conclusion and Outlook

  • The rewriting-and-validation approach solved all test cases and was faster than alternatives in most cases; rewritten shapes can also be reused for matching ontologies and constraints to reduce later validation times.Source: §8 · p. 15
  • The work takes a first practical step in ontology-aware shape rewriting, identifying OWL EL− as a fragment expressive enough for non-trivial use cases yet incorporable into SHACL shapes with low effort.The authors detail the rewriting and provide an implementation reusable in other work.Source: §8 · p. 15
  • Automatically rewritten shapes can become complex, making validation reports harder to read but potentially helping users trace the cause of a violation.Source: §8 · p. 15
  • Future work aims to generate extracts from complex reports tailored to users’ needs.Source: §8 · p. 15
  • The authors plan to extend the techniques to more expressive OWL EL fragments, including inverse roles, which they expect can be added after careful inspection of the algorithms.Source: §8 · p. 15

Appendix

The appendix explains the Turtle encoding and benchmark-generation process, then reports benchmark statistics and additional timing and evaluation results. The generated benchmarks grow in triple counts with difficulty and are mostly non-conforming from level 2 onward.

Turtle Encoding

  • The Turtle examples connect the logic-based encoding to the input and output of the rewriting, including bridge-shape targets over named ontology individuals and entities.The encoding declares ontology individuals, roles, and classes; the example maps s2(∃r−.⊤) to :s2 sh:targetObjectsOf :r.Source: Appendix · p. 21, Figure 3 · p. 21, Figure 4 · p. 22

Benchmarks Generation

  • Three algorithms generate 1,500 instances across 15 difficulty levels, with increasingly complex paths as pathContinueProbability rises.GenerateTBox creates an OWL EL− TBox and name sets, GenerateDataGraph creates random assertions, and GenerateSHACL produces shapes and targets.Source: Appendix · pp. 21, 23, Table 2 · p. 24

Benchmarks Statistics

  • From level 2 onward virtually all generated instances are non-conforming, and mean triple counts for the input TBox, input shapes, and rewriting grow with difficulty.Level 1 has an even 50/50 conforming/non-conforming split; Table 3 reports per-level statistics across 1,500 instances.Source: Appendix · p. 23, Table 3 · p. 28

Extra Results

  • Additional results report timing distributions for completed instances and evaluation results on a shared subset that excludes JFact for the baseline and pySHACL for rewriting.Tables 4 and 6 give minimum, median, and maximum times; Table 5 reports evaluation results for the restricted set.Source: Appendix · p. 23, Table 4 · p. 29, Table 5 · p. 30
Loading 2608.14104v1…