define sh:ReferenceShape, sh:SimpleShape to be able to limit validation effort

[VladimirAlexiev]

• add targetShape #213 describes how in Ontotext GraphDB we use two shapes per "business class": Reference vs Full
• in SHACL's Own Profiles #216 (comment) @mielvds asks for "a profile for data modeling & not necessarily for validation"

In this issue I'd like to focus on this question:

What are the SHACL features needed for modeling, and which are amenable to easier validation?
The "20% features used in 80% of cases"?

I'll write my idea in turtle, but:

• There can be various ways to limit features to achieve constant time, so we should discuss the limitations.
• The currently listed limitations need to be updated when we add more features, in particular Node Expressions
• I don't have any sort of mathematical proof that limitations (skos:scopeNote) ensure the desired outcome (rdfs:comment)
• I may have missed limitations
• Parts of the descriptions should go into a new spec section

sh:ReferenceShape a rdf:Class; rdfs:subClassOf sh:NodeShape;
  rdfs:label "Reference shape";
  rdfs:comment "A node shape that can be validated in constant time regardless of the size of the data graph";
  skos:scopeNote """A reference shape should not use:
- sh:node
- sh:property over multi-valued properties
- sh:path with anything but a simple property or sh:inversePath
- SPARQL constraints""",
    """If a NodeShape is asserted to be a ReferenceShape then 
the SHACL processor must check the limitations and raise an error if they are not satisfied""",
    """If a NodeShape matches the limitations then 
it can be asserted internally by the SHACL processor as a ReferenceShape, which can help with checking shapes that use it""".

sh:SimpleShape a rdf:Class; rdfs:subClassOf sh:NodeShape;
  rdfs:label "Simple shape";
  rdfs:comment "A node shape that can be validated in linear time with respect to the size of the node's neighborhood in the data graph";
  scos:scopeNote """A Simple shape cannot:
- Use sh:node only with other than a sh:ReferenceShape
- Use sh:and, or, not with other than sh:SimpleShapes
- Target a class that has super-classes targeted by other than sh:SimpleShapes""",
    """If a NodeShape is asserted to be a SimpleShape then 
the SHACL processor must check the limitations and raise an error if they are not satisfied""".
    """If a NodeShape matches the limitations then 
it can be asserted internally by the SHACL processor as a SimpleShape, which can help with checking shapes that use it""".

The reason I propose these as distinct classes (rather than just limitations in the spec) is because having such classes (asserted or inferred after checking limitations) can help the SHACL processor.

[HolgerKnublauch]

I think it would be best to generalise this so that shapes or shapes graphs can point to any given Profile. So instead of sh:Simple/ReferenceShape, it could just be a sh:NodeShape with sh:profile ex:SimpleProfile. The sh:profile property would then be validated by a SHACL engine.

[VladimirAlexiev]

@HolgerKnublauch
It may be better to use sh:profile instead of rdf:type.
But thinking about #216, a profile is a set of features allowing a certain complexity of implementation and efficiency of validation.
So we could say eg

• The SHACL Simple profile permits only Reference and Simple shapes
• If more complex shapes are included, they must be sh:deactivated

But we still need to be able to talk about the complexity of individual shapes.