equivalence in shacl

16 views
Skip to first unread message

Bohms, H.M. (Michel)

unread,
Apr 14, 2020, 9:11:49 AM4/14/20
to topbrai...@googlegroups.com

 

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)

 

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...@tno.nl

Location

 

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.

 

 

 

 

Irene Polikoff

unread,
Apr 14, 2020, 10:43:50 AM4/14/20
to topbrai...@googlegroups.com
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 <topbrai...@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)
 
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

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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f3f543e565de44f7930fa4626182e25b%40tno.nl.

dprice

unread,
Apr 14, 2020, 10:57:30 AM4/14/20
to topbrai...@googlegroups.com
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

Irene Polikoff

unread,
Apr 14, 2020, 11:34:03 AM4/14/20
to topbrai...@googlegroups.com

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.

Irene Polikoff

unread,
Apr 15, 2020, 12:51:23 AM4/15/20
to topbrai...@googlegroups.com
Actually, I have to correct myself. Because of OWA, you would not get this inference since there is no way to know that all values come from the class person.

So, I don’t really know under what circumstances one would use this type of restriction.

Bohms, H.M. (Michel)

unread,
Apr 15, 2020, 8:06:46 AM4/15/20
to topbrai...@googlegroups.com

Hi Irene, David

 

Thx, I had been reading this example about 10 times to understand (indeed allvaluesfrom being “at least” not “only” ).

 

Another thing I have been chewing on: the simple case and especially the remarks by David wrt RDFS-entailment.

 

 

My original (very) simple case was: I have two ontologies with different name space and I want to relate concepts from one to the other saying that they are the same. In owl I use owl:equivalentClass and the question was  how best in shacl.

 

I like your split in three cases:

1. Inference like in owl now in shacl (like triple construct)

2. Checking like OWL does (although always compromised by CWA nature as you indicated

3. Stronger checking that might be better reflect what you want in CWA fashion: ie allvaluesfrom: “at least” becomes “only”)

 

I am a bit in doubt about option 2, it always seems compromised (?) and chances are that you actually want 3. So I most like the split in choice 1 and 3.

 

Now about the simple case.

 

ex1:ClassX owl:equivalentClass ex2:ClassY (so no restrictions involved)

 

Or even simpler:

 

ex:ClassX owl:equivalentClass ex:ClassY

 

Or even simpler:

 

ex:ClassX rdfs:subClassOf ex:ClassY AND

ex:ClassY rdfs:subClassOf ex:ClassX

 

Let’s focus on the first only:

 

ex:ClassX rdfs:subClassOf ex:ClassY

 

 

Is it true that I could apply your three options here too? (even now that no restrictions apply) like:

 

Option 1: Inference

 

1a: do nothing in shacl, assume a priori RDFS-entailment

 

1b: In SHACL AF: tripleconstruct self/rdf:type/ClassY

 

Option 2: SHACL SHAPE: sh:property (path rdf:type, sh:hasValue ex:ClassY)

 

