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

Holger,

Your explanation is too long for our target users to understand. It
would be clearer if we defined a new term for this purpose instead of
reusing sh:scopeClass.

-- Arthur

On Thu, Oct 15, 2015 at 8:36 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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
>>
>

Received on Thursday, 22 October 2015 18:25:32 UTC