owl:oneOf to shacl ?

3 views
Skip to first unread message

Bohms, H.M. (Michel)

unread,
Apr 21, 2020, 5:07:05 AM4/21/20
to topbrai...@googlegroups.com

If I want to move:

 

ex:loadLevel

  a rdf:Property ;

  rdfs:domain ex:Vehicle ;

  rdfs:range ex:LoadLevelType ;

.

 

ex:LoadLevelType

  a rdfs:Class ;

  rdfs:subClassOf smls:EnumerationType ;

  owl:oneOf (

      ex:Light

      ex:Normal

      ex:Heavy

    ) ;

.

 

To SHACL; what is the best way to handle the owl:oneOf?

 

1.  in a property shape for loadLevel involving sh:targetSubjectsOf with sh:in

 

2. in the nodeshape for vehicle with sh:in on with path ex:loadLevel

 

For rdfs ranges I use 2. in case there is also a domain and 1. In case there is no domain, but here the constraint is more generic on the range class.

 

Thx Michel

 

Ps

Related:

In general wouldn’t it be more precise to always map a range to a property shape (involving targetSubjectsOf) so also in case there is a domain clause...since domain and range are fully independent....

 

 

 

 

 

 

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.

 

 

 

 

dprice

unread,
Apr 21, 2020, 5:56:12 AM4/21/20
to topbrai...@googlegroups.com
Not sure about “best” but I did this and it works great and aligns with your model:

1) Added to ensure drop-down lists show the right instances for selection in a UI

ex:Heavy
  a ex:LoadLevelType ;
  rdfs:label "Heavy" ;
.
ex:Light
  a ex:LoadLevelType ;
  rdfs:label "Light" ;
.
ex:Normal
  a ex:LoadLevelType ;
  rdfs:label "Normal" ;
.

2) sh:in in the PropertyShape gives me a violation if I go in and make an instance with anything other than the 3 selections

ex:Vehicle-loadLevel
  a sh:PropertyShape ;
  sh:path ex:loadLevel ;
  sh:class ex:LoadLevelType ;
  sh:in (
      ex:Light
      ex:Normal
      ex:Heavy
    ) ;
.

Cheers,
David

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/33cb2621c13641ffbf7e027bf9111354%40tno.nl.


Bohms, H.M. (Michel)

unread,
Apr 21, 2020, 6:45:01 AM4/21/20
to topbrai...@googlegroups.com

 

I’ll add the labels indeed!

 

Wrt shacl: what is the target of this shape?

 

No need to add sh:targetSubjectsOf ex:loadLevel ?

 

 

 

 

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

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

Location

 

dprice

unread,
Apr 21, 2020, 6:49:27 AM4/21/20
to topbrai...@googlegroups.com
Oops - also had this:

ex:Vehicle
  a sh:NodeShape ;
  sh:property ex:Vehicle-loadLevel ;
.

ex:LoadLevelType
  a sh:NodeShape ;
.

Cheers,
David

On 21 Apr 2020, at 11:44, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 
I’ll add the labels indeed!
 
Wrt shacl: what is the target of this shape?
 
No need to add sh:targetSubjectsOf ex:loadLevel ?
 
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

Jan Voskuil

unread,
Apr 21, 2020, 6:57:52 AM4/21/20
to topbrai...@googlegroups.com

The shape is a property shape. Wherever the property in the property path occurs (i.e. ex:loadLevel), the constraint will be checked/validated. So, no need to specify sh:targetSubjectsOf --- unless you want the constraint to hold only if a specific type of subject is present. -j

Bohms, H.M. (Michel)

unread,
Apr 21, 2020, 6:58:47 AM4/21/20
to topbrai...@googlegroups.com

Hi David,

 

Ahh, ok, great, exactly as I had it now (only with explicit nodeshape and anonymous sh:property):

 

ex:Vehicle

  a rdfs:Class ;

  rdfs:subClassOf smls:PhysicalObject ;

.

ex:VehicleShape

  a sh:NodeShape ;

  sh:targetClass ex:Vehicle ;

  sh:property [

    sh:path ex:loadLevel ;

    sh:class ex:LoadLevelType ;

    sh:in (ex:Light ex:Normal ex:Heavy ) ;

    ] ;

