Re: Anyone in support of SPARQL ASK constraints?

I think it is OK to drop ASK for now. If someone make a compelling
case for them later, we can bring ASK back.

-- Arthur

On Thu, Mar 19, 2015 at 1:59 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:
> I don't have an opinion as to whether these should be kept or not but I have
> to say that I can relate to the difficulty you're reporting people have had
> with the fact that the return value is counter-intuitive. I feel the same
> with your proposal in general in that, essentially, instead of defining what
> is valid I actually have to define the error cases. I fully understand how
> you got there but I've always thought this was awkward/counter-intuitive.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM
> Software Group
>
>
> Holger Knublauch <holger@topquadrant.com> wrote on 03/18/2015 07:10:58 PM:
>
>> From: Holger Knublauch <holger@topquadrant.com>
>> To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
>> Date: 03/18/2015 07:12 PM
>> Subject: Anyone in support of SPARQL ASK constraints?
>>
>> In an attempt to simplify the SHACL spec for users and implementers, I
>> would like to remove support for constraints based on SPARQL ASK. These
>> were supported in SPIN, because they are quick to write and produce a
>> boolean. However, they also caused issues in that many people did not
>> expect to return false to signal OK. The reason for that is that SELECT
>> and CONSTRUCT queries produce constraint violations, so the WHERE clause
>> should consistently return rows for the violating resources and values.
>> ASK can usually easily be replaced with SELECT * or SELECT (?this AS
>> ?root).
>>
>> So is anyone currently in favor of keeping ASK in?
>>
>>      http://w3c.github.io/data-shapes/shacl/#sparql-constraints-ask
>>
>> If I don't hear back, I'll take them out of the draft on Monday.
>>
>> Thanks
>> Holger
>>
>>

Received on Thursday, 19 March 2015 22:42:00 UTC