Introduction

The Shapes Constraint Language¹ (SHACL) is the W3C specification for describing and validating constraints over RDF graphs. The constraints defined using SHACL, called ‘shapes’, are themselves expressed using RDF with the set of constraints being termed as ‘shape graph’ and the RDF data being validated called the ‘data graph’. Shapes offer a description of the data graph in the form of constraints that a valid data graph should satisfy. This is based on the closed-world assumption where the information is required to be present and satisfying the conditions of the constraint, with any other alternative including absence considered to be invalid. SHACL is thus useful as a testing mechanism to determine the suitability or the quality of the data based on a given set of constraints. In addition to this, SHACL has applications for other purposes such as code generation and data integration where presence and correctness of information is required.

Creation of shapes using SHACL is invariably tied to the schema or ontology used within the data graph, where the shapes utilise the concepts and relationships to define constraints. These schemas and ontologies (usually) contain axioms in their definition of concepts and relationships, and which can also serve the purpose of specifying constraints over them. A simple example of this are rdfs:domain and rdfs:range which specify the category of concepts acceptable for a property’s domain and range respectively. While a reasoner uses these to infer the type of entity, a validation constraint can use these to ensure a valid type is being used. More complex examples include OWL assertions regarding subclasses or equivalence using constraints over properties. Thus, the axioms defined in an ontology can also be used to validate data - and their use could help in avoiding duplicity of constraints between ontologies and SHACL.

Where the data being validated uses a single ontology, the axioms in that ontology can be utilised to validate the data. However, in cases where the data uses multiple schemas or ontologies - the axioms defined in one or all ontologies no longer reflect the ‘shape’ of the data, and therefore cannot be used in validations readily. Additionally, the data graph may selectively use concepts and properties from different ontologies in a ‘mix-and-match’ approach which further reduces the possibility of reusing axioms to derive constraints since they may depend on concepts not present in the graph.

By contrast, an Ontology Design Pattern (ODP) is defined as a collection of concepts and relationships necessary to define a particular context. Such ODPs can combine or be extended with concepts and relationships from multiple ontologies to express new relationships between them. An ODP can also be made significantly more abstract and generalised - which makes it suitable for reuse across ontologies and data graphs. Additionally, given that an ODP is by design smaller and more modular than a comparatively larger ontology, the axioms defined within it are more suitable for validation given the likelihood of more instances adhering to it. Therefore, ODPs and its axioms can be readily adapted to constraints in SHACL shapes for validation. An added advantage of ODPs is that they are easier to maintain and evolve with the use-case and its data as compared to ontologies.

The argument for using ontology design patterns to define SHACL shapes was originally put forth in a position paper [1]. It discussed similarity between the axioms used to model ODPs and the constraints within SHACL shapes, and how this could be used in generation of SHACL shapes for validation of instances. The aim and motivation behind this was to investigate the automation of SHACL shape generation from modular patterns for a given data graph, and to encourage the reuse of ODPs outside of modelling ontologies for validating RDF graphs. In this article, we expand on our argument with recent developments in the field of automated validation of data, extraction of constraints from data, and the conversion between OWL2 and SHACL. The rest of the article contains: use of ODP axioms to generate SHACL shapes in [sec:pandit_shacl_constraints], an example of ODP to SHACL discussed in [sec:pandit_shacl_example], recent advances in the state of the art in [sec:pandit_shacl_sota], and finally the conclusion in [sec:pandit_shacl_conclusion] .

ODP axioms and SHACL shapes

An axiom is defined within description logic as a logical statement relating roles and/or concepts [2]. Axioms in an ontology define constraints over concepts and relationships that must be satisfied by the instances that use the ontology. These axioms cannot be reused as part of an ODP as this can cause issues with missing entities (dependencies) which are not part of the ODP. Instead, the ODP defines its own set of axioms that are limited to only those concepts and relationships that are a part of it. This enables the ODP to be an independent and modular component.

In general terms, an ODP is essentially equivalent to a shape in SHACL given that they are both abstract when compared to the rest of the data, localised to the concepts in question, modular given that they can be combined, and context-dependant on the ontology or data. While SHACL permits nesting and cross-linking of constraints, we can consider them as specifying composition and inclusion of related constraints similar to building an ODP with axioms. Existing work comparing OWL axioms and SHACL [3] finds the expressibility of OWL being comparable to the SHACL Core vocabulary, and that syntactic translation between OWL and SHACL is straight-forward in most cases. Automating this process involves two steps - first to identify the relevant OWL statements forming a single constraint, and second to then generate their equivalent SHACL shape constraints. Since both OWL and SHACL are essentially defined using RDF triples, both steps can be performed programmatically using the table of associated concepts mapping OWL and SHACL constraints [3].

Example

