- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 23 Jun 2006 15:07:16 +0100
- To: "Olaf Hartig" <OleBowle@gmx.de>
- Cc: <public-sparql-dev@w3.org>, "Richard Cyganiak" <richard@cyganiak.de>
-------- Original Message -------- > From: Richard Cyganiak <> > Date: 23 June 2006 14:06 > > Olaf, > > On 22 Jun 2006, at 11:15, Olaf Hartig wrote: > > In a recent paper about "Semantics and Complexity in SPARQL" > > (http://www.dcc.uchile.cl/~cgutierr/ftp/sparql-ext.pdf) > > Perez et.al. > > mention two approaches to compute solutions for graph patterns - one > > using a procedural semantics and another using a compositional > > semantics. As a real > > implementation for the first they name Jena's ARQ. I'm interested in > > an implementation following the second approach. Does someone, > > familiar with the paper, know of any? > > sparql2sql [1] implements only a subset of SPARQL, but that subset is > evaluated using compositional semantics. I don't see the distinction made in the paper as so black and white in ARQ - for example, the output from the parser turns into the abstract SPARQL operators, which in turn is turned into a concrete execution plan and that is executed. Naively, it's possible to directly implement the SPARQL operators but when converting to SQL (in the new query engine), it gets turned into something closer to relational algrebra (based on Richard's work) which reflects the particular database schema being used, which is turned into SQL and sent to the database engine. Andy > > Best, > Richard > > [1] http://jena.sourceforge.net/sparql2sql/ > > > > -- > > Bye, > > Ole > > ---------- > > GnuPG key: http://www.informatik.hu-berlin.de/~hartig/hartig.asc
Received on Friday, 23 June 2006 14:07:31 UTC