SHACL modeling question

[cbur...@healthwise.org]

I'm hoping to get some help in modeling some node shapes and property shapes around a particular set of user needs. (This is in EDG 6.2.4.)

A simplified version of my scenario is this:

• ex:SubClassA, ex:SubClassB, and ex:SubClassC are all subclasses of ex:SuperClass. All of these are owl:Classes and also sh:NodeShapes.
• ex:property is an owl:ObjectProperty with an rdfs:domain of ex:SuperClass, although in reality it is applicable only to ex:SubClassA and ex:SubClassB, and NOT to ex:SubClassC.
• I have defined a property shape for ex:property on ex:SuperClass, in order to establish some display settings and some constraints on permissible values and cardinality.

My question is: How would I prohibit ex:property from appearing on Edit or Search forms for instances of ex:SubClassC, while still allowing users to use ex:property in searching for instances of ex:SuperClass? (For what it's worth, ex:SuperClass has no direct instances; only its subclasses do.)

It seems to me that the best solution here would be to add a restriction to the property shape for ex:property, specifying that subjects of it must NOT be instances of ex:SubClassC, but I'm not sure how to do that because constraint expressions on property shapes generally constrain the value nodes, rather than the focus nodes. Does my approach even make sense, or is there a better way to do it? Thanks.

[Irene Polikoff]

Hi Carl,

If you specify property constraints for a class, they apply to all its instances - direct or indirect through subclasses.

If you want to use a property only with instances of A and B and not with C, then specify it for A and B only instead of using superclass common with C.

OWL restrictions work the same way. They apply to all instances. Thus, you can’t override them in the subclasses. You can put additional restrictions/constraints for subclasses but not negate the one for the parent.

By contrast, RDFS domains have very different semantics. They do not constrain anything. They simply infer based on property values that an instance is a member of a class. They are not meant to say that property values should exist or be of certain kind, but only that if they do, then an inference can be made about resource’s type. Thus, saying that a property has Superclass in its domain, does not commit you to instances of any given subclass having these values. 

For example, you could have an Organization, with subclasses Government Agency, Commercial Organization. Then, hasCEO rdfs:domain:Organization. This means that if you see a resource of unknown type with CEO, you can infer that it is an organization. You would not be able to classify it more specifically with respect of the organization sub type.  Nor does it imply that members of Organization subclasses would have CEOs.

Tools would typically put a slot on a form for this property for the class in the domain and all subclasses. This is done by convention, for convenience, etc. but RDFS is not a traditional schema language.

Regards,

Irene

--
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/b8e034ce-b6c4-4d72-960b-92ef0bad5b11%40googlegroups.com.

[cbur...@healthwise.org]

Irene, thanks for the quick reply.

I should have anticipated this response! I am aware that constraints made on a superclass must apply to all subclasses. On reflection, I don't really want to place any constraints on ex:property at ex:SuperClass at all. Instead, I'm searching for a way of saying that:

1. ex:property may be used with ex:Superclass, and

2. if it is used that way, its subject must conform to a given shape (namely, the union of ex:SubClassA and ex:SubClassB)

I certainly could take your approach of creating a new property shape for each subclass for which ex:property is applicable. But there are two problems with this approach:

1. In reality, my model is much more complex than in my example, so I would need to create many more than two new property shapes. Would it be possible for me to create a new sh:NodeShape (which is NOT a class) representing the union of all the classes that constitute the domain of ex:property, and then apply a single property shape to that?

2. More importantly: I still want to give my users the ability to search by ex:property across all subclasses of ex:SuperProperty at once. (In my data, probably 95% of the instances of ex:SuperClass belong to a subclass that allows -- in fact, requires -- this property).) In the old SWA forms, this was easy to do by adding a property to the search form for a class, even if the property was not universally applicable to that class. But I am not sure whether it is possible to do that with the SHACL-based forms. Is it?

thanks,

Carl

Hi Carl,

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[Irene Polikoff]

Please see below 

On Oct 21, 2019, at 3:48 PM, "cbur...@healthwise.org" <cbur...@healthwise.org> wrote:

Irene, thanks for the quick reply.

I should have anticipated this response! I am aware that constraints made on a superclass must apply to all subclasses. On reflection, I don't really want to place any constraints on ex:property at ex:SuperClass at all. Instead, I'm searching for a way of saying that:

1. ex:property may be used with ex:Superclass, and

If it may be used with the superclass, then do not set the minCount. Then, it will be optional.

2. if it is used that way, its subject must conform to a given shape (namely, the union of ex:SubClassA and ex:SubClassB)

Yes, you can certainly define this in a shape.

You will then see the property slot for all instances of the superclass (transitively), but if you enter a value for a resource that is not in either A or B, you will get a violation.

I certainly could take your approach of creating a new property shape for each subclass for which ex:property is applicable. But there are two problems with this approach:

1. In reality, my model is much more complex than in my example, so I would need to create many more than two new property shapes. Would it be possible for me to create a new sh:NodeShape (which is NOT a class) representing the union of all the classes that constitute the domain of ex:property, and then apply a single property shape to that?

You can create a node shape and have 2 values in the class target - A and B.

This will result in a form having a drop down for an alternative view e.g., shape X view. It will have the field you defined. The other view (based on the class) will not. 

There can be an unlimited number of alternative views - see the example below.

View 1 

View 2 

2. More importantly: I still want to give my users the ability to search by ex:property across all subclasses of ex:SuperProperty at once. (In my data, probably 95% of the instances of ex:SuperClass belong to a subclass that allows -- in fact, requires -- this property).) In the old SWA forms, this was easy to do by adding a property to the search form for a class, even if the property was not universally applicable to that class. But I am not sure whether it is possible to do that with the SHACL-based forms. Is it?

Yes, I heard a similar requirement from others. 

In the first option I described this would be the case, but you will also see the property in the edit form.

Let's see if Holger has other ideas.

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/d7ae2d9c-b1e3-4b17-85d3-8f88ecbc10fd%40googlegroups.com.