Re: $this in Aggregations

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 Friday, 23 September 2016 18:12:21 UTC