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]" > <[email protected]> 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/b8e034ce-b6c4-4d72-960b-92ef0bad5b11%40googlegroups.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/637D348C-066A-4CB4-88B0-080EAB1D2895%40topquadrant.com.
