Validating owl:Classes or sh:NodeShapes

[Steve Ray]

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 ;

] ;

.

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

[Holger Knublauch]

Hi Steve,

it SHOULD work, but TBC has two validation buttons and only the green one includes the classes and properties:

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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com.

[Steve Ray]

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.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com.

[Holger Knublauch]

On 23 Oct 2021, at 3:50 am, Steve Ray <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> wrote:

Hi Steve,

it SHOULD work, but TBC has two validation buttons and only the green one includes the classes and properties:

<3HjnsEUcNN3NjWZm.png>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep851gHoMy%2BVCgYnTTSfXG54aoy16O9HxkH0j3BrsjtUFRA%40mail.gmail.com.

[Steve Ray]

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

X a owl:Ontology (if you want to name a graph so that you can do things like imports)?

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?

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/441BC0AB-3266-45AE-B94E-52906C004FAB%40topquadrant.com.

[Holger Knublauch]

On 2021-10-23 9:54 am, Steve Ray 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

This is the only use of OWL vocabulary in SHACL - for resolving owl:imports and sh:prefix declarations.

X a owl:Ontology (if you want to name a graph so that you can do things like imports)?

This type triple is not necessary. You only need to use a URI that is equivalent to the named graph, e.g.

<http://example.org/myShapesGraph> owl:imports <http://datashapes.org/dash>

is sufficient. The owl:Ontology type is typically given though as a helpful annotation, e.g. to inform form builders.

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?

There is no need for owl:ObjectProperty or any other global property triples, but they don't do harm either. A pure SHACL implementation takes a rather object-oriented worldview where all property declarations are attached to classes/shapes, and do not really live on their own.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep84zfGuiY1cGyzpfY7ftv12wphNEY_N6pZc0pNociS0q2w%40mail.gmail.com.

[Irene Polikoff]

Please see below.

On Oct 22, 2021, at 7:54 PM, Steve Ray <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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep84zfGuiY1cGyzpfY7ftv12wphNEY_N6pZc0pNociS0q2w%40mail.gmail.com.

[Steve Ray]

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.

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?

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/F4E1CA10-DE55-4375-8BDE-09E17D4FF4AC%40topquadrant.com.

[Holger Knublauch]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep85wifORPOZMHNPpDGSKzaNq94XkKnU3PJ4%2BwT5wRi5E%3Dg%40mail.gmail.com.

[Steve Ray]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/11a62a4b-5b45-ca90-70b4-b1a217cbeaed%40topquadrant.com.

[Steve Ray]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/11a62a4b-5b45-ca90-70b4-b1a217cbeaed%40topquadrant.com.

[David Price]

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> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep85%3DV-uMyv7AarX%3D0TPFDqeKA4bZ%2Bc7LN_6HnAFvVh2N9g%40mail.gmail.com.

[Bohms, H.M. (Michel)]

 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>:

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D4356C60-0BE5-4B7F-BA49-51BF365F1BD0%40topquadrant.com.

 

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.

[Irene Polikoff]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep84WPfeun1WiW_z9QkTYD-WHzeywnVS_J8K_1XFyc25bxA%40mail.gmail.com.

[Irene Polikoff]

myNamespace:MyRootClass  

  rdf:type rdfs:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Resource ;

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep85%3DV-uMyv7AarX%3D0TPFDqeKA4bZ%2Bc7LN_6HnAFvVh2N9g%40mail.gmail.com.

[Steve Ray]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/5A6EB7D4-97BD-452A-9835-10F252C0428D%40topquadrant.com.

[Steve Ray]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/eb2b6be1-f9c3-4539-b006-9d1da7fff7df%40email.android.com.

[Bohms, H.M. (Michel)]

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>:

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep84DR0513sFvMO2QWnwP8v132%3DVyiFz1TQ4uqMxW6Mxdmw%40mail.gmail.com.

[Steve Ray]

Michel,

It helped in the following specific case where I don't need to include a "$this a/rdfs:subClassOf <myroot class>" statement. All my defined classes are instances of s223:Class. All the imported classes from various other ontologies are not.

s223:Class

sh:property [

sh:path rdfs:label ;

sh:sparql [

a sh:SPARQLConstraint ;

sh:message "{$this} must have an rdfs:label" ;

sh:prefixes <http://data.ashrae.org/standard223/1.0/validation/schema> ;

sh:select """

SELECT $this

WHERE {

FILTER (NOT EXISTS {$this rdfs:label ?something}) .

}

""" ;

] ;

] ;

.

Steve

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

[Steve Ray]

I'm not sure I fully understand why, but I changed my root class to be a subClass of rdfs:Resource instead of rdfs:Class as you suggested, and the odd behavior of all my instances suddenly being inferred to be subClasses of rdfs:Resource went away. So thank you.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/EB31B941-9D83-4CA3-8FA8-5D091902D078%40topquadrant.com.

[Bohms, H.M. (Michel)]

Ok see your point.

Then name “Class” is misleading.

It’s a meta class that can better have a more specific name like “MyClass” or MyDefinedClass or LocalClass ..etc.

 

In my cen standard we have a similar “ConceptType” metaclass that can be used for that.

 

Slight diff.: classification towards that class is optional in my case where it might be always classified (for all your defined classes) in your case.

 

Greetings Michel

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep85WtpyZ2u_CT2q%3DC6OXcrn6ThZRqHAfs6Yf0cy9wjJ-WA%40mail.gmail.com.