Markus - "...SMWExternalStore could simply take two objects on initilaisation..." seems like a good idea. Especially when we already have more than one SQL store implementation - so there is no good way just to extend a single sql store implementation.

For the interface of the RDFStore the idea is to bridge the core "wiki methods" (update page, delete page, create new page, move page) to the semantic store methods (SPARQL)
If we look into the sparql (1.1) specification everythings done via 3 methods: INSERT, DELETE and SELECT.
Everything else is a derivative (MODIFY = DELETE + INSERT).
So basically we should implement the "wiki-methods" in terms of sparql. I've tried to do something similar in the JosekiStore class. In case of update:

1) SMWSemanticData $data
2) $export_data = SMWExporter::makeExportData($data);
3) $triple_list = $export_data->getTripleList();
4) $insert_string = "INSERT DATA { " . serialize_triples_to_string($triple_list) . "}";
5) http_post($endpoint, $insert_string);

Seems pretty straightforward.


From: Markus Krötzsch <markus@semantic-mediawiki.org>
To: semediawiki-devel@lists.sourceforge.net
Sent: Fri, September 24, 2010 12:27:25 PM
Subject: [SMW-devel] [RDF] store architecture proposal

This email is about how to integrate RDF store bindings into SMW on a
coarse architectural level.

From looking at the various extensions' code and at the previous
emails, we seem to agree that we need some common interface to
read/write RDF stores. Different bindings could then be done by
implementing this interface.

Here is my proposal for the classes that will help to do this in the end
(inspired by the existing code):

== SMWStore ==

SMW as such interacts with an object that implements the "SMWStore"
interface. This interface will be extended with functions needed to do
SPARQL queries. Details depend on how the mapping to SMWQueryResult
objects will work and remain to be decided.

== SMWExternalStore ==

An SMWStore that has bindings to an external RDF store still uses the
MySQL database backend for some of the data. Some requests are answered
with the database, others are forwarded to the external store.

So any SMWExternalStore uses two backends: one RDF store binding and one
(database-based) SMWStore class. In existing implementations, this is
often realised by sub-classing SMWSQLStore2. But I think it would
usually be better to use SMWSQLStoreLight.

To preserve the choice, SMWExternalStore could simply take two objects
on initilaisation: one SMWStore object that is used for the basic
storage tasks, and one RDFStore object that allows us to access the RDF
store. Implementers would not have to change SMWExternalStore, but only
adapt the RDFStore binding to a new RDF backend.

== RDFStore ==

This would be the backend to access RDF stores. It is similar to the
SparqlTools static class in LinkedWiki. I propose to make it non-static,
so that the endpoint and graph can be part of the object instance
instead of being passed with each call.

The big question is, which functions are needed in the interface of
RDFStore. I will send another email about this.

== Other RDF store bindings ==

For implementing bindings to RDF stores, it would be enough to implement
the interface of RDFStore (hopefully just a few methods). So we could
have a few rather small files for different backends.

Summary: To define an SMWStore backend that uses an RDF store, one only
has to implement a new RDFStore subclass "MyRDFStore" that can
communicate with the store. One then creates a new SMWStore as an
instance of SMWExternalStore that is initialised with two objects: basic
SMWStore (e.g. SMWSQLStoreLight) object and a MySQLStore object. The
MySQLStore object would possibly need information about the service
endpoint and graph name for initialisation (but this depends on the
implementation; some stores do not support graph names, and others are
not accessed by a service endpoint).

-- Markus

Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
Semediawiki-devel mailing list