.

 

So the only potential issue I saw with this approach:

Now this constraint is modelled only in the context of Vehicle, being the domain.

But actually the range always holds also in case the ex:loadLevel is a property of something not of type domain (here ex:Vehicle)....(this is still possible since domain means “at least” and not “only” ...)

 

So I thought...maybe it would be more accurate to make it into a property shape for sh:allSubjectsOf this property....

 

What do you think of this?

 

Thx again, Michel

 

 

 

 

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

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

Location

 

Bohms, H.M. (Michel)

unread,
Apr 21, 2020, 7:04:40 AM4/21/20
to topbrai...@googlegroups.com

 

Hmmm...I thought that you would use sh:targetSubjectsOf if you want to constrain independent from the type of subject!

(so just any subject having the property)

 

(In david example the target was ex:Vehicle, so he used the property shape in the context of a sh:NodeShape)

dprice

unread,
Apr 21, 2020, 7:17:18 AM4/21/20
to topbrai...@googlegroups.com
Technically, x:Vehicle-loadLevel is independent which may not be exactly what you want. Since you had a domain on the property, you’ve said it is not independent of subject - so I used the PS name to make the intent clear. 

I personally prefer the sh:property style of modelling because I can look at the NodeShape and it’s superclasses to find every property shape that comes into play. That does mean when focusing on the PS I have to do a search to “Find references” for the NS (but by using the PS naming convention of Class-Property I don’t actually need to do that to know where the PS is used).

Cheers,
David


On 21 Apr 2020, at 12:04, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 
Hmmm...I thought that you would use sh:targetSubjectsOf if you want to constrain independent from the type of subject!
(so just any subject having the property)
 
(In david example the target was ex:Vehicle, so he used the property shape in the context of a sh:NodeShape)
 
 
 
 
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.
Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Jan Voskuil
Verzonden: Tuesday, April 21, 2020 12:58 PM
Aan: topbrai...@googlegroups.com
Onderwerp: RE: [topbraid-users] owl:oneOf to shacl ?
 
The shape is a property shape. Wherever the property in the property path occurs (i.e. ex:loadLevel), the constraint will be checked/validated. So, no need to specify sh:targetSubjectsOf --- unless you want the constraint to hold only if a specific type of subject is present. -j
 
From: 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> 
Sent: 21 April 2020 12:45
To: topbrai...@googlegroups.com
Subject: RE: [topbraid-users] owl:oneOf to shacl ?
 
 
I’ll add the labels indeed!
 
Wrt shacl: what is the target of this shape?
 
No need to add sh:targetSubjectsOf ex:loadLevel ?
 

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

Bohms, H.M. (Michel)

unread,
Apr 21, 2020, 7:41:18 AM4/21/20
to topbrai...@googlegroups.com

 

What I meant was: domain and range are independent so if I have only a range, I HAVE to make it an explicit Propertyshape (with as I think: a allSubjectsFrom...).

But if I have a domain AND a range, I can do the range via sh:property/sh:class/sh:datatype in the NodeShape (as we did now).

 

 

My issue is: the range restriction does not only hold in the domain case: it always holds..its independent of that domain.

So...shouldnt a range always be modelled separately from the domain nodeshape, in general as a property shape.

(subissue being then whether sh:allSubjectsOf is needed or not, see  reply Jan; I am still unsure there: you have to give a path and that path should start at some target or is there some kind of default in play here?)

 

 

 

 

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

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

Location

 

dprice

unread,
Apr 21, 2020, 10:28:27 AM4/21/20
to topbrai...@googlegroups.com

On 21 Apr 2020, at 12:41, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 
What I meant was: domain and range are independent so if I have only a range, I HAVE to make it an explicit Propertyshape (with as I think: a allSubjectsFrom...).
But if I have a domain AND a range, I can do the range via sh:property/sh:class/sh:datatype in the NodeShape (as we did now).
 
 
My issue is: the range restriction does not only hold in the domain case: it always holds..its independent of that domain.

