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. 

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.

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. 

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.

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.

> On Nov 1, 2018, at 2:38 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
> <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)
> 
> -----Original Message----- 
> From: Irene Polikoff [ir...@topquadrant.com]
> Received: donderdag, 01 nov. 2018, 17:58
> To: topbraid-users@googlegroups.com [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/ 
> <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 <topbraid-users@googlegroups.com> On 
>> Behalf Of dprice
>> Sent: donderdag 1 november 2018 17:17
>> To: 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> 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
>> 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 <topbraid-users@googlegroups.com> On 
>> Behalf Of dprice
>> Sent: donderdag 1 november 2018 15:11
>> To: 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> 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
>> 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 <topbraid-users@googlegroups.com> On 
>> Behalf Of dprice
>> Sent: donderdag 1 november 2018 14:33
>> To: 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> 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
>> 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.
>> 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.
>> 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.
>>  
>> 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.
>> 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.
>>  
>> 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.
>> 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 
> <mailto:topbraid-users+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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 
> <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