Following my two recent talks at the Enterprise Data World, 2018:
- SHACL (Shapes Constraint Language) – An Introduction, [Download Slides >>]
- FIBO in SHACL: The Next Step in Data Validation and Interoperability, [Download Slides >]
I have been getting many questions about specific details of the automated OWL to SHACL convertor that is included in TopBraid products.
Motivations for the Conversion
In this post, I am not going to focus on why one would want to do the conversion, but, rather, discuss how conversion is done and what is being converted.
If you are interested in some information on ‘why’, there are:
- useful links on the SHACL page
- a post I have previously wrote on how SHACL supports data governance
- the two talks I gave at the conference, touch on this as well– see presentations attached above.
With the ‘why’ question addressed, let’s talk about how. Be aware that this is a post with a lot of technical details. If this is what interests you, stay on!
How to Run the Conversion
- If you are a user of TopBraid Composer, you will find ‘Convert OWL/RDFS to SHACL…’ under the Model menu. This operation will convert the model you currently have open, creating a new RDF file. You will be able to select some options such as whether the converted graph should continue to include converted RDFS/OWL statements or whether they should be removed.
- If you are a user of TopBraid EDG, select any ontology managed by EDG and then click on Transform tab (requires 6.0 or higher). Along with this option, you will find a number of other transformation/inference/rule execution capabilities that are being added to TopBraid EDG starting with the 6.0 release. Conversion operation will transform the graph (asset collection in EDG speak) you are running it on. In EDG, you are not working with files, but rather with named graphs in EDG’s triple store. You will also, if desired, be able to perform this operation in a context of a workflow/working copy and then review and approve the transformations before committing them.
What will be Converted and How
Much of conversion is done using SHACL rules. In TopBraid Composer, you can examine owl2shacl.ttl to see the rules used. This file gives you definitive information about the scope and coverage of conversion. I am sure that additions will happen as more users try the convertor.
Here is a list of what is being automatically converted at the time of writing and how:
rdfs:subClassOf restrictions are converted to property shapes connected to the classes that are subjects in {?subject rdfs:subClassOf ?restriction} statement. The classes will get rdf:type sh:NodeShape triple, making them shapes as well as classes. The property shapes will use the following constraint components:
- owl:allValuesFrom statements are converted to property shapes with either sh:class (for object properties) or sh:datatype constraint components
See owl2shacl:owlAllValuesFrom2shClassOrDatatype rule
- owl:minCardinality statements are converted to property shapes with sh:minCount constraint component
See owl2shacl:owlMinCardinality2shMinCount rule
- owl:maxCardinality statements are converted to property shapes with sh:maxCount constraint component
See owl2shacl:owlMinCardinality2shMaxCount rule
- owl:cardinality statements are converted to property shapes with sh:minCount and sh:maxCount constraint component
- owl:hasValue statements are converted to property shapes with sh:hasValue constraint component
See owl2shacl:owlHasValue2shHasValue rule
- owl:someValueFrom statements are converted to property shapes with dash:hasValueWithClass constraint component – unless the range of the property is the same as the value of owl:someValueFrom. In the latter case, it is converted to sh:minCount = 1. Further, sh:minCount is always produced, as a backup for tools that only understand that.
See owl2shacl:owlSomeValuesFromIRI2dashHasValueWithClass and owl2shacl:owlSomeValuesFrom2shMinCount1 rules
- qualified cardinality restrictions are converted to corresponding qualified value shapes – unless the range of the property is the same as the value of owl:onClass. In the latter case, it is converted to the plain sh:minCount/sh:maxCount shapes.
rdfs:domain statements are converted to property shapes connected to the classes that are objects in {?property rdfs:domain ?object} statements. Classes will get a rdf:type sh:NodeShape triple. If there is a rdfs:range statement for the property, resulting shapes will have either sh:class or sh:datatype constraint components that correspond to the range.
See owl2shacl:CreatePropertyShapesFromMatchingDomains rule
owl:FunctionalProperty statements are converted as sh:maxCount = 1.
owl:equivalentClassOf restrictions – currently, not converted because we feel that they need to be converted as SHACL Rules. This may be a next step for the converter.
The only exception is if the value of owl:equivalentClassOf is an owl:intersectionOf some restrictions. The class that is the subject of the owl:equivalentClassOf statement is declared to be rdfs:subClassOf each restriction in the intersection. These are then converted according to the rules specified above.
See owl2shacl:CopyEquivalentIntersection rule.
If a restriction uses owl:unionOf to specify the range of values in owl:allValuesFrom or owl:someValuesFrom, converted shapes will use sh:or.
For example, the following FIBO restriction (in Manchester syntax):
fibo-fnd-rel-rel:isHeldBy only (fibo-be-oac-opty:Investor or fibo-fbc-pas-fpas:FinancialServiceProvider)
is converted as
fibo-sec-sec-ast:Portfolio-isHeldBy
rdf:type sh:PropertyShape ;
sh:path fibo-fnd-rel-rel:isHeldBy ;
sh:class fibo-fnd-aap-agt:AutonomousAgent ;
sh:or (
[
sh:class fibo-be-oac-opty:Investor ;
]
[
sh:class fibo-fbc-pas-fpas:FinancialServiceProvider ;
]
) ;
As you can see from the above, most property shapes are created as resources with the URI formed as a concatenation of a class and a property e.g., fibo-sec-sec-ast:Portfolio-isHeldBy. We recommend that you follow this practice when defining SHACL shapes manually. TopBraid EDG will enforce this best practice.
Exception to this practice in the generation process are qualified value property shapes. They are generated as blank nodes within the node shapes. It currently works this way because we have not yet settled on the algorithm to use for generating property shape URIs in this situation.
What will Not be Converted
As stated previously, this blog describes what is being converted at the time of this writing. We fully expect to be extending conversion capabilities over time. It is quite likely that when you read the blog, conversion includes more than what stated here. With this caveat in mind, here is what is not converted in the current implementation:
Complex axioms where values of owl:allValuesFrom, owl:someValuesFrom, owl:hasValue or owl:onClass are intersections of other restrictions are not handled. For example, the following FIBO restriction:
fibo-fnd-pty-rl:isPlayedBy some ((fibo-fnd-rel-rel:controls only fibo-be-le-fbo:FormallyConstitutedOrganization)
or (fibo-be-oac-cpty:hasDegreeOfControl only fibo-be-oac-cpty:DegreeOfControl)
or (fibo-be-oac-cpty:hasNatureOfControl only fibo-be-oac-cpty:LimitedDeFactoControl))
Will be converted only partially, resulting in sh:minCount = 1 constraint for fibo-fnd-pty-rl:isPlayedBy property. Nothing will be said about the range of values for the property.
SHACL has the required expressivity to describe restrictions on the values, but the auto-converter does not translate them. You will need to convert these expressions manually.
Also not auto-converted are owl:disjointUnionOf, owl:disjointWith, owl:oneOf, owl:complimentOf, property chain axioms or disjoint property statements.
Your Input will be Appreciated
Overall, we find that for most commonly used ontologies, this automated conversion handles at least 80% of the content. For example, FIBO has thousands of restrictions and only 21 of the rdfs:subClassOf restrictions were not converted. Several more were converted only partially.
Try out the conversion feature and let us know how it worked for your ontology! We are looking forward to continue to fine tune it based on user feedback.
Other Options to Automate SHACL Shapes Creation
Finally, I wanted to end this post by letting you know about a few additional options for auto-creating SHACL shapes:
- If you have some RDF data and want to generate shapes that correspond to the data, this option is currently available in TBC and in TopBraid EDG. In TBC, use Model -> Derive SHACL Shapes. In TopBraid EDG (6.0 or higher), when working with ontologies, click on Transform tab -> Convert OWL Axioms to SHACL Constraints.
- The reverse option of generating RDF data from SHACL (for testing purposes) is also available in both TBC and in EDG.
- Starting with the 6.0 release, you will be able to create SHACL Shapes from a spreadsheet input as well as from GraphQL Schemas