Given a choice between OWL Property Restrictions and SHACL, is there any reason to choose the OWL approach any more?
Particularly with respect to cardinality constraints
I think the fact that OWL is fully based on the Open World Assumption makes it quite unique. There are use cases where you bring together many datasets from many different sources that need this unique feature. For any given fact there may always be different opinions from different sources. Fundamental support in your "data fabric" (or Enterprise Knowledge Graph) for "Multiple versions of the Truth" is critical or even stronger: it is the single most important enabler for enterprise-wide use cases. For the EKG we need OWL to be the core. To form the "unbiased" representation of all your data, not forcing any particular closed world view of the world, inferring all the right facts. With lots of translation languages in the onion ring around that such as SHACL (strict context-specific closed-world shapes of objects), SPARQL (graph 2 tabular), R2RML (tabular 2 graph) and so forth.
The differences between OWL and SHACL are presented in the table below.
OWL | SHACL |
---|---|
Based on open world assumption | Based on closed world assumption |
Designed for inferencing | Designed for validation |
Computationally cheap (typical problems are decidable) | ? |
A lot of inferences almost "out of the box" | One have to define a lot of constraints manually |
Is useful as documentation for RDF |
As to cardinality constraints in OWL, these constraints allow to close the world in some respects in some cases, in order to get additional inferences.
The logic of cardinality constraints is opposite in OWL and in SHACL. Informally:
In SHACL,
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:path ex:parent ;
sh:minCount 1 .`
means that if somebody is a person, then he/she has to have at least one parent.
In OWL,
ex:Person owl:equivalentClass [ rdf:type owl:Restriction ;
owl:onProperty ex:parent ;
owl:minCardinality "1" ] . `
means that if somebody has at least one parent, then he/she is a person.
From TopBraid marketing materials:
How is SHACL different from RDF Schema and OWL? RDFS and OWL were designed for an “Open World” in which data may be assembled from many places on the Semantic Web. This design goal has caused a lot of frustration over the years, because it made it impossible to check even the most obvious integrity constraints, such as whether a property has a certain number of values. In contrast, SHACL assumes a “Closed World”, aligning with the expectations of typical business users. Furthermore, OWL has been optimized for a certain type of classification problems, yet it could not be used to do routine operations necessary for data validation such as mathematical computations or text operations. SHACL is much more expressive. Further it seamlessly integrates with SPARQL to express almost arbitrary conditions. BTW it is perfectly fine to incrementally extend an RDFS or OWL model with SHACL statements, supporting both worlds.
See also: http://spinrdf.org/shacl-and-owl.html
In my experience, most users of OWL have not really understood or do not care about the actual semantics of OWL (open-world assumption etc). In many cases, OWL cardinality restrictions have been used because there was no other alternative. Yet, as pointed out elsewhere, the semantics of an owl:maxCardinality 1 is backwards from what most people expect: it means that if the property has two values then those values are assumed to be the same (owl:sameAs). In SHACL, a sh:maxCount 1 means that if the property has two values then one of them needs to be deleted.
The main reasons for continuing to use OWL in favor of SHACL are that OWL has a longer history (i.e. more tools, reusable ontologies and examples), and in case you want to use OWL (DL) inferencing. But if you need traditional closed-world semantics, use SHACL. Note that SHACL and OWL can be mixed, for example define classes and properties in one file, then define OWL restrictions in another file and SHACL constraints in yet another file.
In my experience OWL reasoning is very rarely used, and the complex OWL constructs (including Restriction
and unionOf
) are not very useful.
Even rdfs:domain/range
cause reuse problems because they are monomorphic: use them with several values, and you're calling for trouble.
So we at Ontotext have been using lately example-based models, non-committal schema:domain/rangeIncludes
, and shapes to express how classes and props are used together.