Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

'Bohms, H.M. (Michel)' via TopBraid Suite Users Thu, 28 Oct 2021 13:00:16 -0700

I do understand that an own generic rootclass can help but not how an own "owl 
class" can support that.....

Op 28 okt. 2021 21:53 schreef Steve Ray <st...@steveray.com>:
Michel,
I was doing it similar to what you suggest, but making our own version of
owl:Class made it slightly easier to collect all the locally defined classes
for validation/inferencing. Don't have to have

a/rdfs:subClassOf* in my queries when validating all our defined classes. I
suppose it's a style/judgment call.

Steve

On Thu, Oct 28, 2021 at 11:59 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users <topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>>
wrote:
Cant see why you would need an owndefined owlclass in your no owl rdfs........

Just type your random classes as rdfs class and subclass them wrt your
rootclass itself also of type rdfs class.

Op 28 okt. 2021 20:49 schreef David Price
<dpr...@topquadrant.com<mailto:dpr...@topquadrant.com>>:
Hi Steve

Rdfs subclass is between RDFS Class as a set theory relation (all Sub are
Super) and type is from RDF to define set membership (Ind is a member of Sub)

Cheers,
David

On 28 Oct 2021, at 19:33, Steve Ray
<st...@steveray.com<mailto:st...@steveray.com>> wrote:

One last(?) guidance request.
Previously, I had been declaring classes as:

ex:MyRandomClass

rdf:type owl:Class ;

rdf:type sh:NodeShape ;

rdfs:subClassOf owl:Thing ;

...

Normally, I define a root class in my ontologies, and all my other classes are
subclasses of that:

myNamespace:MyRootClass

rdf:type owl:Class ;

rdf:type sh:NodeShape ;

rdfs:subClassOf owl:Thing ;

So in my no-OWL migration, I have defined my own non-OWL version of owl:Class:

myNamespace:Class

rdf:type rdfs:Class ;

rdf:type sh:NodeShape ;

rdfs:subClassOf rdfs:Class ;

so my random classes would be:

ex:MyRandomClass

rdf:type myNamespace:Class ;

rdf:type sh:NodeShape ;

rdfs:subClassOf myNamespace:MyRootClass ;

so should my new root class be:

myNamespace:MyRootClass

rdf:type myNamespace:Class ;

rdf:type sh:NodeShape ;

rdfs:subClassOf rdfs:Class ;

or should it be:

myNamespace:MyRootClass

rdf:type myNamespace:Class ;

rdf:type sh:NodeShape ;

rdfs:subClassOf rdfs:Resource ;

...I'm starting to confuse myself about things being a subClassOf something and
being an rdf:type of something else. (I think I was absent during that session
of semantic web 101!)
I'm thinking the first one, but does the SHACL/rdf world even need both a type
and a subClass?
I realize that SHACL will just ignore the OWL stuff, but I'd like to go ahead
and not have it there to avoid confusion.

Steve

On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch
<hol...@topquadrant.com<mailto:hol...@topquadrant.com>> 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
<ir...@topquadrant.com<mailto:ir...@topquadrant.com>> wrote:
Please see below.

On Oct 22, 2021, at 7:54 PM, Steve Ray
<st...@steveray.com<mailto:st...@steveray.com>> 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
<hol...@topquadrant.com<mailto:hol...@topquadrant.com>> wrote:

On 23 Oct 2021, at 3:50 am, Steve Ray
<st...@steveray.com<mailto:st...@steveray.com>> 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
<hol...@topquadrant.com<mailto:hol...@topquadrant.com>> 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
topbraid-users+unsubscr...@googlegroups.com<mailto:topbraid-users+unsubscr...@googlegroups.com>.
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
topbraid-users+unsubscr...@googlegroups.com<mailto:topbraid-users+unsubscr...@googlegroups.com>.
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>.

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/9b6a7357-afd4-4918-b00a-c34c4b334323%40email.android.com.

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Reply via email to