I agree. When I run the SHACL reasoner with the following code, I get all
the inverse triples.
s223:InversePropertyShape
a sh:NodeShape ;
sh:rule [
a sh:SPARQLRule ;
sh:construct """
CONSTRUCT {
?o ?invP $this .
}
WHERE {
$this ?p ?o .
?p s223:inverseOf ?invP .
}
""" ;
sh:prefixes <http://data.ashrae.org/standard223/1.0/inference/owl-subset> ;
] ;
sh:targetClass s223:Concept ;
.
Your point is well taken that we could do it your way without running the
reasoner, although we run it anyway for other inferences.
Steve
On Thu, Oct 28, 2021 at 12:18 PM Irene Polikoff <[email protected]>
wrote:
> In SHACL, you give a name to the inverse relation by creating a property
> shape with the inverse path. For example:
>
> skos:Concept-broader-inverse
> a sh:PropertyShape ;
> sh:path [
> sh:inversePath skos:broader ;
> ] ;
> sh:class skos:Concept ;
> sh:name "narrower concept" ;
> .
>
> This is the true notion of the inverse relation in a graph because it
> describes traversing a relationship in an opposite direction and it gives a
> name to the opposite direction.
>
> When you declare a separate URI for a property and say that it is an
> inverse e.g.,
>
> skos:narrower owl:inverseOf skos:broader.
>
> And then talk about triples that use the skos:narrower predicate, strictly
> speaking, you are not really talking about triples with the skos:broader
> relationship that exist in your graph - whether you traverse such triples
> in one direction or in another. At most, you are talking about skos:broader
> triples that would get generated from the skos:narrower should a reasoner
> be applied.
>
> On Oct 27, 2021, at 12:41 PM, Steve Ray <[email protected]> wrote:
>
> Yes, you are correct - I meant the use of owl:inverseOf, for which I infer
> the inverse triple. I agree with you about not needing this, but it seems
> some on the committee like being able to refer to the inverse relation by a
> more familiar relation name. I may try one more time to argue to eliminate
> our inverse properties.
>
> Regarding the owl:SymmetricProperty declaration, I plan to go ahead and
> replace it with a mynamespace:SymmetricProperty declaration, since I wrote
> the SHACL inference rule anyway. One less OWL element in the model.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch <[email protected]>
> wrote:
>
>>
>> On 2021-10-27 10:40 am, Steve Ray wrote:
>>
>> Thanks Holger and Irene for this perspective.
>>
>> Regarding properties, are you saying I should just declare all my
>> properties to be of type rdf:Property? I'm reluctant to just have them all
>> embedded inside property shapes, just for clarity.
>>
>> This is your choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff <[email protected]>
>> wrote:
>>
>>> 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]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 23 Oct 2021, at 3:50 am, Steve Ray <[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
>>>>
>>>> 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]> 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].
>>>>> 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].
>>>>> 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].
>>>> 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].
>>>> 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].
>>> 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
>>> <https://groups.google.com/d/msgid/topbraid-users/F4E1CA10-DE55-4375-8BDE-09E17D4FF4AC%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].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep85wifORPOZMHNPpDGSKzaNq94XkKnU3PJ4%2BwT5wRi5E%3Dg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85wifORPOZMHNPpDGSKzaNq94XkKnU3PJ4%2BwT5wRi5E%3Dg%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/11a62a4b-5b45-ca90-70b4-b1a217cbeaed%40topquadrant.com
>> <https://groups.google.com/d/msgid/topbraid-users/11a62a4b-5b45-ca90-70b4-b1a217cbeaed%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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep84WPfeun1WiW_z9QkTYD-WHzeywnVS_J8K_1XFyc25bxA%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep84WPfeun1WiW_z9QkTYD-WHzeywnVS_J8K_1XFyc25bxA%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/5A6EB7D4-97BD-452A-9835-10F252C0428D%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/5A6EB7D4-97BD-452A-9835-10F252C0428D%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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/CAGUep84CKR%2Bz10gHQ6zv%3DK3RbQ5%3Dow-vdkufrwpmOMvzCbj%2BaA%40mail.gmail.com.
