Re: ISSUE-95: Is sh:scopeClass overloaded?

Hi Arthur,

I know the rationale behind this design isn't entirely obvious. This is 
in part because the design is liberally moving between various 
metalevels, and templates are also shapes in my design. But there is a 
precedent for this:

OWL has owl:Restrictions, which are defined using rdfs:subClassOf, e.g.

ex:Person
     a owl:Class ;
     rdfs:subClassOf ex:Animal ;
     rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty ex:firstName ;
         owl:allValuesFrom xsd:string ;
     ] .

Arguably, the designers could have created a new property 
owl:restrictedBy to distinguish restrictions from named superclasses, 
but since there is no logical difference between restrictions and other 
classes, they chose to reuse the same subset mechanism. However, seeing 
restrictions defined as superclasses also sometimes confuses people and 
tools may want to handle them different too. Yet, the overall language 
design is consistent, and does make sense if you dive deep enough.

In the case of SHACL, let my try to walk through this step by step.

1) sh:Arguments are constraints.

For example, if you define

ex:MyTemplate
     a sh:ConstraintTemplate ;
     sh:argument [
         sh:predicate ex:myProperty .
         sh:datatype xsd:integer .
     ] .

and then you instantiate

ex:MyShape
     sh:constraint [
         a ex:MyTemplate ;
         ex:myProperty 4.2 ;
     ] .

this would be flagged as a violation, because ex:myProperty must have 
xsd:integers, not xsd:decimals.


2) sh:scopeClass is a bit like superClassOf

 From a validation point of view, there is no difference between:

a)    ex:MySubTemplate rdfs:subClassOf ex:MyTemplate .

b)    ex:MyTemplate sh:scopeClass ex:MySubTemplate .

If you have an instance of ex:MySubTemplate, then all constraints 
attached to ex:MyTemplate also apply, e.g. if ex:MyTemplate is the 
scopeClass of some shape, or if ex:MyTemplate is a ShapeClass itself 
(which it is in my design). This is the same situation with an 
inferencing-based approach, where the constraints at MyTemplate also 
"inherit" down into MySubTemplate (let's please not fight over 
terminology here).


3) Constraints define the structure of data

Constraints such as sh:property and sh:argument declare "applicable" 
properties. Tools can use this information to build up input forms etc. 
Attached is an input form from TopBraid, which shows that we were able 
to use the very same mechanisms to build a form either for a shape or 
its property constraints. It is a very common scenario to have 
algorithms that walk through all applicable properties and do something. 
All we need to do here is to follow rdfs:subClassOf and sh:scopeClass 
links. It would be a wasted opportunity to require yet another mechanism 
to find the applicable properties, especially if this mechanism only 
applies to certain kinds of objects (here: template definitions). This 
doesn't only impact the compactness of the algorithms and SPARQL 
queries, but also their performance - one more property to check at 
every step.

The same argument applies to validation: with the consistent mechanism 
people can run SHACL engines over SHACL files, e.g. to check the syntax 
of their constraint definitions.

The redesign fixes a previous issue with the spec, which was reusing 
rdfs:subClassOf to mean two different things (argument inheritance 
versus template injection). The redesign intentionally fixes this 
without introducing any new custom properties.

Does this make more sense now? I do believe this issue will only ever 
have to be fully understood by few people - only a subset of SHACL users 
will write their own templates, and from those almost everyone will 
either use a wizard-like tool or copy-and-paste from another example 
template in Tutorials. Whether they see sh:scopeClass or sh:injectedInto 
in their copied snippets will not make any difference to them. However, 
sh:injectedInto would be extra work for all algorithms that try to make 
sense of a SHACL document.

Thanks
Holger




On 10/16/2015 4:09, Arthur Ryman wrote:
> I looked at Holger's proposal. It looks like sh:scopeClass is being
> used for a completely different purpose than its original purpose
> which was to define the scope of a shape as being a class. In Holger's
> proposal it is being used to inject a node constraint into a property
> constraint.
>
> I'd like to see a new predicate used for template injection.
>
> -- Arthur
>