Dear Irene, see below after >




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@01D4722D.8DA91430]<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 <topbraid-users@googlegroups.com> On 
Behalf Of Irene Polikoff
Sent: donderdag 1 november 2018 20:00
To: topbraid-users@googlegroups.com
Subject: Re: [topbraid-users] general shacl question

Michel,

RDFS+OWL offer users ability to define a large number of model patterns. In 
developing a translator, we did not have a goal to covert all possible 
patterns. This would have been quite hard and require a lot of effort. Instead, 
our goal was to help bootstrap moving to SHACL by covering roughly 80% of what 
a model may contain.

> of course I appreciate that. My statement was not in general but only on the 
> specifics dealing with rdfs:range conversion (I thought this would be clear 
> from my message). Anyway, please be assured I fully appreciate your 80% as it 
> is! So to be fully clear: I think your shacl conversion stuff is great. 
> Especially the way you do it via transparent  shacl is brilliant and a fine 
> showcase for its power!


We started by identifying ontologies to test the conversion with. One of these 
ontologies was FIBO (as described in the blog a gave a link to) and there were 
a few others. Quite likely these models did not have this particular pattern. 
Further, in some cases, there could be more than one way of 
interpreting/translating/mapping statements from the source ontology into SHACL 
shapes.

> of course I hope(d) that this rdfs:range as IMHO not-so-very-particular 
> pattern would be part of the 80% 😊


So, no. The converter is not complete. If it does not cover some common 
patterns in the ontologies you need to convert, then you can add a rule 
yourself by following the example. Some axioms/modeling styles can be very 
complex making it hard to create a general rule. The would then need to be 
dealt with in the case by case basis.

> see above (I never said something on completeness in a general sense). So 
> perfectly ok.
> and no, I have no intention to write rules myself! I am perfectly happy to 
> wait for your extensions that are then used consistently by all!


Your example is not complex to convert. Sometimes, a parent property may have 
no domain statement because it is there simply to support rdfs:subPropertyOf 
reasoning. It would then have child properties that declare a domain. IN any 
case, I see no harm in translating it the way you have suggested. One issue may 
be in figuring out convention for the URI of the newly generated property 
shapes. Converted is using <class local name>-<property local name> pattern for 
the property shapes that are resources. In this case, another convention is 
needed.

> yep, it would face the same naming convention issue as I would do it manually 
> myself indeed.


With respect to your question of generating global property shapes even when a 
domain statement exists, this would not be the most accurate translation. 
Domain statement says that all subjects of triples with the predicate equal to 
the property must be members of the domain class. Thus, there could not be :R 
:p :V where :p rdfs:domain :C and :R is not a SHACL instance of :C.

>true, but that was not my point. My point is that :R can still be an instance 
>of (also) another class (if my interpretation of rdfs:domain semantics is 
>right). And the range would then also be relevant for these other classes! And 
>this can only be done if the (global) range gets a global CWA/shacle 
>counterpart! And if not, the class specific variants will always be 
>‘incomplete’ (THAT was the specific potential incompleteness I was referring 
>too). But I am happy if you prove me wrong here! 😊

Formulated otherwise: my idea: a global owa constraint needs a global cwa 
constraint, kind of law of conservation of globalness 😊

Greetings, Michel



On Nov 1, 2018, at 2:38 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> wrote:

Thx all clear..i will define the range only stuff manually

One question still....arent the ranges for properties having a domain also not 
best treated with a separate global shacle shape? Since those ranges not only 
hold for the class at the domain but for all classes?
Said otherwise...is your current converter conplete?
So what about in the future only generating global property shapes for all 
ranges..with or without domain...in favour of the current shacl for the domain 
classes?

Or am i now wrongly interpreting domain semantics? My assump. Is that a domain 
clause says nothing about nondomain classes having the property....

Gr m

Verzonden van mijn Android-telefoon via TouchDown 
(www.symantec.com<http://www.symantec.com>)

-----Original Message-----
From: Irene Polikoff [ir...@topquadrant.com<mailto:ir...@topquadrant.com>]
Received: donderdag, 01 nov. 2018, 17:58
To: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com> 
[topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>]
Subject: Re: [topbraid-users] general shacl question
Domains and ranges are transformed into Property Shapes as follows:

rdfs:domain statements are converted to property shapes connected to the 
classes that are objects in {?property rdfs:domain ?object} statements. Classes 
will get a rdf:type sh:NodeShape triple. If there is a rdfs:range statement for 
the property, resulting shapes will have either sh:class or sh:datatype 
constraint components that correspond to the range.

Thus, if a property does not have a domain statement, but has a range 
statement, there will be no property shape generated. I can see how it would 
make a sense in this case to generate a property shape with a 
sh:targetSubjectsOf target, but it is not done at the moment.

You can see the details on what is being converted here 
https://www.topquadrant.com/2018/05/01/from-owl-to-shacl-in-an-automated-way/.

The file that contains conversion rules is available in the TopBraid/SHACL 
project.



On Nov 1, 2018, at 12:43 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> wrote:

Hi David,

Wrt “Don’t understand what “global” or “cwa” have to do with it but …”, I’ll 
try to be more precise (please tell me if I am wrong)

With owa I meant OWL/RDFS open world interpretation
With cwa I meant SHACL closed world interpretation

In OWA/OWL we have two kinds of restrictions: 1) for a class (I call them 
local) and 2) for a property (I call them global).
Global ones are the universal ones: the hold for a property where ever they are 
applied in what ever class context.
So
- local > owl restrictions for classes
- global> o.a. rdfs domain/ranges for properties (datatype or object properties)

