Modeling Instructions for SHACL Shapes

Introduction

As input specification for Metamorph we use SHACL. However, different schemas have different expressivity (constructs to model information), so not all constructs SHACL offers can be meaningfully translated into other schema formats. To this end, we use a specific subset of SHACL. On this page we'll explain how to model certain common phenomena, and how to express those in SHACL in a way such that Metamorph can pick up on them and transform them to your desired schema.

Preface

Unlike in object-orientation (OO), relational modeling and many other modeling paradigms, in Semantic Web there is a difference between:

• Semantic definitions, which tell what things mean. These are typically modeled using RDF and OWL classes, and RDF properties.
• Structural definitions, which impose a structure on things. These are typically modeled using SHACL using node and property shapes.

In this document, UML classes will be used to describe node shapes. Furthermore, the following namespace prefixes will be used:

prefix exsh: <http://example.com/Shapes#> .
prefix exvoc: <http://example.com/Shapes#> .
prefix sh: <http://www.w3.org/ns/shacl#> .
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
prefix xsd: <http://example.com/ns#> .

Modeling

Classes

In SHACL, classes translate to a node shape with a target class corresponding to an OWL or RDF class as defined in your vocabulary.

Simple class

Let's start with a simple class definition in the UML Model.

This would be expressed in the following way in SHACL:

exsh:ExampleNodeShape a sh:NodeShape ;
    sh:targetClass exvoc:Class1 .

Class with attributes

For these examples, we define attribute as a property with a primitive type. So, basically an owl:DatatypeProperty.

Attributes become property shapes in SHACL. There are two equivalent ways of modeling this.

Inline as blank nodes:

exsh:ExampleNodeShape a sh:NodeShape ;
    sh:targetClass exvoc:Class1 ;
    sh:property [
        sh:path exvoc:attribute1 ;
        sh:datatype xsd:string ;
        sh:maxCount 1 ;
    ] ;
    sh:property [
        sh:path exvoc:attribute2 ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:datatype xsd:DateTime ;
    ] ;
    sh:property [
        sh:path exvoc:attribute3 ;
        sh:minCount 1 ;
        sh:datatype xsd:integer ;
    ]

Or as named individuals:

exsh:ExampleNodeShape a sh:NodeShape ;
    sh:targetClass exvoc:Class1 ;
    sh:property exsh:attribute1Shape ,
                exsh:attribute2Shape ,
                exsh:attribute3Shape .

exsh:attribute1Shape a sh:PropertyShape ;
    sh:path exvoc:attribute1 ;
    sh:datatype xsd:string ;
    sh:maxCount 1 .

exsh:attribute1Shape a sh:PropertyShape ;
    sh:path exvoc:attribute2 ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:datatype xsd:DateTime .

 exsh:attribute3Shape a sh:PropertyShape ;
    sh:path exvoc:attribute3 ;
    sh:minCount 1 ;
    sh:datatype xsd:integer .

These two representations are identical and will be interpreted in the same way. The decision to explicitly name (i.e. give it a URI) a sh:PropertyShape is up to the modeler. One particularly good reason to use a named individual is if a property shape is reused in multiple node shapes.

---

In the remaining examples we will be using the blank node notation for property shapes.

---

Class with association

Associations, like attributes, are modeled as property shapes. The difference is that instead of pointing to values types like attributes do, they point to another object. SHACL allows for two ways of modeling associations:

• Shape-based constraints using sh:node
  • where you reference another sh:NodeShape, which the data needs to conform to
• Value type constraints using sh:class
  • where you reference an rdfs:Class or owl:Class that the target resource needs to be an instance of

While both are supported by the SHACL standard and SHACL validatiors, the difference in their meaning and implications make sh:node less ambiguous and therefore preferred when defining profiles.

Using sh:node, this would be modeled as such:

exsh:Class1Shape a sh:NodeShape ;
    sh:targetClass exvoc:Class1 ;
    sh:property [
        sh:path exvoc:hasClass ;
        sh:maxCount 1 ;
        sh:node exsh:Class2Shape ;
    ] .

exsh:Class2Shape a sh:NodeShape ;
    sh:targetClass exvoc:Class2 .

Class with inheritance

In the next example, we'll discuss inheritance. Inheritance is a tricky concept because it has a different meaning in semantic modeling and data structure modeling.

Semantic modeling

Any individual of the subclass/specialization is also an individual of the superclass/generalization.

For example: say Rabbit is a subclass of Mammal, Fluffy is a Rabbit, then Fluffy is also a Mammal. In OWL this is modeled with the owl:subClassOf association.

Data structure modeling

Any attribute or association that can be applied to the superclass/generalization, may also be applied to the subclass/specialization.

For example: for administrative purposes the register would like to assign buildings a document number. In their model, they decided to make Building a subclass of Document. Structurally, this allows them to define document number once and use it on both Building and Document (or on anything they wish to, really). This, however, does not mean that a building is a document.

In SHACL this is modeled using the sh:and association.

---

Defining a model for the purpose of schema generation, our focus will be on data structure modeling, so we are interested in the behavior of sh:and. As such, the situation above is modeled as follows:

exsh:Class1Shape a sh:NodeShape ;
    sh:targetClass exvoc:Class1 ;
    sh:property [
        sh:path exvoc:attribute1 ;
        sh:maxCount 1 ;
        sh:datatype xsd:string ;
    ] .

exsh:Class2Shape a sh:NodeShape ;
    sh:targetClass exvoc:Class2 ;
    sh:and exsh:Class1Shape.

---

Note: the use of sh:and is discouraged. In most situations shape graphs tend to be relatively small, so it's better to 'flatten' the complex taxonomies you find in a semantic model and just model the properties (attributes and associations) you need directly on the node shapes.

There are some exceptions with large structural models where this becomes hard to manage. In those cases the use of sh:and is advisable, if only to make the maintenance of the model manageable.

---

Enumerated class

In this example we we'll discuss how to model an attribute that is supposed to have an enumerated value. In Semantic Web, an enumerated class is also a class, and therefore the attribute is considered to be an association (i.e. an instance of owl:ObjectProperty), and, therefore, modeled in sh:node in SHACL:

exsh:Class1Shape a sh:NodeShape ;
    sh:targetClass exvoc:Class1 ;
    sh:property [
        sh:path exvoc:attribute4 ;
        sh:minCount 1;
        sh:maxCount 1 ;
        sh:node exsh:EnumeratedClassShape ;
    ] .

exsh:EnumeratedClassShape a sh:NodeShape;
    sh:in (
        exvoc:Red
        exvoc:Yellow
        exvoc:Green
    ) .

Conclusion

We have discussed the most common modeling constructs you will need to define the data structure model of a profile. Any of these can be combined to form more elaborate structures. If you limit yourself to these modeling constructs, your model can easily be transformed into many technology-specific schemas with Metamorph.

Author: Joep van Genuchten
Edited by: Bart Kleijngeld