Re: aggregates

Simon Schenk wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>> CONSTRUCT
>> { ?X ex:hasFriends
>>   {COUNT ?X WHERE ?P foaf:knows ?X}
>> }
>> WHERE {?P a foaf:Person}
> 
> In [3] on slide 3 it should be 'COUNT ?P', right? If not, could you please
> explain the example, as in that case I do not understand it. ;-)

I want to count the number of friends per ?P, i.e. the number of ?X that 
?P knows.

> Subqueries in CONSTRUCT frighten me.

Why?

> I would prefer to keep CONSTRUCT similar to
> a projection, perhaps with scalar expressions in the line of the current filter
> expressions, but not as complicated as subqueries. I'd prefer something like
> 
> CONSTRUCT
> { ?P ex:hasFriends ?F }
> WHERE {
>   ?P a foaf:Person.
>   SELECT COUNT(?X) AS ?F WHERE {
>     ?P foaf:knows ?X }
> }


The intention was I would like to treat subqueries as well as aggregates 
as "expressions". Throwing the subquery into the pattern reads a bit 
strange IMO. What I suggest is just writing

{ COUNT ?X WHERE { ?P foaf:knows ?X } } as ?F

instead of

SELECT COUNT(?X) AS ?F WHERE { ?P foaf:knows ?X }


I need to see clearer what is the exact semantics of subselects inside 
the pattern.
How do e.g. the bindings from the outside pattern propagate into the 
subquery. Does the order play a role here or do these subselects behave 
like filters (always to be evaluated last)?

If the latter, how does that fit e.g. with the example from 
LimitPerresource:

  SELECT ?post ?title ?author ?date
  {
    { SELECT ?post { ?post a sioc:Post } LIMIT 10 }
    ?post dc:title ?title ; sioc:has_creator ?author ; dc:created ?date.
  }

  wouldn't that one be clearer if written as:

  SELECT ?post ?title ?author ?date
  { ?post dc:title ?title ; sioc:has_creator ?author ; dc:created ?date.
    FILTER( { ?post IN {SELECT ?post { ?post a sioc:Post } LIMIT 10 } )
  }


> Btw, that argument affects other features such as fulltext as well. The current
> SPARQL design is quite clean: BGP matching binds variables. FILTER filters out
> some of these bindings. Result formats and modifiers do some post processing.
> That may involve sorting, grouping, in the future also filter expressions and
> aggregate functions, grouping etc, but not matching. I'd prefer to keep it like
> this.

It is not clear to me how the current subselect proposal fits cleanly 
into that and it seems that some means to construct new values is 
anyways wanted (be it project exprerssions, scalars, or assignment)

A lot of these questions maybe boil down to simply a matter of taste, 
but we need to get them clear.

Axel

> Cheers,
> Simon
> 
> Axel Polleres schrieb:
>> Looking at the examples for aggregates [1] and thinking about an earlier
>> implementation I did on aggregate functions inspired rather by
>> aggregates in declarative logic programming than in SQL, I sketched an
>> alternative syntax proposal for aggregates at [3] which I could present
>> briefly as part of the aggregates discussion on day 2.
>>
>> 1.
>> http://www.w3.org/2009/sparql/wiki/Feature:AggregateFunctions
>> 2.
>> http://www.mat.unical.it/asptut/slides/unit2.pdf, slide 60ff
>> 3.
>> http://www.polleres.net/presentations/20090506SPARQL_aggregates_as_subqueries.pdf
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEARECAAYFAkoBUMEACgkQQ0Lz1fXAQeOljACgo34w+HMXBTp5AUlZqXff4cDi
> uRkAn3ihvdd7DwfXnZwF0bNIQ8kMxCuZ
> =k9MM
> -----END PGP SIGNATURE-----
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Wednesday, 6 May 2009 09:39:09 UTC