If you are creating or modifying ontologies with TopBraid EDG, you have probably noticed that every new class you create is also a Node Shape.
You may also noted that there is a separate panel called Node Shapes and classes do not show up on it even if they are Node Shapes. So, what is the story, you may wonder – should I use classes as Node Shapes, should I create Node Shapes that are not classes? We will try to answer these questions in this blog.
Are Classes the same as Node Shapes?
In TopBraid EDG classes are always Node Shapes – if you are planning to work with instance data. This is because instance data needs shape definitions.
If you will never have any instances of classes in EDG, then you can leave then just as classes. But this would be fairly unusual.
Are Node Shapes the same as Classes?
No, Node Shapes are broader than classes. In other words, some Node Shapes are also classes and some are not. If a Node Shape is a class, then it can have class members – because it is a class. For example
ex:Person a owl:Class.
ex:Person a sh:NodeShape.
Now you can have instances of the Person class and they can have properties described by the Property Shapes associated with ex:Person. See a blog about Property Shapes and Properties.
You can also have Node Shapes that are not classes. In this case, they can’t have instances. But they can target classes and this means that they are describing instances of a class they target. For example:
ex:Person a owl:Class.
ex:PersonShape a sh:NodeShape.
ex:PersonShape sh:targetClass ex:Person.
When should you use this pattern as opposed to the first one? Rarely, if ever.
Remember that in EDG, classes are also Node Shapes, so ex:Person will be a Node Shape and it will have property definitions. It does not make sense to create a separate Node Shape that will be identical to ex:Person and will simply compete with it.
Are targets then not useful? Yes, they are – for advanced users.
sh:targetClass is rarely used – unless one wants to fully separate classes and Node Shapes and use classes that are not Node Shapes. But then, you will not be able to work with instances in EDG – create them, update them, etc. You will be able to validate their information, but this is all.
There are several other target statements and options that are more commonly used – for cases when you need to provide shape information about resources that can’t be identified simply as instances of a class – because there is no class that contains all and only resources you want to target.
Keep in mind though that explicit targets are advanced features intended for users that have considerable experience in modeling with SHACL. As you get started, you will be able to accomplish a lot by simply using classes that are also Node Shapes. This is called an implicit target – there is no target statement, but by making a class a Node Shape, it is understood that the shape is targeting instances of the class.
When should one create Node Shapes that are not classes?
One common use case is to provide alternative views into data. Properties shapes defined for a class typically define a full complement of properties that may be used for instances of a class. Different users (including applications) may need different views on data. For example, for a user who is a subject matter expert, you may want to have a view on a data assets that has:
–a smaller number of properties than those available to a data steward
–some additional properties with values derived by rules
To accomplish this, use the Node Shapes panel to create a Node Shape. Note that this panel will ONLY display Node Shapes that are not classes. Otherwise, it would show too many Node Shapes. You will see some pre-built Node Shapes in the panel. They are used internally by TopBraid EDG.
When you create a new Node Shape, you can use Modify>Clone property shapes from… to copy some of the Property Shapes. Typically, you will copy a subset of Property Shapes from the class.
Your next step will be connect your new Node Shape to the class. This is best done by using “applicable for class” property. Screenshot below shows Employee Node Shape that defines an alternative view into members of the class Person. It also sets this view as a default for users in the data consumer role.
Now, if we look at data for a specific person, we will get two views. Employee View, shown in the next screenshot, will be the default view for people in a data consumer role.
A complete Person view shows a number of additional property values that are not included in the Employee View – as highlighted in the next screenshot.
Any system accessing data in TopBraid EDG via GraphQL APIs can now query EmployeeView object to get just the properties defined.
While systems accessing Person object have access to all the properties – a subset of which is shown in the screenshot below.
Let us know if you want to see a blog on using Node Shapes for more advanced, non-class targets, e.g., sh:subjectsOf!