Re: [topbraid-users] oneOf in shacl

2018-11-01 Thread Irene Polikoff 
If you  say

> ex2:Category
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   sh:in (
>   ex2:Pub
>   ex2:Adult
>   ex2:Senior


Then, if a triple such as ex2:Teen a ex2:Category is added, there will a 
violation.

So, if you want to make sure that no one would be able to add more members to 
the ex2:Category class without triggering an issue, then yes, do use sh:in.


> On Nov 1, 2018, at 3:53 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
>  wrote:
> 
> Hi Irene
>  
> Thx for your extensive feedback, much appreciated.
>  
> The situation I now have is the following:
>  
> I DO have both in:
>  
> ex2:Category
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   owl:oneOf (
>   ex2:Pub
>   ex2:Adult
>   ex2:Senior
> ) ;
>  
>   ex2:Pub a ex2:Category.
>   ex2:Adult ex2:Category.
>   ex2:Senior ex2:Category.
>  
> And my idea was: I add the oneof to the category class to indicate a 
> closed/fixed list (assume for the moment the example was on dogs where the 
> three allowed items are really all, no such thing as teen-dog ie. ).
>  
> I understand the owl-owa level reasoning issues. I am most interested in the 
> cwa-shacl interpretation.
>  
> Generatings shacl for above gives me:
>  
> ex2:Dog
>   rdf:type sh:NodeShape ;
>   sh:property [
>   rdf:type sh:PropertyShape ;
>   sh:path ex2:category ;
>   sh:class ex2:Category ;
>   sh:maxCount 1 ;
>   sh:minCount 1 ;
> ] ;
>  
> For Category I see however no shacl generated. So if I understand you right 
> there is no need too for data verification.
>  
> So…making a diff. for closed and open/extendable lists of allowed enumeration 
> items seems to have no effect on my actual shacl-cwa validation right?
>  
> Its just having a function on spec level I guess: with oneOf > closed 
> list….no oneOf of…open list. Or can I better leave the one of out here too? 
> (again the simpler/less the better…).
>  
> Thx again, 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>
> 
>  
>  <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.
>  
>  
>  
>  
> From: topbraid-users@googlegroups.com 
> <mailto:topbraid-users@googlegroups.com>  <mailto:topbraid-users@googlegroups.com>> On Behalf Of Irene Polikoff
> Sent: donderdag 1 november 2018 04:00
> To: topbraid-users@googlegroups.com <mailto:topbraid-users@googlegroups.com>
> Subject: Re: [topbraid-users] oneOf in shacl
>  
> Holger is correct. But additionally, this example calls for some reflection 
> on the goal of this modeling pattern - having owl:oneOf in the first place.
>  
> OWL is open world. This means that if you say the following:
>  
> ex2:Category
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf owl:Thing.
>   ex2:Pub a ex2:Category.
>   ex2:Adult ex2:Category.
>   ex2:Senior ex2:Category.
>  
> And, for example,
>  
> ex2:hasCategory rdfs:range ex2:Category.
>  
> And then
>  
> ex2:Asset1 ex2:hasCategory ex:Teen
>  
> There will be no inconsistency detected.
>  
> ex2:Teen will be inferred to be a ex2:Category, if you use an inference 
> engine.
>  
> Even if you use owl:oneOf as shown in your example below, there still would 
> still be no inconsistency since under the OWA, ex2:Teen could be the same as 
> either ex2:Pub,  ex2:Adult and  ex2:Senior. 
>  
> One possible way to get some checking/enforcing out of owl:oneOf would be if 
> your data always included owl:differentFrom assertions:
>  
> ex2:Teen owl:differentFrom ex2:Pub;
> owl:differentFrom ex2:Adult;
> owl:differentFrom ex2:Senior.
>  
> Such information, however, is rarely part of the data and you would need a DL 
> reasoner to detect this violation if data was present.
>  
> Or, another way to detect inconsistency would be if you had something like:
>  
> ex2:Teen a ex2:NotACategory.
> ex2:NotACategory.owl:disjointWith ex

RE: [topbraid-users] oneOf in shacl

2018-11-01 Thread 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
Hi Irene

Thx for your extensive feedback, much appreciated.

The situation I now have is the following:

I DO have both in:

ex2:Category
  rdf:type owl:Class ;
  rdf:type sh:NodeShape ;
  owl:oneOf (
  ex2:Pub
  ex2:Adult
  ex2:Senior
) ;

  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

And my idea was: I add the oneof to the category class to indicate a 
closed/fixed list (assume for the moment the example was on dogs where the 
three allowed items are really all, no such thing as teen-dog ie. ).

I understand the owl-owa level reasoning issues. I am most interested in the 
cwa-shacl interpretation.

Generatings shacl for above gives me:

ex2:Dog
  rdf:type sh:NodeShape ;
  sh:property [
  rdf:type sh:PropertyShape ;
  sh:path ex2:category ;
  sh:class ex2:Category ;
  sh:maxCount 1 ;
  sh:minCount 1 ;
] ;

For Category I see however no shacl generated. So if I understand you right 
there is no need too for data verification.

So…making a diff. for closed and open/extendable lists of allowed enumeration 
items seems to have no effect on my actual shacl-cwa validation right?

Its just having a function on spec level I guess: with oneOf > closed list….no 
oneOf of…open list. Or can I better leave the one of out here too? (again the 
simpler/less the better…).

Thx again, 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>



[cid:image001.gif@01D471C0.60E22580]<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.









From: topbraid-users@googlegroups.com  On 
Behalf Of Irene Polikoff
Sent: donderdag 1 november 2018 04:00
To: topbraid-users@googlegroups.com
Subject: Re: [topbraid-users] oneOf in shacl

Holger is correct. But additionally, this example calls for some reflection on 
the goal of this modeling pattern - having owl:oneOf in the first place.

OWL is open world. This means that if you say the following:

ex2:Category
  rdf:type owl:Class ;
  rdf:type sh:NodeShape ;
  rdfs:subClassOf owl:Thing.
  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

And, for example,

ex2:hasCategory rdfs:range ex2:Category.

And then

ex2:Asset1 ex2:hasCategory ex:Teen

There will be no inconsistency detected.

ex2:Teen will be inferred to be a ex2:Category, if you use an inference engine.

Even if you use owl:oneOf as shown in your example below, there still would 
still be no inconsistency since under the OWA, ex2:Teen could be the same as 
either ex2:Pub,  ex2:Adult and  ex2:Senior.

One possible way to get some checking/enforcing out of owl:oneOf would be if 
your data always included owl:differentFrom assertions:

ex2:Teen owl:differentFrom ex2:Pub;
owl:differentFrom ex2:Adult;
owl:differentFrom ex2:Senior.

Such information, however, is rarely part of the data and you would need a DL 
reasoner to detect this violation if data was present.

Or, another way to detect inconsistency would be if you had something like:

ex2:Teen a ex2:NotACategory.
ex2:NotACategory.owl:disjointWith ex2:Category.

But in this case inconsistency would be detected even if you did not use 
owl:oneOf since the inference would be that ex2:Teen is both a category and not 
a category and these classes are disjoint. So, oneOf does not buy you anything 
in this case.


With SHACL, you do not need to say sh:in on the Shape Node level. You can 
simply have:

  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

The range statement would be translated into the property shape with sh:class 
ex2:Category constraint.

And a statement {ex2:Asset1 ex2:hasCategory ex:Teen} will be reported as an 
issue.

With this, my personal preference would be to translate

ex2:Category
  owl:oneOf (
  ex2:Pub
  ex2:Adult
  ex2:Senior
) ;

Into

  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

Having said this, such decisions depend on the goals and intensions of the 
modeler.


On Oct 31, 2018, at 6:13 PM, Holger Knublauch 
mailto:hol...@topquadrant.com>> wrote:

Yes, sh:in at a node shape states that all target nodes (here: the instances of 
ex2:Category) must be one of the enumerated values.

Holger




On 1/11/2018 2:29 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:


ex2:Category
  rdf:

Re: [topbraid-users] oneOf in shacl

2018-10-31 Thread Irene Polikoff 
Holger is correct. But additionally, this example calls for some reflection on 
the goal of this modeling pattern - having owl:oneOf in the first place.

OWL is open world. This means that if you say the following:

ex2:Category
  rdf:type owl:Class ;
  rdf:type sh:NodeShape ;
  rdfs:subClassOf owl:Thing.
  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

And, for example,

ex2:hasCategory rdfs:range ex2:Category.

And then

ex2:Asset1 ex2:hasCategory ex:Teen

There will be no inconsistency detected.

ex2:Teen will be inferred to be a ex2:Category, if you use an inference engine.

Even if you use owl:oneOf as shown in your example below, there still would 
still be no inconsistency since under the OWA, ex2:Teen could be the same as 
either ex2:Pub,  ex2:Adult and  ex2:Senior. 

One possible way to get some checking/enforcing out of owl:oneOf would be if 
your data always included owl:differentFrom assertions:

ex2:Teen owl:differentFrom ex2:Pub;
owl:differentFrom ex2:Adult;
owl:differentFrom ex2:Senior.

Such information, however, is rarely part of the data and you would need a DL 
reasoner to detect this violation if data was present.

Or, another way to detect inconsistency would be if you had something like:

ex2:Teen a ex2:NotACategory.
ex2:NotACategory.owl:disjointWith ex2:Category.

But in this case inconsistency would be detected even if you did not use 
owl:oneOf since the inference would be that ex2:Teen is both a category and not 
a category and these classes are disjoint. So, oneOf does not buy you anything 
in this case.


With SHACL, you do not need to say sh:in on the Shape Node level. You can 
simply have:

  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

The range statement would be translated into the property shape with sh:class 
ex2:Category constraint.

And a statement {ex2:Asset1 ex2:hasCategory ex:Teen} will be reported as an 
issue.

With this, my personal preference would be to translate 

> ex2:Category
>   owl:oneOf (
>   ex2:Pub
>   ex2:Adult
>   ex2:Senior
> ) ;

Into

  ex2:Pub a ex2:Category.
  ex2:Adult ex2:Category.
  ex2:Senior ex2:Category.

Having said this, such decisions depend on the goals and intensions of the 
modeler.

> On Oct 31, 2018, at 6:13 PM, Holger Knublauch  wrote:
> 
> Yes, sh:in at a node shape states that all target nodes (here: the instances 
> of ex2:Category) must be one of the enumerated values.
> 
> Holger
> 
> 
> 
> 
> On 1/11/2018 2:29 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:
>>  
>> ex2:Category
>>   rdf:type owl:Class ;
>>   rdf:type sh:NodeShape ;
>>   rdfs:subClassOf owl:Thing ;
>>   owl:oneOf (
>>   ex2:Pub
>>   ex2:Adult
>>   ex2:Senior
>> ) ;
>> .
>>  
>> What would the shacl look like for the yellow part?
>>  
>>  
>> sh:in (ex2:Pub ex2:Adult ex2:Senior) ;
>>  
>> Somehow….but it is not in a property shape right?
>> thx
>>  
>>  
>>  
>>  
>> Dr. ir. H.M. (Michel) Böhms
>> Senior Data Scientist
>> 
>> T +31888663107
>> M +31630381220
>> E michel.bo...@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-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [topbraid-users] oneOf in shacl

2018-10-31 Thread Holger Knublauch 
Yes, sh:in at a node shape states that all target nodes (here: the 
instances of ex2:Category) must be one of the enumerated values.


Holger



On 1/11/2018 2:29 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:


ex2:Category

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

rdfs:subClassOf owl:Thing ;

owl:oneOf (

ex2:Pub

ex2:Adult

ex2:Senior

) ;

.

What would the shacl look like for the yellow part?

sh:in (ex2:Pub ex2:Adult ex2:Senior) ;

Somehow….but it is not in a property shape right?

thx



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



T +31888663107
M +31630381220
E michel.bo...@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-users+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.

[topbraid-users] oneOf in shacl

2018-10-31 Thread 'Bohms, H.M. (Michel)' via TopBraid Suite Users 

ex2:Category
  rdf:type owl:Class ;
  rdf:type sh:NodeShape ;
  rdfs:subClassOf owl:Thing ;
  owl:oneOf (
  ex2:Pub
  ex2:Adult
  ex2:Senior
) ;
.

What would the shacl look like for the yellow part?


sh:in (ex2:Pub ex2:Adult ex2:Senior) ;

Somehowbut it is not in a property shape right?
thx





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


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

Location



[cid:image001.gif@01D4713F.47022BF0]

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.
For more options, visit https://groups.google.com/d/optout.