I’m not sure why this is an issue. A named PS can use sh:class or sh:datatype to specify the required “range" with no mention of “domain”. I’m not sure I agree - see below.

So...shouldnt a range always be modelled separately from the domain nodeshape, in general as a property shape.

Not necessarily. Some PropertyShapes (i.e. properties) only make sense in the context of a specific NodeShape (i.e. Class). The US has Social Security Number with a required NNN-NN-NNNN pattern and only instances of class USPerson (i.e. U.S. citizens, permanent residents, and temporary (working) residents) can have that - class Dog cannot, so not necessary to model it outside the context of Person. In fact, you might argue that making it a separate named PS with just a sh:path and sh:datatype creates the potential for misuse by other modellers using your shapes, and therefore choose not to do so.

(subissue being then whether sh:allSubjectsOf is needed or not, see  reply Jan; I am still unsure there: you have to give a path and that path should start at some target or is there some kind of default in play here?)

In your simple case, all that's required in SHACL is that PS sh:path should be the IRI of the predicate (plus the sh:class or sh:datatype). You can then say more in the NodeShapes that control where the PS is used.

Cheers,
David

Bohms, H.M. (Michel)

unread,
Apr 21, 2020, 11:12:06 AM4/21/20
to topbrai...@googlegroups.com

Hi David

 

I see the need for often context (domain)-sepcific constraints.

 

But my question is about universal constraints like an rdfs:range or a property being functional etc.

 

In  https://spinrdf.org/shacl-and-owl.html there is the example for functional.

 

I used this approach for the range:

 

ex:accuracy

  a rdf:Property ;

.

ex:accuracyShape

  a sh:PropertyShape ;

  sh:targetSubjectsOf ex:accuracy ;

  sh:path ex:accuracy ;

  sh:class smls:QuantityValue ;

.

 

There are now 2 issues.

 

Issue 1:

- is the red needed or not?

 

Issue 2:

- even if there is a domain so this constraint can be modelled in the context of a nodeshape, wouldn’t it be better to do it as above (since domain and range are completely independent, so the range constraint also holds for instances of the property not of type domain)

 

 

 

 

 

 

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

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

Location

 

Irene Polikoff

unread,
Apr 21, 2020, 11:46:36 AM4/21/20
to topbrai...@googlegroups.com
See below

On Apr 21, 2020, at 11:12 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Hi David
 
I see the need for often context (domain)-sepcific constraints.
 
But my question is about universal constraints like an rdfs:range or a property being functional etc.
 
In  https://spinrdf.org/shacl-and-owl.html there is the example for functional.
 
I used this approach for the range:
 
ex:accuracy
  a rdf:Property ;
.
ex:accuracyShape
  a sh:PropertyShape ;
  sh:targetSubjectsOf ex:accuracy ;
  sh:path ex:accuracy ;
  sh:class smls:QuantityValue ;
.
 
There are now 2 issues.
 
Issue 1:
- is the red needed or not?

If you plan on using a property shape stand alone, outside of a node shape, it needs a target. Otherwise, it gets a target from the node shape.

ex:accuracyShape
  a sh:PropertyShape ;
  sh:targetObjectsOf ex:accuracy ;
  sh:class smls:QuantityValue ;
.

Is the same as

ex:accuracyShape
  a sh:PropertyShape ;
  sh:targetSubjectsOf ex:accuracy ;
  sh:path ex:accuracy ;
  sh:class smls:QuantityValue ;
.


Issue 2:
- even if there is a domain so this constraint can be modelled in the context of a nodeshape, wouldn’t it be better to do it as above (since domain and range are completely independent, so the range constraint also holds for instances of the property not of type domain)


Better for what? For tools? I would not say so. 

With this approach, there is more figuring out to do in order to identify the applicability of a property and the allowed values when you are dealing with a resource. If one needs to have highly responsive user interface, this will slow it down considerably and add complexity. Even just from the validation perspective and assuming you do not need real time validation, checking for all possible options and running them will take more time. If performance is never an issue, then, pile on whatever you want.

Bohms, H.M. (Michel)

unread,
Apr 22, 2020, 3:23:12 AM4/22/20
to topbrai...@googlegroups.com

