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

Holger,

Let's agree to disagree about the influence that your implementation
experience is having on the language design.

You asked me to propose and alternate term and the WG agreed with that
action. I'll think about this more and post my proposal on the wiki,
or endorse your proposal.

-- Arthur



On Thu, Oct 22, 2015 at 3:48 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> If this explanation is too long, then sh:scopeClass in general is too
> complex. All I did is to apply our own technology consistently, just like
> the OWL people did with owl:Restrictions. As I explained, this consistency
> provides numerous benefits which a newly minted property would drop.
>
> I also strongly disagree with the repeated claims that "this just reflects
> Holger's specific implementation". This is completely untrue. In fact the
> whole topic is part of the extension mechanism, which is part of SHACL. The
> details of this have no impact on the Core Language, if this is what you are
> concerned about.
>
> Holger
>
>
>
>
> On 10/23/15 4:25 AM, Arthur Ryman wrote:
>>
>> 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 21:24:07 UTC