shacl shape inheritance

[Maatary Okouya]

I have a quick question about the best way to express inheritance between pure shapes. 

E.g. 

:aShape a sh:nodeShape .

:bshape a sh:nodeShape .

Are the following 2 options equivalent, and which one is the reocmmended ? 

bShape rdfs:subClassOf aShape; 

or

bShape sh:node aShape ; 

The goal is to have bShape inherit the property of aShape.

Thanks

[Holger Knublauch]

sh:node is the right solution. subClassOf is only for classes, including for classes that are also shapes.

(Typo above - sh:NodeShape must have a big N)

Holger

Thanks

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
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/07c4c762-a4be-4617-9991-647907b3e235n%40googlegroups.com.

[Maatary Okouya]

thanks for clarifying.

[Maatary Okouya]

One extra clarification on this. 

Is it ok to actually mix both approach i.e. 

:aShape a owl:Class; a sh:NodeShape .

:bShape a sh:NodeShape;

:bShape sh:node aShape;

.

[Holger Knublauch]

Sure, the SHACL semantics should inherit constraints both ways. So all constraints at aShape will also apply to bShape.

But I have not seen this particular pattern in practice. Is this a real use case?

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/995f18bd-3789-491d-bc88-09d06e5050d0n%40googlegroups.com.

[Maatary Okouya]

Yes it is, as in i am trying my best to model a situation that is best described in https://www.linkedin.com/pulse/how-model-shared-local-data-viewpoints-using-shacl-irene-polikoff/

I would not say that the pattern apply 100 % there are some nuance here. 

One particular difference with the example is that

- in the example You clearly have the concept of US Person and UK Person and Person. 

- In our context we are dealing with the same concept just shaped differently according to the local view. The name of the concept does not change because it is literally the same thing, however in one context it is shape in a certain way, and in other it is shape in another way. 

So while my first approach would be to follow the recommended appraoch to subclass classes that are also nodeshape, it does not fill right. At the same time i am not confy all the way and fully break my class/nodeshape into class and node shape. hence the situation described in the previous email where i would have some high level class/nodeshape and then have shapes for the local views. 

Hope it make somewhat sense. 

Our domain is Biological network. The thing we are talking about are biological interaction e.g. ProteinModification, Regulation, GeneticChange and what not. 

[Maatary Okouya]

>> Sure, the SHACL semantics should inherit constraints both ways. So all constraints at aShape will also apply to bShape.

I tried it in EDG Studio, and the bShape disapear from the shapePanel. 

[Maatary Okouya]

Is that expected or a bug ?

[Maatary Okouya]

More importantly i think is, is there a workaround to make it show up in the Shape Panel ?

I have double check in the shacl playground that that modelling pattern works. I was able to validate things. 

However part of doing this models is to make it easily human readable as well, as much as machine processable. Hence would be nice to have it showing up in EDG. 

[Holger Knublauch]

I guess the problem with this pattern of mixing sh:node and rdfs:subClassOf is that the user interface doesn't expect it. The Node Shapes panel will only show as roots those node shapes that are not value of sh:node - otherwise they are expected to be part of the tree further down and are not roots. But if the root nodes are also classes they are hidden too, because they are not considered pure node shapes. The UI needs to make such choices and I don't consider this mix of design patterns as common enough to support it.

The usual pattern is something like

ex:Person

   a owl:Class, sh:NodeShape ;

That class is then used for the rdf:types.

ex:UKPerson

   a sh:NodeShape ;

   sh:targetClass ex:Person ;

Then, if you want to see the additional properties for UK people, you would switch the form to that "perspective".

If UKPerson is also an rdf:type then just make it a class and use rdfs:subClassOf Person. No need for node shapes then.

The sh:targetClass relationship will indirectly make sure that all constraints from Person will also apply to UKPerson.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9e9d94c3-ca66-4969-b1d1-ae511d24c46en%40googlegroups.com.

[Maatary Okouya]

Cristal Clear. 

Thanks. 

[Maatary Okouya]

To wrap this all around, what is the recommended way to share those shapes i.e. when writing the data, and the shapes are in their own ontology, as pure nodeshape, how do we link to it from the data such that the user can pull them. 

I mean in the scenario where, the class is a nodeshape there is no issue, it suffice to dereference the type of the entity or property through linked data principles. But with shapes in their own module i have no idea.

[Maatary Okouya]

I found out that some folks use dc:conformsTo or the original one sh:shapesGraph or validatedBy (which i have no idea which ontology it belongs to). 

I find it a bit brittle compared to the linked data appraoch, that everyone know i.e. lookup the class and find out about the shape at once. While things like conformsTo imply an indirection, beside do we add it to the dataset, or to each entity in the dataset and so forth ....

I wonder what's your experience with this. 

[Holger Knublauch]

I have never seen or used explicit "conforms-to" links in practice. In my experience the validation is almost always controlled by the declared rdf:types of an instance, which is then used by the shapes graph either through implicit class targets or sh:targetClass. If rdf:types are not sufficient then custom targets (e.g. in SPARQL) can be used https://w3c.github.io/shacl/shacl-af/#targets

(SHACL contains sh:targetNode is a way to link shapes with specific target nodes, but those triples need to stored in a shapes graph, not with the data).

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/696e132a-0c8f-44e5-ae22-743cc91e9b18n%40googlegroups.com.

[Maatary Okouya]

I understand what you wrote. However what i am talking about or focus on, is the other way around, not to link the shape to the data, but to link the data to the shapes. Essentially what i am after is a consistent easy link data experience which exist and work well in the non-shacl world. Meaning, when you look at data, and want to understand it, you can navigate to the ontology that defines it, through the linked data principle. You just need to lookup/dereference the properties or classes that are used in the data at hand. Or you can simply deferences the prefixes defined for that dataset. 

Now when it comes to the shacl era, shapes can reside in other modules when not combining sh:NodeShape and sh:Class, hence to help people fully understand the data, the shape of it must be accesible somehow. It need to be distributed and deference-able. Hence the need to used something like dc:comformsTo in your data to link to the shapes. Otherwise what would happen is someone would look up the class and properties in the ontology, but won't have access to the shapes that fully explain the dataset. 

[Holger Knublauch]

The DASH namespace contains the property dash:shape for this use case, linking instances to shapes, in the data graph.

dash:shape

  a rdf:Property ;

  rdfs:comment "States that a subject resource has a given shape. This property can, for example, be used to capture results of SHACL validation on static data." ;

  rdfs:label "shape" ;

  rdfs:range sh:Shape ;

.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/06610503-3bbc-471e-ada3-278f825afdb5n%40googlegroups.com.

[Maatary Okouya]

Nice, 

thanks