So I understand now that domain/ranges are not transformed into shacl 
PropertyShapes.
They are only taken into account when their properties feature in a local owl 
restriction for a class resulting in local shapes in the context of a NodeShape 
for that class.

We see quite some use cases where properties have no domain (to keep them 
flexibly applicable) and are also not constrained for specific classes. In 
these situations we still want to have cwa shacl code to check the data aginst 
their range (datatype or class). But ok that is quite a different discussion 
topic.

Gr 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


<image001.gif>
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> 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> On 
Behalf Of dprice
Sent: donderdag 1 november 2018 17:17
To: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>
Subject: Re: [topbraid-users] general shacl question


On 1 Nov 2018, at 14:42, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> wrote:

Ok, so global cwa shapes are not (?yet) generated, thx

Don’t understand what “global” or “cwa” have to do with it but …

OWL Object and Datatype properties without an rdfs:domain and not mentioned in 
a restriction on a class do not result in property shapes as part of the 
OWL-to-SHACL rules.

The owl2shacl generation was implemented using rules, found in 
TopBraid/SHACL/owl2shacl.ttl,  so that it could be modified and/or extended or 
replaced by customers as they see fit. There may not be a one-size-fits all 
approach to the OWL to SHACL language conversion. The coverage of the current 
rules is explained on our Web site:

https://www.topquadrant.com/2018/05/01/from-owl-to-shacl-in-an-automated-way/

Properties with no related class are typically only created in generic, high 
level ontologies that are reused in more specific ontologies where they appear 
in restrictions. In that situation, the SHACL should be generated from those 
more specific ontologies, not the generic, high level ones. There’s a similar 
issue with range-less properties, which OWL also allows.

Cheers,
David




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


<image001.gif>
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> 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> On 
Behalf Of dprice
Sent: donderdag 1 november 2018 15:11
To: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>
Subject: Re: [topbraid-users] general shacl question





On 1 Nov 2018, at 13:54, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> wrote:


Ok, thx

I think I have to reformulate my issue then.

Is there any global PropertyShape generation at the moment?
Ie property shapes not in context of a NodeShape.

Just tested this in Composer 6.0.0 by making an OWL object and OWL datatype 
property with no domains and no OWL classes in the graph. I don’t see anything 
referencing the two properties after running inferences.


Ie when I have no class restrictions but only property restrictions like domain 
and range.
Are these now generated by the shacl-convertor?

Example

Generated:

  sh:property [
      rdf:type sh:PropertyShape ;
      sh:path ex2:name ;
      sh:datatype xsd:string ;
      sh:maxCount 1 ;
      sh:minCount 1 ;
    ] ;

For ex2:Dog only.

But is there also a global:

  Ex2:NameShape
      rdf:type sh:PropertyShape ;
      sh:tagetsSubjectsOf ex2:name ;
      sh:datatype xsd:string ;
    ] ;

Generated?
That can be used validating values for names for all classes…

If yes, where could I find it (do not see it as instance of PropertyShape
If no, is that something to do manually? Could it be in the converter in 
principle?

You can make additional rules if you want, to generate anything you want. You 
can also modify owl2shacl yourself if you want to include your new rules, to 
delete existing rules, etc.

Cheers,
David











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


<image001.gif>
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> 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> On 
Behalf Of dprice
Sent: donderdag 1 november 2018 14:33
To: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>
Subject: Re: [topbraid-users] general shacl question






On 1 Nov 2018, at 12:02, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> wrote:

I saw:

owl2shacl:rdfsRange2shClassOrDatatype
  rdf:type sh:SPARQLRule ;
  rdfs:comment "For each relevant property that has an rdfs:range, create 
sh:class or sh:datatype constraint unless it already exists (from a 
restriction)." ;


That means if sh:class or sh:datatype are already set in the property shape, 
don’t duplicate the statement. That’s what this does:

FILTER NOT EXISTS { ?propertyShape sh:class|sh:datatype ?any } .







this triggers some questions for me:

suppose the property is restricted for some specific class…shouldn’t it then be 
still generated (as propertyshape) for other classes? (for say instance 
verification for other classes where it might be used but where it is not 
restricted)?

And

How does this relate to a domain  spec?

The rule is against NodeShape, no matter how the NodeShape got there so not 
really related to the logic wrt rdfs:domain.




I thought that in case of a domain spec nodeshape info is generated too (like 
the more general hasPart examples earlier?). Are they then generated or not 
(could not find them so quickly after generation). An if that is the case, 
shouldn’t it say “(from a restriction or domain)” iso of just “(from a 
restriction)”?

The “from a restriction” is not actually involved in the rule logic. It’s just 
a suggestion to the reader about how there might already be a 
sh:class/sh:datatype for the property shape already related to the NodeShape in 
question. That said, I don’t see any rule generating sh:class from an 
rdfs:domain so the comment is likely accurate.

Cheers,
David





thx

ps guess it has to do with

unless it already exists (from a restriction)."

Meaning in a separate propertyshape…not within a nodeshape (anonymous)

In hat case I have another question: generating shacl with explicit property 
shapes (option) seems to give more functionality that only in context class, 
right? (also giving validation options for classes not restricting)



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


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

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>.
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<mailto:topbraid-users+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

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>.
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<mailto:topbraid-users+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

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>.
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<mailto: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<mailto: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<mailto: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<mailto: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.

Reply via email to