- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 30 Oct 2015 10:31:10 +1000
- To: public-data-shapes-wg@w3.org
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