Re: shapes-ISSUE-95 (Template Simplifications): Proposed simplification and clean up of template mechanism [SHACL Spec]

Peter,

I found your first email on this topic more constructive, where you 
stated that this is going in the right direction. You have meanwhile 
raised a new ISSUE for the topic of subclassing. I believe we can and 
should handle these two topics individually. My proposed simplifications 
address the issue of having an unnecessary amount of AbstractXY classes, 
so there are definitive benefits. I suggest to approve this suggestion 
and then look at ISSUE-101 as a next possible refactoring. I see no 
reason why ISSUE-101 should block progress on ISSUE-95.

On 10/8/2015 23:16, Peter F. Patel-Schneider wrote:
> As far as I can tell the only change to 7.3 Template Instantiation is to add
> a clarification sentence at the end, which does not make a technical change
> at all.
>
> The beginning of 7.4 Template Injection does not make any sense at all.
> What is an "instance node"?  The phrase does not occur elsewhere in the
> document at all.

On the branch of the spec I have switched from "instance node" to 
"constraint node". What else does not make sense at all? I'd appreciate 
specific feedback.

>    This section also overloads sh:scopeClass.

I believe the approach uses sh:scopeClass consistently with its meaning. 
Using the example from 7.4, if you have an instance of 
sh:PropertyConstraint then these instances must fulfill the structural 
constraints at the shape ex:LanguageConstraint. In particular they must 
fulfill the definition of the sh:argument ex:lang, e.g. to make sure 
that languages must be strings. This means that infrastructure for 
editing and constraint checking can be reused for constraint 
definitions, leading to significantly lower costs of adoption - and I 
speak from experience as someone who is building such tools.

Holger


>
>
> The approach continues to use rdfs:subClassOf for template inheritance.  The
> rdfs:subClassOf property is defined on RDFS classes as the way to state that
> one class is a subclass of another.  It is not about inheritance between
> non-classes.  I thus vote against this change.  The first change that needs
> to be done is to replace the use of rdfs:subClassOf.
>
>
>
> peter

Received on Thursday, 8 October 2015 22:39:26 UTC