Re: SHACL semantics - any alternatives to SPARQL?

On 3/10/2015 4:25, Eric Prud'hommeaux wrote:
> I'd be very surprised if all the folks present at that vote understood 
> that it would be used as evidence that we specifically need SPIN 
> templates. At the time, I recall folks saying "well, perhaps ShEx is a 
> 'template' language..." It seems likely that it would have met with 
> objection had it explicitly read "SPIN templates". 

Eric, where do you want this process to go next? Shall we now re-open 
all requirements because someone may have misunderstood them? The 
wording was quite unambiguous about "parameterizable recurring 
patterns". SPIN-like templates are one possible design for this 
requirement, and have been successfully used in practice for many years. 
Furthermore, subsequent decisions and votes were made under the 
assumption that constraint macros are already accepted. If you want to 
reopen the voting, I could certainly live without sh:valueShape, which 
is causing a lot of problems for something that can also be expressed in 
SPARQL. I only voted in favor of it as a gesture of goodwill to the ShEx 
people.

>> be against templates in general - I believe the only open issue with
>> templates is that Jose suggested to use another language than SPARQL
>> (I believe he actually prefers some controlled sub-set of SPARQL).
>> Templates are very important to create user-friendly constraint
>> models for people who do not know SPARQL, so they need to be
>> mentioned in the Primer.
> The document no-class-templates.html was very explicit about factoring
> out templates and classes from the rest of the primer.

Factoring out does not mean deleting. You had no mandate to delete 
templates and I had objected to this out several times.

>
>
>> - The choices syntax is unnecessarily different from the rest of the
>> syntax. I think I could live with making these a hard-coded type of
>> constraint (instead of relying on templates), but I see no need to
>> have random new elements such as sh:propertyGroup. Neither should
>> sh:choice be directly attached to a Shape.
> I'm not sure what the counter-proposal is. How would I say that
> there was a choice between (foaf:name) OR (foaf:givenName AND
> foaf:familyName)?

This was already solved in the Example 11 of my version of the Primer 
that you overwrote with your own approach:

https://w3c.github.io/data-shapes/data-shapes-primer/ldom-primer.html


Overall I am not seeing a basis for further collaboration on this Primer 
under such circumstances and will vote against its further development 
or publication. Editors should try to build consensus and I am not 
seeing any willingness to compromise in your work.

Holger

Received on Monday, 9 March 2015 23:03:31 UTC