Thx Irene

 

- so red should be in, clear!

- leaving out the path was new to me. So this is the default semantics when no (other) path is specified? Guess there is some rule “if no path then use property indicated by targetSubjectsOf”? Is that somewhere specified in the shacl spec?

- wrt range in case of also domain: I did not argue based on performance just on logic: if it is always separate also in case of domain there would be one simple rule and not a rule like:

“if there is no domain map range to propertyshape with allSubjectsFRom, if there is a domain (or domains) map range to propertyshape used by node shape”.

- an as said: the dealing with the range would be independent of whether there is a domain or not.

- anyway, apart from this logic, I see the practical interpretation that you are in general especially interested in the range IN CASE of the domain is relevant so I will also stick to the second more complex mapping. Guess this is also more in line with the CWA-situation you map towards.

 

Best regards Michel

 

 

 

 

 

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

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

Location

 

dprice

unread,
Apr 22, 2020, 6:19:00 AM4/22/20
to topbrai...@googlegroups.com

On 22 Apr 2020, at 08:23, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Thx Irene
 
- so red should be in, clear!

Only if not using sh:property .

- leaving out the path was new to me.

That’s an error. PS all have sh:path by-definition - “A property shape is a shape in the shapes graph that is the subject of a triple that has sh:path as its predicate.” from the spec.

So this is the default semantics when no (other) path is specified? Guess there is some rule “if no path then use property indicated by targetSubjectsOf”? Is that somewhere specified in the shacl spec?
- wrt range in case of also domain: I did not argue based on performance just on logic: if it is always separate also in case of domain there would be one simple rule and not a rule like:
“if there is no domain map range to propertyshape with allSubjectsFRom, if there is a domain (or domains) map range to propertyshape used by node shape”.
- an as said: the dealing with the range would be independent of whether there is a domain or not.
- anyway, apart from this logic, I see the practical interpretation that you are in general especially interested in the range IN CASE of the domain is relevant so I will also stick to the second more complex mapping. Guess this is also more in line with the CWA-situation you map towards.

A few further comments below responding to your earlier concerns. I’m not sure all “range” possibilities have been thought thru in some of this discussion.

 
Best regards 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.
 
Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Irene Polikoff
Verzonden: Tuesday, April 21, 2020 5:46 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] owl:oneOf to shacl ?
 
See below


On Apr 21, 2020, at 11:12 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:
 
Hi David
 
I see the need for often context (domain)-sepcific constraints.
 
But my question is about universal constraints like an rdfs:range or a property being functional etc.

range is not “universal”. If a property has rdfs:range xsd:integer for a specific class/NS, then in any of it’s subclasses a further constraint can be added to the value space of that property, to only allow positive integers for example. In OWL, sub-properties sometimes do the same thing (e.g. ex:US_SSN might be a sub-property of ex:identifier and require the US SSN formate string rather than a general string).
The red is needed only if you do not use sh:property in NodeShapes. Note that I explain again why I prefer sh:property approach below.


 
Issue 2:
- even if there is a domain so this constraint can be modelled in the context of a nodeshape, wouldn’t it be better to do it as above (since domain and range are completely independent, so the range constraint also holds for instances of the property not of type domain)

This is no concept of “instances of the property”, so this issue does not make sense to me. All property values (i.e predicate + object) are associated with a subject that is rdf:type a NodeShape/Class.

 
 
Better for what? For tools? I would not say so. 

I always specify the relevant properties in the NodeShape/Class. It’s far better wrt communication with humans reading your ontology, for example. People in general don’t think of independent properties floating around to be randomly assigned to individuals. They think if classes of individuals that are *defined* by the set of relevant properties. In many standards the definition for a subclass is "A SubX is a SuperA where <further properties specifying criteria go here>” and  "A SubZ is a SuperA where <different further properties specifying criteria go here>”. Also, if you use sh:targetSubjectOf then every ontology that re-uses yours and wants to use that property has to change the property shape itself (probably imported from your graph) rather than just using sh:property in the NodeShape they define in their graph. So, I find sh:property preferable from an ontology partitioning perspective as well for re-usable properties.

 
With this approach, there is more figuring out to do in order to identify the applicability of a property and the allowed values when you are dealing with a resource. If one needs to have highly responsive user interface, this will slow it down considerably and add complexity. Even just from the validation perspective and assuming you do not need real time validation, checking for all possible options and running them will take more time. If performance is never an issue, then, pile on whatever you want.

