ISSUE-23: A specific proposal

In an attempt to make the discussion about ISSUE-23 [1] a bit more 
specific, I would like to suggest the following design. I have 
experimented with this design for a while and it appears to work nicely 
- both from an implementation perspective and user experience. My 
current draft [2] uses this design in its examples.

In this proposal, the base class is sh:Shape, which carries the system 
properties to define constraints, i.e. sh:constraint, sh:property and 
sh:inverseProperty. sh:Shape can be instantiated and used by itself. To 
instruct a SHACL engine, the property sh:nodeShape is used to link a 
resource with its sh:Shape(s) that it is supposed to have. This design 
pattern is especially suitable for people who want to avoid any 
conflicts between existing RDFS data models and constraint checking.

In the context of SHACL, rdfs:Class is declared as a rdfs:subClassOf 
sh:Shape, which means that any class can play the role of a Shape, and a 
Class can have constraints attached to it. Furthermore the rdf:type 
property is used by the SHACL engine to link instances with their class 
shapes, in the same way that sh:nodeShape is used. As a consequence, we 
have a natural implementation of specialization - rdfs:subClassOf is 
used to express sub-shape relationships.  This design pattern is 
especially suitable for people who want to naturally build upon the data 
models that already exist, and existing rdf:type triples.

I believe this design produces a very attractive user-facing syntax (no 
bloating extra triples) while maintaining a very good level of 
flexibility and backwards compatibility. Existing RDFS/OWL ontologies 
and their instances can be incrementally enhanced with SHACL constraints.

I would welcome specific, practice-oriented criticism of this design.

Thanks,
Holger

[1] http://www.w3.org/2014/data-shapes/track/issues/23
[2] http://w3c.github.io/data-shapes/shacl/

Received on Thursday, 23 April 2015 23:20:26 UTC