> On Apr 14, 2020, at 10:57 AM, dprice <dpr...@topquadrant.com> wrote: > > 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.
Presuming this was true, it would help only to ensure that the equivalent class restriction is translated exactly the same as the subClassOf restriction. And I am not certain it is the best approach to ensure this. Let’s say you got >> exPerson a owl:Class; >> rdfs:subClassOf [ owl:onProperty ex:parent; >> owl:allValuesFrom ex:Person]. >> _:b1 a owl:Restriction; >> rdfs:subClassOf ex:Person. From >> exPerson a owl:Class; >> owl:equivalentClass [ owl:onProperty ex:parent; >> owl:allValuesFrom ex:Person]. You would then get the same SHACL translation as if the original restriction used the subclassOf. But nothing would happen as a result of the blank node restriction being inferred a subclass of Person. I also do not think that RDFS inferencing happens in TopBraid prior to the Generate SHACL from RDFS/OWL. Of course, one could force it to happen. On the other hand, it is much simpler to just generate the same shapes irrespective of how the restriction is declared. > > Cheers, > David > >> On 14 Apr 2020, at 15:43, Irene Polikoff <ir...@topquadrant.com >> <mailto:ir...@topquadrant.com>> 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 <topbraid-users@googlegroups.com >>> <mailto:topbraid-users@googlegroups.com>> 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 michel.bo...@tno.nl <mailto:michel.bo...@tno.nl> >>> 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 topbraid-users+unsubscr...@googlegroups.com >>> <mailto:topbraid-users+unsubscr...@googlegroups.com>. >>> 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 topbraid-users+unsubscr...@googlegroups.com >> <mailto:topbraid-users+unsubscr...@googlegroups.com>. >> 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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/C3316663-2D24-4A69-B2FB-1041ADA7BC33%40topquadrant.com > > <https://groups.google.com/d/msgid/topbraid-users/C3316663-2D24-4A69-B2FB-1041ADA7BC33%40topquadrant.com?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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3381CA39-D811-46D2-8B3F-54091CF3FB7D%40topquadrant.com.
