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

As far as I can tell this proposed change goes in the right direction,
particularly if it removes dependency on subclass relationships between templates.

However, the summary description here is quite high level and the diff is
unreadable.  I think that a clean version of the appropriate document sections
is needed to evaluate the proposal.


peter


On 09/28/2015 05:55 PM, RDF Data Shapes Working Group Issue Tracker wrote:
> shapes-ISSUE-95 (Template Simplifications): Proposed simplification and clean up of template mechanism [SHACL Spec]
> 
> http://www.w3.org/2014/data-shapes/track/issues/95
> 
> Raised by: Holger Knublauch
> On product: SHACL Spec
> 
> Based on recent discussions (e.g. about the unification of property constraints with node constraints, and the many AbstractXY classes in the Turtle file), I have carefully revised the template mechanism, leading to a cleaner and much more compact design.
> 
> I have described them on a branch of the spec [1] and this diff gives some impression of the changes [2].
> 
> In a nutshell, I am proposing two changes. Sorry they are very technical and may not be of interest to everyone here:
> 
> 
> 1) Cleaner template injection mechanism, instead of inheritance (see corresponding section in the Templates section).
> 
> In the previous version, if multiple templates were merged into one (such as sh:PropertyConstraint), then they would use rdfs:subClassOf.  In the new design I am using sh:scopeClass for that purpose, because this more cleanly separates argument inheritance from SPARQL body inheritance.
> 
> 
> 2) Replaced sh:validationFunction with sh:NodeValidationFunction, and allowing these functions to directly inject themselves into other templates such as sh:PropertyConstraint.
> 
> In the previous version, each validation function still needed to be backed by a separate template, even though this template was almost trivial and had basically the same arguments all over again.  In the new design, it is sufficient to declare the validation function and give it sh:scopeClass sh:PropertyConstraint.
> 
> The net result of these changes is that I was able to drop the vast majority of AbstractXY classes, and the same function code is reused for sh:property, sh:inverseProperty, sh:argument and (if approved) sh:constraint. I am pasting an example node validation function below - this is all that it takes to inject a new property into sh:property:
> 
> ex:hasLanguage
>  a sh:NodeValidationFunction ;
>  sh:scopeClass sh:PropertyConstraint ;
>  sh:argument [
>   sh:predicate ex:lang ;
>   sh:datatype xsd:string ;
>   rdfs:label "language" ;
>   rdfs:comment "The language to match against, e.g. \"de\"." ;
>  ] ;
>  sh:sparql """
>     ASK {
>      FILTER (isLiteral($node) && langMatches(lang($node), $lang)) .
>   }
>   """ .
> 
> which can then be used as a new property ex:lang as in
> 
> ex:TemplateLanguageExampleShape
>  a sh:Shape ;
>  sh:scopeClass ex:Country ;
>  sh:property [
>   sh:predicate ex:germanLabel ;
>   sh:maxCount 1 ;
>   ex:lang "de" ;
>  ] ; ...
> 
> I hope this proposed simplification is in everyone's best interest.
> 
> [1] https://github.com/w3c/data-shapes/tree/template-simplifications
> [2] https://github.com/w3c/data-shapes/commit/be1a06061c601315e0eb542dc5eddf7ca2c23e87
> 
> 
>

Received on Friday, 2 October 2015 17:20:03 UTC