In addition to what Irene said about question 3 and OWL restrictions, I will note that in the very simple case of question 2 where it’s useful when mapping between two shapes graphs/ontologies:
In TopBraid Composer, the RDFS inference default is “on” for SHACL engine and the rdfs:subClassOf inferences are made prior to the validation happening (i.e. it works as expected if subClassOf is stated in both directions). I expect that would be true for at least some other SHACL engines too. Cheers, David > On 14 Apr 2020, at 15:43, Irene Polikoff <[email protected]> wrote: > > Any mapping needs to take into account the specific modeling expression and > what do you actually expect/need to accomplish by using it. > > owl:equivalentClass restrictions mostly differ from rdfs:subClassOf > restrictions in that they directly entail additional classification > inferences. > > For example, let’s say you have: > > exPerson a owl:Class; > rdfs:subClassOf [ owl:onProperty ex:parent; > owl:allValuesFrom ex:Person]. > > ex:Alice a ex:Person; > ex:parent ex:Bob. > > We know from this that Bob must be a person. > > OWL operates under OWA so not having {ex:Bob a ex:Person} triple will not > cause any validation errors. Instead, it will cause an addition of this > triple. > > What do you want to happen in SHACL? > > If you want to get a validation error to ensure that Bob is a member of the > class ex:Person or one of its subclasses AND not a member of any other class > that does not meet this criteria, you would specify sh:class ex:Person > constraint on ex:parent property in a shape that targets members of ex:Person > class. > If you want to get the inference above, you would specify SHACL rule that > generates the triple for Bob. > If a parent could be a person as well as a member of some other class that is > not a subclass of ex:Person (which is what OWL restriction means), you could > use sh:in constraint with a list of possible classes on the > ex:parent/rdfs:subClassOf*/rdf:type path. This is still not exactly like OWL > since you have to list all possible classes. This is because SHACL operates > under CWA. > > Now, let’s say you have: > > exPerson a owl:Class; > owl:equivalentClass [ owl:onProperty ex:parent; > owl:allValuesFrom ex:Person]. > > ex:Alice a ex:Person; > ex:parent ex:Bob. > > In this example, there is no additional entailments. The outcome with OWL > reasoning and the possible solution in SHACL will be exactly as with the > rdfs:subClassOf restriction. > > Let’s say your data is just: > > ex:Alice ex:parent ex:Bob. > > Nothing at all will happen. > > Let’s say your data is just: > > ex:Alice ex:parent ex:Bob. > ex:Bob a ex:Person. > > Now, with OWL we would get an inference {ex:Alice a ex:Person}. > > To get this inference in SHACL, you would need something like: > > ex:PersonRulesShape a sh:NodeShape ; > sh:targetSubjectOf ex:parent ; > sh:rule [ > a sh:TripleRule ; > sh:subject sh:this ; > sh:predicate rdf:type ; > sh:object ex:Person ; > ] ; > sh:condition ex:HasPersonParentShape. # Rule only applies to subjects of a > triple where objects are persons > > ex:HasPersonParentShape a sh:NodeShape; > sh:path ex:parent; > sh:class ex:Person. > > If, on the other hand, you want a violation if Bob is a person and Alice is > not, then do the following: > > ex:Person a owl:Class, sh:NodeShape; > ex:property [ sh:path ^ex:parent; > sh:class ex:Person]. > > This is just one type of restriction. Similarly you could consider other > types of restrictions. > > For example, what do you expect when they use equivalentClass with > cardinalities and hasValue? This is very tricky since under OWA you would not > get violations for these type of restrictions. For allValuesFrom you could > force violations if you use disjoint classes, but no for these types of > restrictions. Are you using them to only infer class membership? This is also > questionable - OWA does not really produce inferencing for such restrictions > since you never know what is the exact number of values or whether a value > exists or not. > > exPerson a owl:Class; > rdfs:subClassOf [ owl:onProperty ex:parent; > owl:cardinality 2]. > > Let’s say you translate it to SHACL as sh:minCount 2 and sh:maxCount 2 > constraint for all people. Note that you would not get a violation with OWL. > > Then for > > exPerson a owl:Class; > owl:equivalentClass [ owl:onProperty ex:parent; > owl:cardinality 2]. > > Do you want a rule inferring that anyone with 2 parents is a person? Do you > want a violation if someone has 2 parents and is not a person? Neither of > those would happen in OWL. > > >> On Apr 14, 2020, at 9:11 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> In our national modelling team the questions were raised how to best map >> owl:equivalentClass to SHACL. >> >> Some ideas: >> 1- related to sh:node (details unclear) (from >> https://spinrdf.org/shacl-and-owl.html >> <https://spinrdf.org/shacl-and-owl.html>) >> >> 2- owl:equivalentClass is just syntactic sugar for: >> -- rdfs:subClassOf in 2 directions >> (ok but how to describe it from one shape-side?) >> >> 3-procedural: shacl-af rule to explicitly code in 2 directions the >> instantiation >> >> An other issue: >> How to deal with more complex variants like: >> >> ex1:Class1 (when property p=p1) equivalent to ex2:ClassY or even: >> ex1:Class1 (when property p=p1) equivalent to ex2:ClassZ (when property q=q1) >> >> we can always fall back to skos:related...but we want to have some more >> semantics..... >> >> thx for advice, Michel >> >> >> >> >> Dr. ir. H.M. (Michel) Böhms >> Senior Data Scientist >> >> T +31888663107 >> M +31630381220 >> E [email protected] <mailto:[email protected]> >> Location >> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707> >> >> >> <image001.gif> <http://www.tno.nl/> >> This message may contain information that is not intended for you. If you >> are not the addressee or if this message was sent to you by mistake, you are >> requested to inform the sender and delete the message. TNO accepts no >> liability for the content of this e-mail, for the manner in which you use it >> and for damage of any kind resulting from the risks inherent to the >> electronic transmission of messages. >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/f3f543e565de44f7930fa4626182e25b%40tno.nl >> >> <https://groups.google.com/d/msgid/topbraid-users/f3f543e565de44f7930fa4626182e25b%40tno.nl?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/3A29746B-1D96-4708-B3CB-9050666D17F0%40topquadrant.com > > <https://groups.google.com/d/msgid/topbraid-users/3A29746B-1D96-4708-B3CB-9050666D17F0%40topquadrant.com?utm_medium=email&utm_source=footer>. UK +44 (0) 7788 561308 US +1 (336) 283-0808 -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/C3316663-2D24-4A69-B2FB-1041ADA7BC33%40topquadrant.com.
