Hi Michael, what you would like to do is probably not possible in SMW right now, but it might be possible to get it working. When using an RDF store, SMW stores (copies of) its data there and queries the store to obtain result lists for #ask. However, all simple data lookups are still done through the SQL database backend. So, for example, if you have a table generated by #ask, then SPARQL will be used to find out which results are in the table (one result = one row). But the contents of the table cells (property values) still come from the database.
There have been extensions to SMW that allow you to SPARQL query (directly) external data sources, but that was not integrated with wiki data. In principle, it would not be too hard to re-wire all of SMW's data access to the RDF store if desired. Some development is needed to do this, but I think only in two or three files. There are two main tasks: * The individual data access methods of the SMWSparqlStore implementation would have to be implemented to run and return results from SPARQL queries. Currently this code just inherits from the SQL store and overwrites very little of its public interface (see SMWStore for documentation of the available methods). For getting SPARQL to access the RDF store, it should be enough to implement the methods that returns all data about one subject (getSemanticData). The method that gets data values for one subject and property largely is based on getSemanticData. Overall, this should not be too hard, but it needs to be done. The SQL store code is more complicated, since it needs to fetch data from many tables and since it uses caching (though you might want to use that too) -- SPARQL might actually be comparatively simple. * SMW's SPARQL binding/RDF mapping code must be extended to be able to read values from SPARQL results that have datatypes other than Wikipage. Currently, there is no code to read, say, a number that is returned by a SPARQL query (but there is code to parse SPARQL query results in general; just the specific value parsing is missing). One could also defer this task and start with wikipage property data only to see how it goes. Another challenge in the SPARQL result parsing might be that the SPARQL result interpretation in SMW is not really designed to process result tables of the form "Property|Value" where value could contain literals of any type. Maybe one needs another access method in the SPARQL code to turn this into a SemanticData object. Note that you also need to make sure that the SMW datavalue ends up in a single RDF value (e.g., coordinates have latitude and longitude, but there should also be a string encoding that combines both for retrieval). If a datavalue is spread across multiple triples, then it would be much harder to retrieve it. I would rather add a value to SMW's RDF export for convenient access than to write a more complicated access method. One thing to be checked (I don't recall) is the use of graph names in SMW. I think SMW stores all of its data in one graph, so it would be unproblematic to store more data with the same URIs as long as it's in a different graph. The question then is how normal SPARQL queries use the graph setting (otherwise you might find that your new data is not shown even after extending methods as required). I guess it is clear, but what you will of course never be able to do is to modify RDF data that was written by SMW in the RDF store. The data that SMW stores is taken from wiki pages and changing the data in the RDF (or in SQL) won't change the pages. So the next time somebody edits a page (or a refresh job happens), the old data would overwrite the new. Cheers, Markus On 06/08/13 14:59, Michael Färber wrote: > Hi all, > > I have SMW with a triple store (Virtuoso) connection and want to store > additional structured data into this triple store by an external tool > (by accessing the triple store access point directly with SPARQL, i.e. I > add triples externally). Is there a viable way to get this added data > (properties) shown in the SMW frontend/pages? Whenever I insert triples > in the triple store, SMW ignore these, although I took care of the URI > naming conventions. > It seems that SMW also considers the triples in the MySQL DB. Can't I > just determine that SMW should only consider the triplestore structured > data? > I have heard of using a separate graph in the triple store for storing > and quering triples I added by myself externally, but using only one > graph would make life much easier in my opinion, since I use the same > properties. > > Thank you very much for your support. > > Best, > Michael > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
