I believe that incorporating SPARQL functionality within SMW is just a wrong approach - why not to implement querying any SPARQL endpoint?
This way one can import stuff into any SPARQL engine using RDFExport or implementing new SMWStore and just provide the endpoint for querying.
I have a feeling that SMW query representation layer (with all formatting and stuff) should be separate from actual querying layer so it can display any queries in SMW Ask or in SPARQL or in anything other query language that returns data in some predefined format ( e.g. SPARQL is simple enough to be such a format).
I understand that it might be a lot of work, but with large datasets querying speeds, inference and triple management will become a major issue and is probably better to shift to some specialized software like Openlink Virtuoso or Redland then to solve within SMW project.
On Sep 21, 2007, at 2:37 AM, S Page wrote:The SMWStore class provides a SQL-independent API to the storage layer, so I think you could implement it with a non-relational database and SMW would still work."Storing the data in a triples-based database in addition" is as I understand it the idea behind doing a bulk export into an external store.Maybe RAP (Rdf API for PHP) is far enough along for a talented developer to try it as an alternative storage layer.Wow, good info all around.I recall recently seeing info about ARC for PHP:Redland does indeed have PHP bindings these days:(Written by Dave Beckett of Triplr incidentally)I've used Redland to run SPARQL queries within tiny Rails applications in the past, but for anything sizable I'd recommend against it since Redland SPARQL doesn't optimize SPARQL queries - meaning you can get results back with an order of magnitude improvement just by moving the line-order of statements.I wonder what the DBpedia people would be able to add to this discussion.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Semediawiki-user mailing list