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'm wondering whether SHACL is considered to supercede OWL. The syntax appears similar, to my casual inspection.
I am probably missing the purpose of OWL cardinality constraints. As part of an ontology, they should facilitate inferencing (a separate concern from validation). But how do cardinality constraints facilitate inferencing?
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 | One have to define a lot |
| almost "out of the box" | of ad-hoc 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.
来源：https://stackoverflow.com/questions/44767223/owl-property-restrictions-vs-shacl