Re: ISSUE-95: Template Simplifications

I believe the underlying problem in this discussion is that there is one 
viewpoint that doesn't really seem to care about templates and whether 
SHACL can be expressed in itself, and another viewpoint that tries to 
make templates as user-friendly as possible and also have the 
possibility to express SHACL in itself.

I don't want to be forced to treat the core language different from how 
extensions work - indeed I find it a major selling point of SHACL to 
have this option. I am not feeling that I am getting support for my 
viewpoint, and people come up with all kinds of roadblocks that seem to 
make my life as difficult as possible. Over a month ago, I have proposed 
necessary refactorings to further simplify the Turtle file and reduce 
the number of abstract classes, but I am blocked on those refactorings. 
This produces a self-fulfilling prophesy, because I am not able to 
demonstrate that the SHACL.shacl file has indeed become much shorter.

Blank statements such as "don't use inheritance" without looking into 
details and proposing alternatives don't work for me. I have spent a lot 
of time trying to come up with an architecture that supports both view 
points. Those who only care about the Core language can happily continue 
to do so - we have even split the document into two Parts for that 
purpose. But there are numerous advantages in being able to implement 
SHACL using templates, and the design is very consistent.

*It would significantly increase the implementation burden and thus 
hinder the acceptance of SHACL if the core language cannot be expressed 
in templates.* Right now, my implementation just needs a single 
mechanism - SHACL's own extension mechanism to drive everything. Why on 
earth should people be forced to first implement the Core language and 
then (separately) the extension mechanism? There is no convincing reason 
IMHO. We are throwing away the baby with the bathwater here. What is 
missing is a better explanation of how the templating mechanism works 
because I seem to have lost most people here along the way. But this is 
an editorial and temporary problem.

On 10/30/2015 9:50, 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:
> [...]
>
>>> 7.4
>>>
>>> [All of 7.4]
>>> ->
>>> It is sometimes desirable to mix multiple templates so that
>>> they can be used within the same constraint.  This is done by making a
>>> template class that is a subclass of multiple other template classes.  An
>>> instance of the child template class then combines the effects of all these
>>> templates, because it is an instance of them all.
>> You state above that you want to get rid of abstract superclasses. In the
>> current TTL file, there is a class sh:AbstractPropertyConstraint which defines
>> the argument sh:predicate once and for all its subclasses. Similarly, there is
>> now a shared superclass for the two templates defining sh:qualifiedMinCount
>> and sh:qualifiedMaxCount, to define their shared argument
>> sh:qualifiedValueShape. How would your design handle these cases?
> This is about implementing the core vocabulary.  This does not need to be part
> of the SHACL spec at all.
>
>> Also, why would anyone want to instantiate something like
>> sh:AbstractDatatypePropertyConstraint directly? The language only really
>> supports instantiating sh:PropertyConstraint.
> If these abstract superclasses are removed then there is no problem with
> instantiating them.
>
>> The reason for me to introduce template injection was to be able to
>> distinguish the "inheritance" of arguments from "merging" them into a single
>> node. My previous design was mixing those two aspects, blurring the lines
>> between those two use cases.
>>
>> While not completely out of the question, a major problem that I ran into was
>> the treatment of optional arguments. Example of this include
>> sh:ignoredProperties (from closed shapes) and sh:flags (from sh:pattern). If
>> we only have a single mechanism, then a superclass such as
>> sh:PropertyConstraint would "inherit" all properties such as sh:minCount and
>> sh:pattern as non-optional. Do you have a better solution to this?
> Just don't "inherit" properties.  Let each template be in control of the
> arguments that it wants.

See above. I want to be able to express the core vocabulary as templates 
too. In the end, what we selected to be "core" is just an arbitrary 
choice, and serves as examples of what other people will want to express.

>
> Further, is there any need for this outside of implementing the core vocabulary?

Yes absolutely. I have numerous examples of where I want to add new 
properties to sh:property, e.g. to mark a property as primary key. And 
those templates need to "inherit" sh:predicate, for example.

Holger

Received on Friday, 30 October 2015 00:31:48 UTC