Re: [ANN] Semantic MediaWiki 1.6.0 supports SPARQL 1.1 RDF stores

On 03/08/11 18:29, Kingsley Idehen wrote:
> On 8/3/11 1:06 PM, Markus Krötzsch wrote:
>> We are happy to announce the new major release
>>
>> SMW 1.6.0
>> Semantic MediaWiki
>> http://semantic-mediawiki.org/
>>
>> SMW is a popular free and open source content management system based
>> on the MediaWiki software that powers Wikipedia [1]. It adds
>> capabilities of semantic data management, querying, and export. Many
>> extensions to SMW are available for adding further features ranging
>> from faceted data browsing to RDFa support.
>>
>> SMW 1.6 newly adds support for using SPARQL-compatible RDF stores for
>> managing data (including query answering).
>
> So you mean: SMW is no longer inextricably bound to MySQL? I can just
> point it to a SPARQL compliant DBMS?

Yes and no:

The wiki data of MediaWiki is stored in a relational SQL database, and 
you will always need such a database to run a MediaWiki site at all. SMW 
also takes advantage of this to store data. However, it does not have to 
be MySQL. At least PostgreSQL also works well (with MediaWiki and all 
SMW functions). I am not sure about the status of other backends such as 
Oracle. SQL stores have very diverse ways of interpreting the standard, 
so many queries must be tweaked specifically for one system.

Meanwhile, the SPARQL stores in SMW are used to manage all semantic data 
and to execute all complex queries over that data. This means that you 
can directly access the SPARQL store to use the data instead of relying 
on wiki services. It also means that you might get better query 
performance if the RDF store is fast.

>
>> This is possible by exploiting the new SPARQL 1.1 Update capabilities
>> for writing, and SPARQL Query for accessing semantic data. See [2] for
>> details. Completely rewiring SMW queries to SPARQL requires many
>> different SPARQL features which is an interesting testbed for RDF
>> stores. The main system used for development was 4Store which worked
>> quite well. Virtuoso has been tested successfully too, but the graph
>> support in SMW is currently a bit limited so adjustments are needed
>> there (will be fixed in upcoming versions). Feedback on experiences
>> with other RDF stores in combination with SMW is welcome.
>>
>> Other changes in SMW 1.6.0 include:
>>
>> * Added UNIX-style DSV (Delimiter-separated values) result format.
>> * Added full support for PostgreSQL database backends.
>
> Hmm. does this mean MySQL and PostgreSQL as opposed to ODBC accessible
> RDBMS backends? If so, why? It just doesn't need to be so ODBC is
> actually more powerful than any native RDBMS specific API, and
> substantially so.

DBMS access is managed by MediaWiki through a database abstraction layer 
that takes the varying (in)capacities of different RDBMS into account. I 
am sure that the MediaWiki developers will appreciate suggestions on how 
to improve this system, if you have concrete ideas. But this is not 
related to SMW.

Our choice to specifically improve our PostgreSQL support was due to 
popular demand among our users.

>
...
>>
>> It is planned to further extend the SPARQL support for SMW, first by
>> adding special handling to exploit features of important RDF stores
>> (e.g. there already is special code for 4Store that exploits its
>> resource limit features). Moreover, connectivity to other external
>> SPARQL endpoints might be added (given that SMW already includes a
>> SPARQL result parser and a SPARQL query builder).
>
> You have to make a loosely coupled solution. The technology
> infrastructure is in place.
>
> You should be able to speak about SMW without provisos for: 4Store,
> Virtuoso, MySQL, PostgreSQL. It is a chunk functionality that doesn't
> need an DBMS (graph or relational) backend specificity.
>
>
> Anyway, I'll take a look at what can be done re. this critical final
> mile decoupling :-)

Good luck with that! You may find that, in practice, the capabilities of 
these systems are very different, and that there is no completely 
unified way of talking to them. Many systems offer additional 
"non-standard" features that are specifically dear to their users, and 
that one wants to support when using them. For example, our applications 
of 4Store specifically are motivated by its non-standard resource limit 
feature that aborts query execution if a query takes too long. Also, not 
all features of SPARQL 1.1 are implemented in all stores, so one needs 
to implement workarounds in some cases (we have done this for 4Store to 
get INSERT ... DELETE ... working).

>
> Anyway, thanks for the significant improvements as outline above, still
> a zillion times better than the old architecture.

Thanks. I am positively surprised that you are actually familiar with 
the previous architecture.

Markus

-- 
Dr. Markus Krötzsch
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
+44 (0)1865 283529               http://korrekt.org/

Received on Wednesday, 3 August 2011 19:54:34 UTC