Blog

Simplified SPARQL Aggregates

September 17th 2011 by Arto

We have observed that SPARQL 1.1’s syntax for aggregates tends to surprise many, if not most, people. According to the standard SPARQL 1.1 grammar, to write a COUNT() query you have to be somewhat verbose:

SELECT (COUNT(*) AS ?count) WHERE {?s ?p ?o}

Note the required explicit variable name, ?count, as well as the required parentheses surrounding the projected expression. With a strictly standards-compliant SPARQL query processor, omitting either the parentheses or the variable binding will result in a syntax error. This was also the case with Dydra until recently.

As of today, however, we also support a simplified and abbreviated convenience syntax for aggregates, one that is more in line with the previous experience and initial expectations of users coming from, say, an SQL background:

SELECT COUNT(*) WHERE {?s ?p ?o}

The same convenience syntax is available for all the familiar COUNT, SUM, MIN, MAX, and AVG aggregates.

To write maximally portable SPARQL queries, you should probably continue to use the standard syntax in any non-trivial software you release. However, when initially exploring your dataset and formulating your queries using the Dydra query editor, we’re sure you’ll quickly find the abbreviated syntax to be a very welcome convenience indeed.

If you have similar pet peeves and pain points with other aspects of the SPARQL standard, let us know. Making your use of SPARQL as easy and pleasant as possible is what we’re here for…

Continue reading...

DAWG Test Suite for SPOCQ

September 8th 2011 by James

ARQ proposed a standard textual notation for abstract SPARQL algebra expressions, which it calls ‘symbolic SPARQL expressions’ (SSEs). The documentation describes expressions which are compatible with Lisp’s S-expressions and, given appropriate reader and printer support, can serve as the externalization for a model of abstract SPARQL algebra expressions represented as simple lists.

This approach has proven invaluable to the development of Dydra’s SPOCQ query engine. In the early phases, expositions in the literature on SPARQL 1.0 semantics made it relatively easy to implement the query processor in terms of a small collection of Lisp macros which constituted an operational semantics for SPARQL.

As the work progressed towards support for SPARQL 1.1, this abstract algebra model and the SSE notation made it easier to comprehend the intent of the W3C specification and to verify the query processor’s performance against the Data Access Working Group’s evolving test suite.

In order to document this aspect of our implementation, we have translated the query expressions from the original SPARQL form into SSEs and present them here for reference. We also record and publish our latest DAWG conformance test results here:

Continue reading...

SPARQL 1.1 Now Supported

September 7th 2011 by Arto

The top feature request we’ve heard from our users and customers lately has been support for SPARQL 1.1. We’ve listened, and are pleased to announce that Dydra now implements SPARQL 1.1 Query and Update in full.

SPARQL 1.1 Query

We now fully support SPARQL 1.1 Query, including aggregates, subqueries, negation and filtering, SELECT expressions, property paths, assignments and bindings, syntactic sugar for CONSTRUCT, and many additional operators and functions.

Signing up for a Dydra account is the very easiest way to get to grips with the new features in SPARQL 1.1. Our easy-to-use browser-based query editor lets you interactively write and test queries on your dataset without any hoops to jump through to install complex software or to configure and serve a SPARQL endpoint yourself.

SPARQL 1.1 Update

We also now fully support SPARQL 1.1 Update. Starting today, you can use all of the update operators on your repository data: INSERT/DELETE, INSERT DATA, DELETE DATA, LOAD, CLEAR, CREATE, DROP, COPY, MOVE, and ADD.

We will in the near future be updating our documentation with further details regarding the transactional semantics of Dydra, since the official SPARQL 1.1 Update specification leaves them up to each implementation.

Faster Queries

We’ve improved our query engine’s performance quite a bit. It was already pretty fast before, and it’s yet faster now. In particular, we’ve improved the throughput for “worst-case” queries that perform a lot of full edge scans of large repositories. These kinds of queries can now run even up to a hundred times faster.

This is, indeed, one of the benefits of hosting your SPARQL endpoint with Dydra: as we simultaneously both roll out ever more hardware capacity and work to further improve our query engine, you reap the benefits without having to lift a finger.

Faster Imports

Last but not least, we’ve overhauled how we do data imports. We now make use of the very latest release of the Raptor RDF Syntax Library, the high-performance, open-source library for parsing and serializing most RDF serialization formats as well as RSS/Atom feeds and various microformats.

Anything that Raptor can parse, Dydra can now import into your repository. The new import functionality is also considerably faster than what we offered before.

We intend to keep our internal Raptor build closely in sync with the upstream open-source release, which means that the best way to ensure Dydra can import some new format or another is to contribute to the Raptor project on GitHub

Continue reading...