RDF2RDB Version 0.53 by Michael Brunnbauer, netEstate GmbH 

This tool converts RDF data in several formats to a MySQL database.

Project homepage: http://www.netestate.de/De/Loesungen/RDF2RDB
You can contact me at [email protected]

Quick start
-----------

-Make sure that Python 2 is installed: http://www.python.org/
 The tool was tested with Python 2.6. If you have troubles with newer 
 2.x versions contact us.

-Install the MySQL module for Python: 
 http://sourceforge.net/projects/mysql-python

-Install the RDFLib module for Python:
 https://pypi.python.org/pypi/rdflib

Create a fresh MySQL database with default character set = utf8 and
adjust database credentials at the beginning of settings.py. Then run
rdf2rdb.py with one or several files or URLs containing RDF data in
a format supported by RDFLib:

./rdf2rdb.py http://www.w3.org/People/Berners-Lee/card.rdf

./rdf2rdb.py http://xmlns.com/foaf/spec/index.rdf http://www.w3.org/People/Berners-Lee/card.rdf

You can add more data to the database by calling rdf2rdb again. It uses 
the file rdf2rdb.pickle to save state information between runs. Tables and
columns may be renamed or dropped in incremental runs due to the additional
information that is considered and to avoid name collisions.

Call ./rdf2rdb without options to see available command line options.

If you have installed a plugin parser for RDFlib and are working with 
local files, you may have to add the filename extension in settings.py 
(filenameextensions).

Database structure
------------------

For every class a thing belongs to, a table with the class name is created:

 <class name>

The table contains at least these fields:

 <class name>_id (The primary key, an integer)
 uri (The URI of that thing)

Functional properties with a datatype are stored as columns in these tables:

 <property name> (The value of the property for the thing, NULL if not known)

Functional properties are properties with only one value for each thing.

Datatype properties connect things with data values (string, integer, 
date, etc). Object properties connect things with other things.

For object properties, a table is created for every class combination seen
with this property:

 <class name 1>_<property name>_<class name 2>

The table has the following fields:

 <class name 1>_id1 (The primary key of the thing in table <class name 1>
 <class name 2>_id1 (The primary key of the thing in table <class name 2>

For non functional datatype properties, a table is created for every 
class/datatype combination seen with this property:

 <class name>_<property name>_<datatype>

<datatype> is the internal datatype name ('string','int','boolean', etc.).
settings.py defines a mapping from datatype URIs (like 
"http://www.w3.org/2001/XMLSchema#integer") to the internal datatype name 
and from the internal datatype name to the MySQL datatype and an optional 
conversion function.

The table for a non functional datatype property has the following fields:

 <class name>_id (The primary key of the thing in table <class name>
 <property name> (The value of the property for the thing)

If a thing has several classes, it will be be contained in all 
corresponding class tables. The information about this thing specified
via properties will be replicated in all corresponding class and property 
tables unless a domain or range has been specified for the property in 
the RDF data.

In RDF, classes and properties are identified with URIs. The information
what names have been chosen for them in the database is stored in the 
table labels:

 uri (The uri of the class/property)
 dblabel (The name of the class/property in this database)

Also, for quick lookups of classes and primary keys of a thing, the table 
uris is created:

 uri (The uri of the thing)
 class (The class name of the thing in the database)
 id (The primary key of the thing in this table)

By default, rdfs:label and rdfs:comment are considered functional 
properties. You can change this behavior in settings.py

Every datatype property is created as functional property in the class 
tables and converted to a nonfunctional property with an extra table if
a second value for the property with the same datatype is seen in the data 
and the property was not declared as functional. This conversion only 
affects class/datatype combinations for which second values have been seen 
so a property can be "functional" for one class/datatype and "non 
functional" for another. If several different datatypes are seen for a 
functional property, the columns in the class tables are named 
<property name>_<datatype> instead of <property name>.

This deviance from the correct semantics of funtional and non functional
was made in consideration of messy data.

Non functional datatype properties are converted back to functional 
with a random value for each datatype chosen if the property is declared 
functional in the RDF data later.

Entailment
----------

All entailments of the following properties should be generated:

 rdfs:subClassOf
 rdfs:subPropertyOf
 rdfs:domain
 rdfs:range
 owl:equivalentClass
 owl:equivalentProperty
 owl:FunctionalProperty (currently supported only for datatype properties)

If you don't need this, you can use the command line option -n to disable 
entailments for better performance.

Things may also be faster if you parse ontology files first.

owl:Thing
---------

Things for which a class is not yet known are assigned the class owl:Thing.
The tables corresponding to owl:Thing are not very useful for a database 
user but are needed for incremental runs.

After every run, things that got stored initially there but got another 
class later are removed from these tables and all empty tables are 
removed.

You can drop all tables related to owl:Thing after a run by specifing the
command line option -r. Be aware that information may be lost that could 
be used in later incremental runs.

T-Box data
----------

If the tool recognises that information is about properties and classes,
it creates no tables in the database for it. This behaviour can be disabled
with the -t command line switch.

Language tags
-------------

Multilingual database schemas are currently not supported. You can specify
which language tags you consider relevant in settings.py (triples with 
other language tags will be dropped). The language information is not 
represented in the database.