Re: ISSUE-95: Template Simplifications

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.

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

peter

Received on Thursday, 29 October 2015 23:51:25 UTC