The MicroBlog ODP [4] is based on real-world use-cases for modelling data related to tweets (Twitter posts). Data instances based on the ODP will therefore have validation requirements that ensure its correctness based on the specific axioms used in the definition of the ODP. It’s core class, MicroblogEntry, defines three axioms describing constraints and relationships within the ODP, which are:

1. MicroblogEntry ⊑ ∀  = 1hasPayload.Payload

2. MicroblogEntry ⊑ ∀  = 1hasAuthor.Author

3. MicroblogEntry ⊑ ∀≤ 1writtenAt.Location

These define that MicroblogEntry has exactly one payload (text of the tweet), exactly one author, and may have zero or one location(s). Any instance of the MicroblogEntry class that fails these constraints can be said to be invalid for the purposes of its intended context. The axioms are defined² using rdfs:subClassOf and owl:Restriction as:

:MicroblogEntry rdf:type owl:Class ;
    rdfs:subClassOf :ReportingEvent ,
        [ rdf:type owl:Restriction ;
          owl:onProperty :hasPayload ;
          owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
          owl:onClass :Payload
        ] ,
        [ rdf:type owl:Restriction ;
          owl:onProperty :hasAuthor ;
          owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
          owl:onClass :Author
        ] ,
        [ rdf:type owl:Restriction ;
          owl:onProperty :writtenAt ;
          owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
          owl:onClass :Location
        ] .

Reusing the axioms in the ODP to directly generate the corresponding constraints in a SHACL shape using sh:class and sh:qualified(Max/Min)Count conditions gives the following SHACL shape:

:MicroblogEntryShape
    a sh:NodeShape ;
    sh:targetClass :MicroblogEntry ;
    
    sh:property [
        sh:path :hasPayload ;
        sh:class :Payload ;
        sh:MinCount 1;
        sh:MaxCount 1;
    ] ,
    sh:property [
        sh:path :hasAuthor ;
        sh:class :Author ;
        sh:MinCount 1;
        sh:MaxCount 1;
    ] .
    sh:property [
        sh:path :hasAuthor ;
        sh:class :Author ;
        sh:MinCount 0;
        sh:MaxCount 1;
    ] .

The SHACL shape defines constraints for two of the axioms with given cardinalities. The third axiom defines an optional triple which provides an optional constraint with only the maximum cardinality. This is represented with an implicit cardinality of minimum count being zero to specify none or at most one location entities should be allowed.

Application of this in practice involves translating the ODP to the ontology or schema used in the data, such as an ontology for Twitter, and converting the SHACL constraints to use the corresponding concepts. This can be done automatically with a mapping table between the ODP and the Twitter ontology concepts, which is then used to rewrite the SHACL rules using the schema used in the data graph. In case the Twitter ontology directly utilises the ODP - the SHACL constraint can be used as is.

The actual advantage of this is apparent when the data graph contains multiple types of schemas - such as for Twitter, Facebook, Emails. In this case, a single ODP can be applied to represent a ‘blog’ or ‘email’ from all three, with additional ODPs specifically developed or extracted from an ontology. Where features differ between the ontologies, specific ODPs can be developed without changing the other ODPs used in the data description and shape generation process. Thus, ODPs are a tool for abstraction of the data and their use in constraint validation is akin to the concept of ‘unit testing’ in software engineering. Another example is utilising provenance ODPs to ensure all incoming data in a heterogeneous graph has information about its source and derivations.

Recent advances in State of the Art

The topic of detecting the schemas used in a data graph is not new - it has been researched in connection with graph summaries, data ingestion and workflows, and reuse of schema-less datasets. In comparison, SHACL and its relation with OWL2 for schema-detection and data validation are new topics and have seen sparse research. Here we summarise recent advances in this field within the last few years.

Savković et al. [5] describe an approach for creating SHACL constraints given a data graph containing an OWL2 QL ontology and an existing set of SHACL constraints. Their approach uses constraint rewriting to transform a subset of SHACL constraints such that it can validate both the ontology as well as the data in the graph. The article also highlights the complexities in such operation, its feasibility, and the necessity of restricting SHACL constraints to not contain negative or cardinality restrictions. While the approach does not directly derive SHACL constraints from the ontology or data - it presents an argument for the expensiveness of such as approach over a large-scale graph.

Recent approaches have also explored the extraction of schema and constraints from a given data graph with promising results. ABSTAT [6] extracts ontology patterns from data along with metrics about its use, and creates a semantic profile that describes characteristics about the data. The semantic profiles are then transformed into SHACL for the validation of constraints through automated generation of constraints. Boneva et al. [7] similarly also extract patterns from data and use it in the construction of SHACL constraints. Their approach detects schemas used in an existing RDF dataset and creates constraints using either SHACL or ShEx to validate the data graph. The tool described in the article provides for an interactive workflow where the extracted schema can be manually edited - with visual feedback on the application of constraints based on the schema and its results over data. Astrea [8] is a tool that generates SHACL shapes from ontologies using a set of mappings (called Astrea-KG) that allow the generation of SHACL shapes from one or more ontologies. The use of mappings allows Astrea to work with a variety of ontologies with positive results. The cited article also provides a good overview of related approaches.

