Dear All,

I can completely agree with Karima. For the connection to the triple store (TS) we should have an interface that people can implement the way they want, depending on the implementation of their triple store.
The interface Karima describes looks very similar to the SMWStore. And I like the idea of extending SMWStore to get things done with minimum rewrite.
In case of the SparqlExtension we extend SMWStore and achieve the functionality with minimum effort.
I would suggest to create an abstract class (and interface) SMWTripleStore to extend the SMWStore and provide a bunch of utility/helper methods (semanticdata_to_triples :-).
That would take care of the writing to the TS.

Now getting data from the TS is a different question. Also there's a related question of the integration with the SRF.


From: Karima Rafes <>
To: Markus Krötzsch <>
Sent: Mon, September 20, 2010 2:19:55 AM
Subject: Re: [SMW-devel] [RDF] Discussion


I'm very tired so I will be short.

Only 2 truths :
1) SMW has always raeson. The triplets in RDF of one page IS the result of the query select * where {<page> ?p ?v} in the triplestore.
2) the customer has always raeson.

So :
1) Any extensions rdfIO or halo, etc haven't to change the graph of SMW. So the user can change the extension and triplestore without redevelop its sparql clients. One word : Interoperability.
2) if you keep your old triplestore with sparul or other protocol, the customers will choose the old or the triplestore full compliant W3C. SMW is a project free so if others extensions want wait the final recommandation, they can keep the current version of SMW and write in their specifications their version of smw.

My proposition :
To respect the first truth, the extension sparql need to have two things in SMW :
- Hook update/insert/delete/refreshall/deleteall data of swm : call class inherit of InterfaceTripleStore
- Contract InterfaceTripleStore{

 $IriPage : IRI not URI. I have to have accent in the IRI (sorry I speak french, lol ) and replace only space by underscore. RDF cannot use IRI but in the recommandation sparql in the triplestore, it's one <IRI>. For the value, you have to insert the tag langage ie the langage of wiki.
$arrayTurtle : one array with 3 column. one field is a IRI (again) or one value like define in the recommandation of sparql 1.0.
$graphName : usually it's the domain name of wiki example :

you can use my class to build the parameter arrayTriplets for one first version.
For the Hook, the code of SMW is too dark for me. Sorry.

It's simple ;) ... it's one minimum. After, we can speak of the future architecture of SWM with a triplestore or fork SMW...

To respect the second rule :
Do nothing, the best will win. In one year, you can ask a survey and so you will can copy and paste the code of the best extension in the SMW. (Geek rule 1 : never reinvent the wheel and copy/paste is your best friend. )

Sorry for my english,

2010/9/19 Markus Krötzsch <>
On 18/09/2010 18:35, Samuel Lampa wrote:
> On 09/18/2010 03:22 PM, Markus Krötzsch wrote:
>> On 18/09/2010 15:05, Alfredas Chm wrote:
>>> As the first thing on the agenda, I would like to ask Markus to create a
>>> page (and add permissions) on the
>>> <>   to put the info on the separate
>>> extensions, comparisons - to be used later as the basis for the discussion.
>> Done (at least a stub):
> Great! Had interesting read on
> Especially this section drew my attention:
> ... so let me add some inline comments (This might be aspects you were
> discussing/regarding already, but just to make sure):
> Wikipage wrote:
>> ... needs to be extended with a function that takes SPARQL queries and that returns SMW query result objects
> For this kind of processing SPARQL/RDF etc with PHP, I'd like to
> highlight the huge benefit of keeping ARC2 in the picture ... it has
> really been an amazing productivity igniter, not so much for its RDF
> store and SPARQL Endpoint as for its super-convenient data structures
> and methods for processing SPARQL, RDF (and its variants). I cannot
> imagine having succeeded with RDFIO in time without all that and there
> also seems to be quite some converge on ARC2 as the library-of-choice
> for other PHP based projects as well (The upcoming Drupal 7, which has
> RDF export turned on by default, etc.)

The core of SMW should not be dependent on ARC2, though. The idea is to
completely delegate SPARQL processing to the external store, and to keep
SPARQL queries opaque to SMW. The only new SPARQL syntax processing
required in SMW would be the processing of SPARQL query result
documents. They are probably not so hard to parse, but one could also
consider copying code from ARC2 to get this done. AFAIK existing
extensions that implement RDF store bindings in this way did not require
much extra RDF/SPARQL handling code for this approach.

> Though maybe that is what was thought of, with the line further below:
>> Direct bindings to ARC2 (via PHP)

I would appreciate to have support for using local ARC2 stores directly
through PHP, without running it as a web service. This would also allow
some of the RDFIO code to move to SMW Core (the SMW-SPARQL-Update
functionality via SMWWriter would remain an extension, but could
possibly be integrated with SMWWriter).

> Anyway, so next thing:
>> Generic SPARQL/SPARUL SMW store implementation that can connect to different RDF stores supporting these standards
> Noting though that there are currently more than one standard for
> updating. ARC2 currently uses SPARQL+ [1], while waiting for
> SPARQ:/Update to stabilize, and standards seem to be a bit of a moving
> target still, so it'd probably be good to make things as generic as
> possible, in order to support multiple/changing standards.

Yes, and it might be necessary to do some changes to the update language
before the recommendation is completed. In the worst case, this would
reduce our "generic" RDF store support to one or two systems that
support our preliminary version of the SPARQL update language. But as
soon as SPARQL 1.1 is out, these intermediate restrictions will vanish
(and the main architecture of SMW's SPARQL support would not be affected
by this).

> In general, all these envisioned strategies seem to require ability to
> run more than one store. So, is that possible today (There is the
> $smwgDefaultStore config setting, but that only takes one store AFAIK, etc)?

I do not plan to use multiple SMWStore objects at the same time now. The
RDF store bindings will work like the current implementations: as
write-through extensions of an SQL-based store (the SQL binding will be
simpler since the query part is fully delegated to the RDF store, but
copies of annotations will still be kept locally).



Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
Semediawiki-devel mailing list