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.