In addition to these, there have been notable development for the support of SHACL and ODPs in the ontology development and data validation fields. SHACL4P [9] is a Protégé plugin for defining and validating Shapes Constraint Language (SHACL). The possibility of creating SHACL constraints in the same environment as ontology engineering provides a good opportunity to interleave the advantages of both. Similarly, Comprehensive Modular Ontology IDE (CoModIDE) [10] is a tool for developing modular ontology patterns using graphical and visual paradigms. Evaluators of the tool found it simpler and easier to use as compared to Protégé in the tasks related to ontology pattern use and development.

Conclusion

Through this article, we presented our arguments towards the use of ontology design patterns (ODPs) to generate SHACL shapes. The approach involves use of axioms defined within ODPs to generate equivalent SHACL shape constraints for data validation over a RDF dataset using those ODPs. The article provides an example of this where the RDF triples representing the ODP axioms within an OWL file are used to generate their corresponding SHACL shape. The state of the art, presented in [sec:pandit_shacl_sota], shows progress on schema detection and extraction, and its use in automating SHACL shape generation process.

While ontologies are a good way to document the schema of a data graph, documentation and schema extraction is complex when using multiple ontologies or in a heterogeneous graph. By using ODPs, which are modular and specific to features or context, documentation can be created in parts and specific to use-cases. However, creation of ODPs is difficult where the structure of data is not known. Approaches that extract SHACL shapes from data can be utilised to transform these shapes into ODPs which can then be combined into larger ontologies over time. In this manner, ODPs along with SHACL are also useful to act as documentation for description of data in a graph. Where the state of the art provides solutions for realising this, the community needs to further advocate ODPs in their role of describing data and possibility of automating validation processes.

We particularly emphasise the use of ODPs rather than ontologies as the basis of validation because RDF graphs can contain multiple ontologies where the axioms from those ontologies may not be sufficient or applicable for verification of the data graph. Data engineers can utilise ODPs in their task based on scenarios and use-cases, which knowledge engineers can build up sufficient ontologies over time. Existing approaches that automate the extraction of schema and generation of SHACL shapes show the viability of this.

This approach also encourages the reuse of ODPs beyond the data modelling phase. Relating ODPs with their corresponding SHACL shapes provides a way to visualise the model of the data as well as to validate it using the same context. The ODPs defined in this manner are modelled more closer to the instances used in actual RDF graphs, and can therefore be used in approaches such as data summarising, visualisation, and exploration. Conversely, ODPs can assist approaches relevant to validation such as visualising SHACL shapes. This can be done by taking SHACL shapes and generating corresponding ODPs to represent their context.

In terms of future work, the approach discussed in this article should be applied to the larger set of vocabularies and datasets presented in the linked data cloud. This would provide a way to detect and collect ODPs used in the data and compare their relevance to the existing vocabularies. Further to this, the automated creation of SHACL constraints from ODPs (and ontologies) has benefits to evolving datasets such as DBpedia and WikiData. Where existing approaches only consider the SHACL core vocabulary in shape generation, there is a need for further investigation in mapping the features provided by SHACL advanced and SHACL-SPARQL to the OWL2 profiles. The ability to convert OWL axioms to SPARQL queries using approaches such as OWL2SPARQL³ allow the generation of SHACL shapes from ODPs by using the SHACL-SPARQL features which need to be harmonised with their use in validating data graphs. Similarly, anti-patterns in both OWL and SHACL that increase complexity for validation also need to be investigated.

We started our argument based on the intended application to automate generation of SHACL shapes from existing patterns/models describing the data. The aim of this was to validate a data graph based on specific contexts (represented through ODPs), and reusing the same validation mechanisms to check for existence and correctness of required data in the graph. The reporting feature of SHACL would then be used to produce a documentation based on the outcome of the validation to describe the quality of data. With the recent development of graphical tools for supporting ontological engineering, we also believe that this approach has value in an educational setting by permitting rapid development of ODPs and assessing their effect on data through querying and validation of constraints similar to existing practices in the software engineering and data-science domains.

Acknowledgements

This work is supported by the ADAPT Centre for Digital Content Technology which is funded under the SFI Research Centres Programme (Grant 13/RC/2106) and is co-funded under the European Regional Development Fund.
We also wish to thank Heiko Paulheim and Sebastian Rudolf for their discussion and guidance in the comparison of axioms and SHACL constraints.

References