On 26/08/11 15:31, Chris Davis wrote: > Am I correct in observing that SMW 1.6 does not support sparql queries > directly included in wiki pages, but only allows for ask queries which > are then translated into sparql syntax? > > The reason for the question is that I'm one of the developers of the > SparqlExtension, and would like to migrate to SMW 1.6. However, I've > become somewhat addicted to/dependent on the more advanced features of > sparql such as federated queries, type conversions, custom functions, > etc (see http://enipedia.tudelft.nl/ for what this enables). > > Is this something that will be eventually integrated in the core code, > or am I better off for the moment setting up an extension that enables > this more advanced functionality with SMW 1.6?
We recently discussed that this would be nice to have in the core, but that some more work is needed to get it there. There are certainly various parties who would be interested in this feature, but someone needs to take the lead in implementing what remains to be done to get this into SMW. Below are some facts to summarise the status. What SMW 1.6 provides is support for SPARQL to the extent needed to have a SPARQL-based backend for query answering. So the following functional components are in SMW: * a SPARQL communication abstraction, similar to MW's DataBase * SPARQL result parser for the standard XML result format * Some basic mechanism for interpreting SPARQL elements (esp. URIs) as WikiPages; could be extended to wrap literals into accoding SMW data items as well * SMW-data to RDF translation * #ask to SPARQL translation that works with the SMW-data to RDF translation in the sense that the results over SPARQL/RDF should be the same as over SQL What is missing to support #sparql-ike queries to external SPARQL services from the wiki: * some mechanism to deal with slow and dead SPARQL services to ensure that they do not delay page display; maybe some asynchronous result loading + caching; * some mechanism to configure available SPARQL services to avoid people having to enter the full URL when sending a query (this is also a possible security issue); * extended SPARQL result interpretation to wrap all elements (URIs, literals) that occur in results into SMW data items that can be displayed to users * adaptor code that allows all existing query printers to act on SPARQL results thus reeived (probably implement a "virtual" store that only retrieves data that came from one SPARQL query); * add an #ask-like parser function to make this available to users Asynchronous retrieval and caching seem to be the hardest problems here. Caching could possibly be built into the existing SPARQL communication abstraction layer. What is missing to have SMW itself provide a SPARQL service to the outside world in general: * a parser for SPARQL queries (could be a library), * code to translate SPARQL queries into SQL queries over SMW's database The second item is a lot of work. Alternatively, one can of course simply connect SMW to an RDF store and let this store provide the SPARQL endpoint. This seems more viable but then SPARQL is not a standard functionality of SMW. Regards, Markus ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