FWIW many of our EDG customers do real-time data validation when editing so it is an important feature. Typically, shapes graphs are not large enough for any of this to have a significant impact on UI performance (i.e. the scale of the data itself is almost always the main “problem” wrt performance issues).

Cheers,
David

Bohms, H.M. (Michel)

unread,
Apr 22, 2020, 6:32:13 AM4/22/20
to topbrai...@googlegroups.com

Thx David

 

- path, that would make sense...but I have mixed message now...

- performance, again mixed messages, anyway I like to focus on the logic- considerations

- universal: with universal I mean restrictions that are on the property not on the class. So domain and range I see as universal restrictions. When going to shacl the domain can be trivially become a property shape within a node shape based on “relevance”. But for the range it is more complex: the range holds independent of the domain so assuming there is no domain the best thing you can do is an explicit propertyshape (with targetSubjectsOf and path). In case there IS a domain you can assume the range constraint is most relevant there (although formally not ONLY there) and make the range sh:class into an implicit or explicit property shape. Does this makes sense?

 

 

 

 

 

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

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

Location

 

Irene Polikoff

unread,
Apr 22, 2020, 7:10:48 AM4/22/20
to topbrai...@googlegroups.com
I made a typo. It should be

ex:accuracyShape

  a sh:NodeShape ;

  sh:targetObjectsOf ex:accuracy ;

  sh:class smls:QuantityValue ;


Node shapes don’t have a path. Constraints specified for a NodeShape apply directly to the targets as opposed to other nodes that are reached by following a path.

Sent from my iPhone

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

Thx Irene

 

- so red should be in, clear!

- leaving out the path was new to me. So this is the default semantics when no (other) path is specified? Guess there is some rule “if no path then use property indicated by targetSubjectsOf”? Is that somewhere specified in the shacl spec?

- wrt range in case of also domain: I did not argue based on performance just on logic: if it is always separate also in case of domain there would be one simple rule and not a rule like:

“if there is no domain map range to propertyshape with allSubjectsFRom, if there is a domain (or domains) map range to propertyshape used by node shape”.

- an as said: the dealing with the range would be independent of whether there is a domain or not.

- anyway, apart from this logic, I see the practical interpretation that you are in general especially interested in the range IN CASE of the domain is relevant so I will also stick to the second more complex mapping. Guess this is also more in line with the CWA-situation you map towards.

 

Best regards Michel

 

 

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

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

Location

 

Bohms, H.M. (Michel)

unread,
Apr 22, 2020, 7:26:14 AM4/22/20
to topbrai...@googlegroups.com

Ahh ok, now I see the equivalence

 

 

So I guess your alternative is preferred (shorter)

 

 

 

 

 

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

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

Location

 

Irene Polikoff

unread,
Apr 22, 2020, 9:05:48 AM4/22/20
to topbrai...@googlegroups.com
You asked “what is better”. To me, answering this question requires considering the context of use from which come criteria for what it means to be better.

If you are making some statements that will simply be read by other people, then the most important criteria for ‘better’ is how easily other people can understand these statements.

If you are making statements that are intended to be machine processable, then I do not see how “better” can’t be decided on without considering performance implications.

Bohms, H.M. (Michel)

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

Agreed, although “logically better” would in my view always prevail over “performance better”.

Of course logic can be compromised for performance reasons but then that should be made as explicit as possible.

(beyond that I think David also argued that performance was here not such a big issue in EDG)

 

gr

 

 

 

 

 

 

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.

 

 

 

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Irene Polikoff
Verzonden: Wednesday, April 22, 2020 3:06 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] owl:oneOf to shacl ?

 

You asked “what is better”. To me, answering this question requires considering the context of use from which come criteria for what it means to be better.

--

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.

Reply all
Reply to author
Forward
0 new messages