sh:Template needed? (was: ISSUE-95: Template Simplifications)

On 10/30/2015 3:43, Peter F. Patel-Schneider wrote:
> On 10/28/2015 10:29 PM, Holger Knublauch wrote:
>> On 10/29/2015 14:14, Peter F. Patel-Schneider wrote:
> [...]
>>> I here propose several changes the normative bits of the version of Part 2
>>> that was prepared for ISSUE-95,
>>> http://w3c.github.io/data-shapes/shacl/index-ISSUE-95.html, that fix many of
>>> the problems there.  I have not proposed changes for any of the bits marked
> [...]
>>> SHACL also includes a more general superclass sh:Template that may be used
>>> for other kinds of templates (rules, stored queries etc). Well-defined,
>>> non-abstract templates must provide at least one body using a property such
>>> as sh:sparql.
>>> ->
>>> Well-defined templates must provide at least one body using a property such
>>> as sh:sparql.
>> Why drop sh:Template? It is already used as shared superclass of
>> sh:ConstraintTemplate and sh:ScopeTemplate, plus we have various other types
>> of templates in production and having a shared superclass streamlines the
>> infrastructure to manage them.
>
>
>
> The uses of sh:Template in the spec are:
>
> 1/ SHACL also includes a more general superclass sh:Template that may be used
> for other kinds of templates (rules, stored queries etc).
>
> This doesn't add anything to the spec at all.
>
> 2/ sh:Template is subclass of rdfs:Class, which means that templates can be
> instantiated via rdf:type.
>
> Make the appropriate subclasses directly be subclass of rdfs:Class.
>
> 3/ If a sh:Template has a value for sh:sparql, then the corresponding instances
> need to follow the same execution rules as outlined for SPARQL-based
> Constraints and SPARQL-based Scopes.
>
> I don't think that this is correct.  In any case it can just be stated on
> the appropriate subclasses.
>
> In sum, sh:Template doesn't add anything to SHACL.

The same argument could be applied to any abstract superclass, anywhere. 
But often such abstract superclasses help to better structure a class 
hierarchy and to reuse declarations. Templates are also a distinct 
general concept, and some definitions can be made for all kinds of 
templates.

Here is what the Turtle source code looks like

sh:Template
     a sh:ShapeClass ;
     rdfs:subClassOf sh:Macro ;
     rdfs:subClassOf sh:SPARQLExecutable ;
     rdfs:label "Template" ;
     rdfs:comment "A macro that acts as an abstraction of a (reusable) 
SPARQL query. The query can be parameterized by the supplied arguments." ;
     sh:abstract true ;
     sh:property [
         sh:predicate sh:labelTemplate ;
         sh:datatype sh:text ;
         rdfs:label "label template" ;
         rdfs:comment "Outlines how human-readable labels of instances 
of this template class shall be produced. The values must be strings 
that can contain {?argName} as placeholders for the actual values of the 
given argument. There may be multiple values, for different languages." ;
     ] ;
.

which shows that it does actually define the property sh:labelTemplate, 
which applies to every template. This would have to be repeated in every 
subclass. Given that we at TopQuadrant already have specific plans to 
add other subclasses of sh:Template, and that the cost of keeping 
sh:Template in the spec is really minimal, I suggest to keep sh:Template 
in the spec.

Why is this such a big deal?

Holger

Received on Friday, 30 October 2015 04:42:27 UTC