Re: $this in Aggregations

I don't think that the new wording conforms to that used in SPARQL, so there
are still changes required here.  Furthermore, the "Furthermore" sentence is
still in the document.

peter


On 11/21/2016 10:49 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> FYI this issue has been recorded in our tracker as ISSUE-208:
> 
>     https://www.w3.org/2014/data-shapes/track/issues/208
> 
> I have gone through all examples and definitions based on SELECT queries that
> I could find, and all of them already project ?this out of the query, so I
> believe the rule that you suggest is OK to adopt. I have added corresponding
> statements to the spec:
> 
> https://github.com/w3c/data-shapes/commit/673b364ab68c68299b0fc6e902b6907af21cf8f9
> 
> 
> Questions: does this mean that I can delete the sentence on Aggregates?
> Anything else needed to close this issue from your perspective?
> 
> Thanks
> Holger
> 
> 
> 
> On 24/09/2016 4:11, Peter F. Patel-Schneider wrote:
>> Here are the requirements for SELECT queries:
>>
>> "The SPARQL queries linked to a constraint via sh:select must be string
>> literals that can be parsed into legal SPARQL 1.1 queries of the query form
>> SELECT after they have been treated with the prefix handling rules outlined
>> later."
>>
>> "The value of sh:select must be a valid SPARQL query using the
>> aforementioned prefix handling rules. This type of validator can be used as
>> values of sh:shapeValidator or sh:propertyValidator."
>>
>> "Furthermore, any query that uses the variable this as part of the
>> Expression used in a SPARQL 1.1 Aggregate is invalid."
>> [This is buried quite deep in 6.4.1.]
>>
>> "The SHACL Full processor must produce a failure if the resulting SPARQL query
>> string cannot be parsed into a valid SPARQL 1.1 query."
>>
>> There is no requirement that $this is returned from the query.  Instead why
>> not just require that $this is returned from the query (maybe also not using
>> AS)?  This would mean that any GROUP BY has to include $this and then there
>> is no problem using $this in aggregates.
>>
>> Currently allowed but newly disallowed:
>>
>> SELECT DISTINCT ?lang
>> WHERE {
>>     { FILTER ($uniqueLang) . }
>>     $this $PATH ?value .
>>     BIND (lang(?value) AS ?lang) .
>>     FILTER (bound(?lang) && ?lang != "") .
>>     FILTER EXISTS {
>>         $this $PATH ?otherValue .
>>         FILTER (?otherValue != ?value && ?lang = lang(?otherValue)) .
>>     }
>> }
>>
>> Currently disallowed but newly allowed:
>>
>> SELECT $this
>> WHERE { OPTIONAL { $this $PATH ?value . } }
>> GROUP BY $this
>> HAVING (COUNT(?value) < $minCount) && (COUNT(?this)<2)
>>
>> Both are somewhat silly but it seems to me that the new rules are simpler
>> than the current ones.
>>
>> peter
>>
>>
>> On 09/22/2016 09:52 PM, Holger Knublauch wrote:
>>> (In order to prevent a deeply nested email thread that goes across multiple
>>> topics, I am splitting the remaining issues into individual emails).
>>>
>>> On 23/09/2016 11:36, Peter F. Patel-Schneider wrote:
>>>>> aggregation
>>>>>
>>>>> The prohibition "Furthermore, any query that uses the variable $this in an
>>>> aggregation is invalid." is vague. It appears to disallow the use of $this
>>>> in any part of the SPARQL 1.1 aggregation machinery, as the pointer in the
>>>> sentence is to Section 11 of the SPARQL specification. This would rule out
>>>> all of the examples of aggregation in the SHACL document.
>>>>>       Comment (HK): I have tried to clarify that this is only about the use
>>>> of ?this in expressions. This is allowing its use in GROUP BY, in case you
>>>> were referring to this. Apart from that I don't see uses of ?this in
>>>> aggregations in the SHACL document.
>>>> https://github.com/w3c/data-shapes/commit/0c6939ba95ffd6c7fee2285a3638c144a97f8528
>>>>
>>>>
>>>>
>>>> GROUP BY is part of aggregation.  There were four examples of GROUP BY ?this
>>>> which the mentioned wording appears to prohibit.  The current wording is no
>>>> better.  "[T]he expression used in an aggregation" is an incorrect
>>>> description as there can be multiple expressions in the aggregation portion
>>>> of a query.  The argument to GROUP BY itself is just as much an expression
>>>> as the argument to HAVING.
>>>>
>>>> This situation is indicative of the sloppiness of the current specification.
>>>> SPARQL has a complicated grammar.  The argument to GROUP BY is a sequence of
>>>> GroupCondition; the argument to HAVING is a sequence of HavingCondition.
>>>> Using general words, like "expression", to describe bits of the SPARQL
>>>> grammar is generally incorrect.  Where specific bits of SPARQL are used in
>>>> the SHACL definition they need to be described as they are in the SPARQL
>>>> definition.
>>> I have clarified this by pointing at the specific Aggregate construct in the
>>> SPARQL syntax:
>>>
>>> https://github.com/w3c/data-shapes/commit/6501260d135dde1ff05b86b71b8c3835dab9dd03
>>>
>>>
>>>
>>> Holger
>>>
>>>
>

Received on Tuesday, 22 November 2016 22:32:39 UTC