Please see below. > On Oct 22, 2021, at 7:54 PM, Steve Ray <[email protected]> wrote: > > I now understand. > > On a related point, is it true that the only owl uses that persist in SHACL > implementations are the two relating to managing graphs: > > owl:imports (if you want to import other graphs), and
Yes, explicitly supported in SHACL e.g., https://www.w3.org/TR/shacl/#shapes-graph > X a owl:Ontology (if you want to name a graph so that you can do things like > imports)? Not really supported/required, but you can use it if you want. > > Do you endorse the use of owl property declarations, e.g. Y a > owl:ObjectProperty, etc., or do you recommend enforcing the implications of > those with SHACL shapes? If the latter, are there SHACL definitions for those? In general, we do not recommend the use of property declarations. SHACL will ignore them. However, if you wanted to, you could use them - as long as you understand that they have no meaning to SHACL. If you say: :PS a sh:PropertyShape; sh:path :p; sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode) You have effectively said that :p is used to connect two resources. If you know what class values of :p belong to, you could also say: :PS a sh:PropertyShape; sh:path :p; sh:class :C . This would also indicate that the property connects two resources, but it says more than that. Using both, sh:class constraint and sh:nodeKind sh:BlankNodeOrIRI is redundant. If you are not able to identify the class, you could say sh:class rdfs:Resource. Instead of owl:Datatype property, you would use sh:nodeKind sh:Literal or use sh:datatype constraint if you can be more specific and identify the datatype. This is not one to one to OWL since OWL distinguishes between the datatype and annotation properties because annotation properties are not used in DL reasoning. SHACL does not have this concept. Another difference is that OWL property type declarations are global. SHACL property shape definitions are specific to targets where a scope of a target could be quite limited. In principle, while a bad practice, it is possible to define two different property shapes with the same path but different targets and have one use sh:nodeKind sh:IRI and another sh:nodeKind sh:Literal. > > Steve > > > > > On Fri, Oct 22, 2021 at 4:12 PM Holger Knublauch <[email protected] > <mailto:[email protected]>> wrote: > > >> On 23 Oct 2021, at 3:50 am, Steve Ray <[email protected] >> <mailto:[email protected]>> wrote: >> >> Holger, >> >> Your final suggestion was the key! Who knew that we must declare owl:Class >> to be of type sh:NodeShape! >> I had a similar validation test for labelling all properties, and declaring >> rdf:Property as rdf:type sh:NodeShape fixed that one as well. >> Thank you so much for that subtle tip. If this is documented in the SHACL >> spec, I missed it. If it is not, I'll bet other people will bump into this >> problem. > > It’s mentioned here: https://www.w3.org/TR/shacl/#implicit-targetClass > <https://www.w3.org/TR/shacl/#implicit-targetClass> > > To validate instances of any class, either use sh:targetClass X or make X > rdf:type rdfs:Class AND rdf:type sh:NodeShape. > > Holger > > >> >> Steve >> >> >> >> >> On Thu, Oct 21, 2021 at 6:18 PM Holger Knublauch <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Steve, >> >> it SHOULD work, but TBC has two validation buttons and only the green one >> includes the classes and properties: >> >> <3HjnsEUcNN3NjWZm.png> >> >> On 2021-10-22 8:09 am, Steve Ray wrote: >>> I'm not understanding something about validating SHACL files. Normally I >>> successfully use shapes and SPARQLConstraints to validate rdf instance >>> files, but I'd also like to apply some constraints to our SHACL shape >>> definitions themselves. >>> >>> For example, I'd like to ensure all our declared classes/Nodeshapes have an >>> rdfs:label, so I wrote: >>> >>> owl:Class >>> sh:property [ >>> sh:path rdfs:label ; >>> sh:minCount 1 ; >>> ] ; >>> . >> On the above, please double-check that owl:Class rdf:type sh:NodeShape is >> also asserted. >> >> Holger >> >> >> >>> I also tried >>> 1. Writing a SPARQLConstraint to do the same thing. >>> 2. Using the sh:targetClass method with an explicitly named shape. >>> 3. Using these with sh:NodeShape instead of owl:Class, since all my classes >>> are also instances of sh:NodeShape. >>> >>> None produced any validation errors when I ran the TBC validator on a >>> shapes file containing the definition of a class where I intentionally >>> omitted an rdfs:label value. >>> >>> I know that the SHACL spec even has the shsh:ShapeShape specification, so I >>> assume this kind of thing can be done. Is something blocking the validation >>> error from showing up? Is it because rdfs:label is an annotation property? >>> >>> Steve >>> >>> >>> -- >>> 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 [email protected] >>> <mailto:[email protected]>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> >> >> -- >> 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 [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com >> >> <https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com?utm_medium=email&utm_source=footer>. >> >> -- >> 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 [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/CAGUep851gHoMy%2BVCgYnTTSfXG54aoy16O9HxkH0j3BrsjtUFRA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/topbraid-users/CAGUep851gHoMy%2BVCgYnTTSfXG54aoy16O9HxkH0j3BrsjtUFRA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/441BC0AB-3266-45AE-B94E-52906C004FAB%40topquadrant.com > > <https://groups.google.com/d/msgid/topbraid-users/441BC0AB-3266-45AE-B94E-52906C004FAB%40topquadrant.com?utm_medium=email&utm_source=footer>. > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/CAGUep84zfGuiY1cGyzpfY7ftv12wphNEY_N6pZc0pNociS0q2w%40mail.gmail.com > > <https://groups.google.com/d/msgid/topbraid-users/CAGUep84zfGuiY1cGyzpfY7ftv12wphNEY_N6pZc0pNociS0q2w%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/F4E1CA10-DE55-4375-8BDE-09E17D4FF4AC%40topquadrant.com.
