- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 21 Sep 2016 09:40:23 -0700
- To: Andy Seaborne <andy@apache.org>, public-sparql-exists@w3.org
On 09/21/2016 08:07 AM, Andy Seaborne wrote:
> Hi Peter,
[...]
>> My view is that if there is a good way of retaining either a reasonable
>> meaning or what is generally implemented then that should be the goal
>> instead of forbidding constructs. So the useful construction (well useful
>> if there is an initial query instead of a VALUES)
>> SELECT ?book WHERE {
>> VALUES ?book { :book1 :book2 }
>> FILTER EXISTS {
>> VALUES ?book { :book2 } } }
>> should produce :book2 and not be illegal.
>
> I'm not seeing a use case for this way of writing it when there is FILTER such
> as FILTER(?book IN ( .... ))?
There are other ways of writing this, I agree, but I think that the goal here
should be to try to come up with a method that can handle VALUES ?var ...
inside an EXISTS. It is legal syntax. It's intuitive meaning is clear. The
only reason that it is currently problematic is the substitution definition of
EXISTS. So instead of forbidding VALUES ?var inside EXISTS, fix the
definition of EXISTS to support its intuitive meaning.
> VALUES can be a number of tuples, and include UNDEF as a possible setting.
> These other forms make it more complicated so in the tradeoff of complexity
> for a few more possible forms, I think there is merit in a clear, simple
> solution.
If the clear, simple solution is to forbid SPARQL queries that are currently
legal syntax and have a clear intuitive meaning then I don't see any merit to
the solution.
[...]
peter
Received on Wednesday, 21 September 2016 16:40:56 UTC