FeDeRate provides a mapping between RDF queries and SQL queries over conventional relational databases. SPASQL provides similar functionality, but eliminates the query rewriting phase by parsing the SPARQL directly in the database server. This approach is efficient, and allows applications linked to currently deployed MySQL client libraries to execute SPARQL queries and get the results back through the conventional MySQL protocol.

The parallels between the SPARQL Result Set and SQL relational results allow applications to issue SPARQL queries and process the results as they would process SQL query results. In practical terms, this would entail changing your MySQL server and changing a query in a PHP script to issue a SPARQL query instead of a SQL query, greatly simplifying the deployment requirements of systems like FeDeRate.

Relational schemas tend to be brittle; they require maintenance when new attributes need to be stored. Storing odd attributes in a generic triple store allows a database to efficiently handle the uniform data, and provide flexible storage for irregular data in the generic triple store. Queries on conventional relations can be joined with triple store queries, providing an efficiency where possible and flexibility where needed.

This presentation will discuss the technical choices made during the SPASQL project, conventional applications of SPASQL, and explore next steps, including federation portions of a query to other databases or sources of RDF data. Trade-offs between relational model maintenance time vs. generic triple store query times will allow viewers to decide if this system is right for them, as well as decide how they will manage such a system. Developers of SQL client applications and Semantic Web developers are encouraged to attend.