Option 3: SHACL SHAPE: sh:property (path rdf:type, sh:in (ex:ClassY, ...... fixed list, maybe all classes in ont)

 

 

Do I understand the mails between you and David right that they were about option 1a or 1b?

(David: a, you: b)

 

In case of option 1b, 2 and 3: could you then actually delete the rdfs:subClassOf clauses in your shacl code (leaving only rdfs class definitions? Well ...assuming there are similar decisions for rdfs:subPropertyOf). Or is the pure owa treatment/inference with of rdfs:subClassOf always a reason to leave it in anyway?

 

 

Or....am I talking complete nonsense now 😊

 

Thx a lot, Michel

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

T +31888663107
M +31630381220
E michel...@tno.nl

Location

 

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-user...@googlegroups.com.

Bohms, H.M. (Michel)

unread,
Apr 15, 2020, 8:11:14 AM4/15/20
to topbrai...@googlegroups.com

Oeps I made mistake in order, right below:

 

 

Hi Irene, David

 

Thx, I had been reading this example about 10 times to understand (indeed allvaluesfrom being “at least” not “only” ).

 

Another thing I have been chewing on: the simple case and especially the remarks by David wrt RDFS-entailment.

 

 

My original (very) simple case was: I have two ontologies with different name space and I want to relate concepts from one to the other saying that they are the same. In owl I use owl:equivalentClass and the question was  how best in shacl.

 

I like your split in three cases:

1. Inference like in owl now in shacl (like triple construct)

2. Checking the OWL Restriction in owl meaning (although always compromised by CWA nature as you indicated

3. Stronger checking that might be better reflect what you want in CWA fashion: ie allvaluesfrom: “at least” becomes “only”)

 

I am a bit in doubt about option 2, it always seems compromised (?) and chances are that you actually want 3. So I most like the split in choice 1 and 3.

 

Now about the simple case.

 

ex1:ClassX owl:equivalentClass ex2:ClassY (so no restrictions involved)

 

Or even simpler:

 

ex:ClassX owl:equivalentClass ex:ClassY

 

Or even simpler:

 

ex:ClassX rdfs:subClassOf ex:ClassY AND

ex:ClassY rdfs:subClassOf ex:ClassX

 

Let’s focus on the first only:

 

ex:ClassX rdfs:subClassOf ex:ClassY

 

 

Is it true that I could apply your three options here too? (even now that no restrictions apply) like:

 

Option 1: Inference

 

1a: do nothing in shacl, assume a priori RDFS-entailment

 

1b: In SHACL AF: tripleconstruct self/rdf:type/ClassY

 

Option 2: SHACL SHAPE: sh:property (path rdf:type, sh:in (ex:ClassY, ...... fixed list, maybe all classes in ont)

 

Option 3: SHACL SHAPE: sh:property (path rdf:type, sh:hasValue ex:ClassY)

Irene Polikoff

unread,
Apr 15, 2020, 9:15:52 AM4/15/20
to topbrai...@googlegroups.com
Michel,

I do not advise removing subclass statements. SHACL uses them as described here https://www.w3.org/TR/shacl/#terminology, see SHACL subclass.

If you want owl:equivalentClass to be understood by a SHACL engine as 2 subClassOf statements, they need to be translated as 2 subClassOf statements prior to providing data for SHACL validation.

How this translation is accomplished is up to you.

Sent from my iPhone

Bohms, H.M. (Michel)

unread,
Apr 15, 2020, 3:03:28 PM4/15/20
to topbrai...@googlegroups.com

 

Thx

 

One of the profiles we use for our cen standard smls is (RDFS+SHACL)

So in a sense if equivalence is relevant here we already model with “2 x rdfs:subClassOf”.

 

Wrt par. 1.5: guess it is ok to assume rdfs-entailment for most shacl processors (so that my shacl af rule for doing the same is obsolete/already taken care of). Would only be relevant when RDFS-entailment is “OFF”.

 

The sentence:

“SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required.”

 

Is a bit unclear: full RDFS inf. is not required does that mean that some limited form IS required? Or can there be no rdfs-entailm. at all? And what is “full”/”limited”? Etc.

 

I am unsure whether my scenarios for CHECKING (not inferencing) the rdfs:subClassOf relations  could be relevant

 

Thx for this whole rdfs/shacl discussion, I learned a lot,

Michel

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

T +31888663107
M +31630381220
E michel...@tno.nl

Location

 

Irene Polikoff

unread,
Apr 15, 2020, 3:50:33 PM4/15/20
to topbrai...@googlegroups.com
It is all described in the spec. See SHACL Subclass, SHACL superclass, SHACL Types and SHACL Class Instance.

SHACL engines are required to perform one type of RDFS inferencing.

?x a C1.
C1 rdfs:subClassOf+ C2.

 |
V

?x a C2

Meaning that any shape specified targeting instances of C2, applies to ?x

And if you have a constraint sh:class C2, ?x is a valid value.

As for entailments, I am not aware of any SHACL implementations that support entailment regimes.

On Apr 15, 2020, at 3:03 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 
Thx
 
One of the profiles we use for our cen standard smls is (RDFS+SHACL)
So in a sense if equivalence is relevant here we already model with “2 x rdfs:subClassOf”.
 
Wrt par. 1.5: guess it is ok to assume rdfs-entailment for most shacl processors (so that my shacl af rule for doing the same is obsolete/already taken care of). Would only be relevant when RDFS-entailment is “OFF”.
 
The sentence:
“SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required.”
 
Is a bit unclear: full RDFS inf. is not required does that mean that some limited form IS required? Or can there be no rdfs-entailm. at all? And what is “full”/”limited”? Etc.
 
I am unsure whether my scenarios for CHECKING (not inferencing) the rdfs:subClassOf relations  could be relevant
 
Thx for this whole rdfs/shacl discussion, I learned a lot,
Michel
 
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

Reply all
Reply to author
Forward
0 new messages