Re: $this in Aggregations

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 06:55:54 UTC