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 On Monday, October 21, 2019 at 2:27:08 PM UTC-7, Irene Polikoff wrote: > > 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 > > > On Oct 21, 2019, at 4:53 PM, "[email protected] <javascript:>" < > [email protected] <javascript:>> wrote: > > 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. > > -- > 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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/b8e034ce-b6c4-4d72-960b-92ef0bad5b11%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/b8e034ce-b6c4-4d72-960b-92ef0bad5b11%40googlegroups.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/d7ae2d9c-b1e3-4b17-85d3-8f88ecbc10fd%40googlegroups.com.
