Chapter 9.4, Shape definitions

[RiittaA]

• Embedding PropertyShapes into NodeShapes may result in problems with reusability and a limitation of SHACL expressivity.
• There is no need to limit the use-cases of validation only to contexts where data is in tabular/relational form. Some PropertyShapes can be extremely reusable (for example a shape validating person's national identification number) in many contexts, and thus it is not justified that each application profile reimplements the same validation constraint, instead of using single nationally defined constraint that can be managed and updated in a centralised manner when needed (e.g. the ongoing NiN-update process in Finland).
• Our proposal is to treat PropertyShapes as having an identity and being easily reusable in multiple Nodeshapes in multiple application profiles.

[costezki]

Thank you, Rita, for the observation. We have relaxed the rule to allow for both cases.

When generating SHACL shapes, it is a good practice to create a node shape for each UML class and, within it a property shape for each UML attribute and UML Connector of that class. If the property shapes are defined within the node shapes (rather than freestanding), then we mirror the structure depicted in the UML diagrams. Doing so is intuitive for the readers, the resulting constraint definitions are organically integrated, and the maintenance costs are decreased. However, sometimes it may be useful to define the property shapes as stand alone, therefore reusable.

See https://semiceu.github.io/style-guide/public-review/gc-data-shape-conventions.html#sec:dsc-r4