Proposal 4 is immature, untested and unstable (was: implementation of core SHACL (using proposed syntax))

On 14/04/2016 6:00, Peter F. Patel-Schneider wrote:
> On 04/12/2016 10:40 PM, Holger Knublauch wrote:
>> On 13/04/2016 1:11, Peter F. Patel-Schneider wrote:
> [...]
>
>> Do you have an example of a user-defined constraint component by any chance?
>> How would someone formalize the kind of SPARQL generation without pre-binding?
> [...]
>
>> Holger
> I have a template-driven version of SHACL.  It currently does not handle
> nested validation reports, however.
>
> It does not use pre-binding, instead using textual substitution, which is only
> needed for IRIs and literals so the problems with substituting blank nodes do
> not arise.
>
>
> Here are a few templates for core components, including RDFS ranges and shapes
> that determine whether the component is syntactically correct.
>
> sh:datatypeIn a rdf:Property ; a sh:Shape ; rdfs:domain sh:Shape ; rdfs:range
> rdf:List ;
>    sh:list [ a sh:Shape ; sh:nodeKind sh:IRI ] .
> shmm:datatypeInShape a sh:Shape ; sh:scopeClass sh:Shape ;
>    sh:propValues ( sh:datatypeIn sh:datatypeIn ) .
>
> sh:datatypeIn a sh:ComponentTemplate ;
>    sh:templateMessage "Does not have any required datatype [l(argument)]"@en ;
>    sh:message "Datatypes need to be IRIs"@en ;
>    sh:templatePattern """BIND ( datatype(?this) AS ?dt )
>      FILTER NOT EXISTS { VALUES ?dt { [l(argument)] } }""" .
>
> sh:maxExclusive a rdf:Property ; a sh:Shape ; rdfs:domain sh:Shape ;
> rdfs:range rdfs:Literal ;
>    sh:nodeKind sh:Literal .
> shmm:maxExclusiveShape a sh:Shape ; sh:scopeClass sh:Shape ;
>    sh:propValues ( sh:maxExclusive sh:maxExclusive ) .
>
> sh:maxExclusive a sh:ComponentTemplate ;
>    sh:templateMessage "Too big, must be less than [argument]"@en ;
>    sh:message "Minimum must be a literal"@en ;
>    sh:templateFilter "( COALESCE(?this < [argument],false) )" .
>
> sh:disjoint a rdf:Property ; a sh:Shape ; rdfs:domain sh:Shape ; rdfs:range
> rdf:List ;
>    sh:list shmm:pathShape ;
>    sh:propValues ((rdf:rest rdf:rest) [ a sh:Shape ; sh:hasValue rdf:nil ] ) .
> shmm:disjointShape a sh:Shape ; sh:scopeClass sh:Shape ;
>    sh:propValues ( sh:disjoint sh:disjoint ) .
>
> sh:disjoint a sh:ComponentTemplate ;
>    sh:propValues (rdf:first [ a sh:Shape ; sh:argumentName "path1" ] ) ;
>    sh:propValues ((rdf:rest rdf:first) [ a sh:Shape ; sh:argumentName "path2"]);
>    sh:templateMessage "Path values not disjoint"@en ;
>    sh:message "Not list of two paths"@en ;
>    sh:templatePattern """?this [p(path1)] ?value1 . ?this [p(path2)] ?value1 .""" .
>
> sh:and a rdf:Property ; a sh:Shape ; rdfs:domain sh:Shape ; rdfs:range rdf:List ;
>    sh:list [ a sh:Shape ; sh:class sh:Shape ] .
> shmm:andShape a sh:Shape ; sh:scopeClass sh:Shape ;
>    sh:propValues ( sh:and sh:and ) .
>
> sh:and a sh:ComponentTemplate ;
>    sh:templateMessage "AND"@en ;
>    sh:message "sh:and takes a list of shapes"@en ;
>    sh:templateQuery """SELECT [projection] ?this ?message ?severity ?subject
> ?property ?object
> WHERE { { [l(s(argument) " } UNION { ")] } }""" .

So now you have quickly made up a new text substitution mechanism for 
SPARQL, with some new syntax that nobody but you has ever used, with 
unknown consequences and complexity. Instead of SPARQL, people are now 
supposed to use your macro language, with special constructs that 
probably hard-code the core vocabulary but not the other extensions 
needed in real-world use cases. While I can (off the top of my head) 
think of numerous problems with this, I am starting to get tired of this 
discussion here, and really don't want to spend any more time on this. 
There is nothing broken with Proposal 3 that cannot be fixed with a bit 
of good will. Your goal was to simplify the language, but I think you 
have lost the plot.


May I take a step back for a second? I thought W3C WGs were supposed to 
standardize candidate technologies that have reached a sufficient level 
of adoption, not to do research prototyping. This Shapes WG started off 
with Resource Shapes, ShEx and SPIN as input. There are many years of 
industry experience with all these. The current draft heavily borrows 
the declarative syntax from Resource Shapes and is very similar to SPIN 
in the extension mechanism. Basically we have combined two proven 
technologies, and ShEx has added missing features and will likely 
contribute a compact syntax. Mission would be accomplished.

Sometimes last year Peter came up with his SHACL-SPARQL proposal. It 
didn't get much support then. Now, after more than a year into the WG, 
Peter reiterates exactly the same ideas and attempts a take-over of the 
group with a Proposal 4 that is full of problems, and that would 
invalidate all previous discussions, resolutions and user experience.

Holger

Received on Wednesday, 13 April 2016 21:27:00 UTC