We've recently been debugging a few issues with our current SPARQL implementation so the next version will have a SPARQL engine that returns correct results more of the time (hopefully all the time but we can't guarantee that there aren't issues we haven't found yet). As detailed on the Known Issues page there is a bug in the 0.1.1 Alpha release whereby some queries result in the engine unnecessarily duplicating results, this can be worked around by using SELECT DISTINCT but the cause of the issue has been traced and corrected in development builds as of about a week ago.
I've also been looking at whether to include any of the proposed SPARQL 1.1 features that are in the Working Draft document from the W3C SPARQL Working Group. I have decided to go ahead and include aggregates in dotNetRDFs implementation since they were the thing I most often wanted to be able to do in testing stuff. Latest development builds committed to SVN this afternoon add support for AVG, COUNT, COUNT(*), MAX, MIN and SUM aggregates, currently the MAX and MIN aggregates only operate over the numeric data space. Until the working group sees fit to clarify how they expect such aggregates to behave over mixed data and how they decide what type of maximum or minimum to compute I'm not going to expand the capability any further. As part of this implementation all aggregates support aliasing to a variable name using AS ?alias syntax, if not specified explicitly an aggregate gets mapped to the variable ?Result in the Result Set. The aggregate result is a typed Literal Node (Integer for COUNT aggregates) and the widest numeric type for all others. A final limitation to this experimental implementation of aggregates is that only 1 aggregate is supported in a SELECT clause and currently we don't support any kind of GROUP BY/HAVING clauses in relation to aggregates. 21/10/2009 13:45:14 by Rob Vesse in English
There are currently no Tags for this Content!