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/
