Here it is: the first fully featured release of SemanticXO! Use it in your activities to store and share any kind of structured information with other XOs. The installation procedure is easy and only requires and XO-1 running the operating system version 12.1.0. Go to the GIT repository and download the files “setup.sh” and “semanticxo.tar.gz” somewhere the XO (these files are in the directory “patch_my_xo”). Then, log in as root and execute “sh setup.sh setup”. The installation package will copy the API onto the XO, setup the triple store and install two demo activity. Once the procedure is complete, reboot the XO to activate everything.
There are two demo activities which are described in more details on the project page. Under the hood SemanticXO provides an API to store named graphs containing description of one or several resources. These named graphs are marked with an author name, a modification date and, eventually, a list of other devices (identified by their URI) to share the graph with. This data is used by a graph replication daemon which every 5 minutes browse the network using Avahi, find other triple stores, and download a copy of the graphs that are shared with it. The data backend of the mailing activity provides a good example of how the API is used.
A few days ago, I posted about SemanticXO and how you will see how to install a TripleStore on your XO. Here are the steps to follow to compile&install RedStore on the XO, put some triples in it and issue some queries. The following has been tested with an XO-1 running the software 10.1.3 and a MacBookPro running ArchLinux x64 (it’s not so easy to compile directly on the XO, that’s why you will need a secondary machine). All the scripts are available here.
Installation of RedStore
RedStore depends on some external libraries that are not yet packaged for Fedora11, which is used as a base for the operating system of the XO. The script build_restore.sh will download and compile all the necessary stuff. You may however need to install external dependencies on your system, such as libxml. That script only takes care of the things redstore directly depends on, namely raptor2, rasqal and redland (all available here). Here is the full list of commands to issue:
mkdir /tmp/xo cd /tmp/xo wget --no-check-certificate https://github.com/cgueret/SemanticXO/raw/master/build_redstore.sh sh build_restore.sh
Once done, you will get four files to copy on the XO and if you don’t, you can also download this pre-compiled package. These files shall be put all together somewhere, for instance “/opt/redstore”. Note that all the data redstore needs will be put into that same directory. In plus of these 4 files, you’ll need a wrapper script and an init scripts. Both are available on the source code repository. So, here what to do on the XO, as root (replacing “email@example.com” by the login/IP accurate for you) :
mkdir /opt/redstore scp firstname.lastname@example.org:/tmp/xo/libraptor2.so.0 . scp email@example.com:/tmp/xo/librasqal.so.2 . scp firstname.lastname@example.org:/tmp/xo/librdf.so.0 . scp email@example.com:/tmp/xo/restored . wget --no-check-certificate https://github.com/cgueret/SemanticXO/raw/master/wrapper.sh chmod +x wrapper.sh cd /etc/init.d wget --no-check-certificate https://github.com/cgueret/SemanticXO/raw/master/redstoredaemon chmod +x redstoredaemon chkconfig --add redstoredaemon
Then you can reboot your XO and enjoy the triplestore through its http frontend, available on the port 8080 🙂
Loading some triples
Now that the triple store is running, it’s time to add some triples. The SP2Bench benchmark comes with a tool (sp2b_gen) to generate any number of triples. To begin with, you can generate 50000 triples. That should be about of the maximum amount of triples an XO will have to deal with later on when the activities will store data in it. Here is what to do, with “192.168.1.104” being the IP of the XO:
sp2b_gen -t 50000 rapper -i guess -o rdfxml sp2b.n3 > sp2b.rdf curl -T sp2b.rdf 'http://192.168.1.104:8080/data/http://example.com/data'
It takes about 43 minutes to upload these 50k triples which gives an average of 53 milliseconds per triple or 19 triples per second. That’s not fast but should be enough to have an API allowing to store a bunch triples with an acceptable response time. The data takes 4Mo of disk space on the XO for an initial RDF file of about 9.8Mo.
Issue some queries
The SP2Bench benchmark comes with a generator for the triples and a set of 17 SPARQL queries expressed over this data. The queries are of changing complexity in order to benchmark different triple stores. Unfortunately, 9 of them where to complex for RedStore on the XO, with these 50k triples. These queries where not solved, even after being executed over a full night! The 8 remaining queries are solved without much problems, as long as you have enough time to wait for the answer:
|Query file||Execution time|
The queries have been executed using the “sparql-query” command line client that way:
cat q2.sparql | sparql-query http://192.168.1.104:8080/sparql -t -p -n
The long delay can sounds as a bad news but it must be noted that this was with 50k triples and with queries designed to be tricky in order to test triple store capabilities. Considering a normal usage with fewer triples and more standard queries, we can expect things to go better.