La Casa nel ~Mare~Running away from slavery

In the previous post I exposed the problem I was trying to challenge, which consists in using the sensordata table’s ’sdt’ attribute to refer to the proper sdt class.
Today I found that:

1. within the sensorbase db the sensordata table’s ’sdt’ attribute is not a foreign key referencing the sdt table’s primary key ‘name’. Then if I have to retrieve sdt info stored in the sdt table given a sensordata instance, I have two choices:
   1. changing the db schema in such a way that the sdt attribute becomes a foreign key referencing the sdtName attribute
   2. every time there’s a needing to retrieve info for a particular sdt, I could forward the request to the sensorbaseclient or create an ad-hoc sparql query, referring directly to the sdt table, without using any connection with the sensordata table. Then I could insert the retrieved info in the Jena model.
2. Planning the RDF schema I thought of inserting the existing SDT into a hierarchy according to their meaning. If in future will be created new SDT they could be represented in the hierarchy as direct children of the first common parent of all the sdts, which currently is the ’skill’ class.
3. the relationship that has been planned to exist between the class representing the existing sdts and rawsensordata is a rdfs:subClassOf relation. RawSensorData is the superclass and every sdt is a sub-class (a particular kind) of it, inheriting all its properties and adding new ones. However this relation is hard to be represented in the mapping file, because within the sensorbase db there is not a table for each distinct sdt and because, at last but not at least, D2RQ does not support the rdfs:subClassOf predicate. It does not support it, because, according to what stated by one of its creator:
   

   “as long as there are no reasoners around that can handle the big data
   sets onto which D2R Server is aiming, we won’t integrate a reasoner into D2R
   Server and first try to get the data integration issues right. Maybe
   reasoning is also not a task for a RDF data server, but more a task for
   client applications, which want to do smart stuff with the data.”

   It’s suggested a trick to avoid the problem:

   A hack that we frequently use to handle basic subsumption hierarchies is to
   add additional rdf:type property bridges to the mapping for all desired
   superclasses.

   that is:
   
map:PersonsClassMap a d2rq:ClassMap ;
d2rq:uriColumn "Persons.URI" ;
d2rq:dataStorage map:Database1 .

   map:PersonsType a d2rq:PropertyBridge ;
d2rq:property rdf:type ;
d2rq:pattern "http://annotation.semanticweb.org/iswc/iswc.daml#@@Persons.Type@@" ;
d2rq:belongsToClassMap map:PersonsClassMap .
   in the mapping file, when in the schema subclasses of the person class are declared, as professor, employee etc.

Tomorrow I’ll better understand how the trick used to avoid the subClassOf issue works, and I’ll try to query the sensorbase client to get sdt info, given a sd instance, trying also to simulate from code other subClassOf relationships (I would have to add some class that are not contemplated in the db, manually to the Jena model).

I managed to use Derby with the D2RQ Platform and now I’ve got a mapping file (mapping between ontology and relational data model, containing statements written in the “D2RQ Mapping Language”) and a schema, that have been both automatically generated by the D2RQ platform proper scripts. I created a sample Java project to print data taken from the virtual read-only RDF graph, created over the relational databases by the D2RQ engine thanks to the mapping file. In fact the D2RQ engine uses the mapping file to rewrite Jena API calls to SQL queries against the database and passes query results up to the higher layers of the frameworks. That sample project comprehends calls to the Jena’s model, Jena’s Graph API and to the Jena’ARQ engine to process SPARQL queries.
The automatic generation of the mapping file required a username and password to access the database and then I set them for the sensorbase db even if they were not originally required, adding the following lines to the derby.properties file:

derby.database.propertiesOnly = true
derby.connection.requireAuthentication=true
derby.database.defaultConnectionMode=fullAccess
derby.database.fullAccessUsers=myrtill
derby.database.sqlAuthorization=true
derby.user.myrtill=passw3084

Then those username and password have been utilized in the mapping file to access the sensorbase db.
I uploaded my own project to the Subversion server provided by the Google code hosting service. Use this command to anonymously check out the latest project source code:

# Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://hackystat-linked-sensor-data.googlecode.com/svn/trunk/ hackystat-linked-sensor-data-read-only

Now I have to perform changes over the mapping file to make it follow the planned RDF schema. Firstly I have to change the following lines in the mapping file:

map:SENSORDATA_SDT a d2rq:PropertyBridge;
d2rq:belongsToClassMap ;
d2rq:property vocab:SENSORDATA_SDT;
d2rq:propertyDefinitionLabel “SENSORDATA SDT”;
d2rq:column “APP.SENSORDATA.SDT”;

I must understand how to insert as the object of a triple, the uri common to every SDT class(Build, Cli, Dependency,etc.) concatenated with the literal value of the d2rq:column “APP.SENSORDATA.SDT” (instead of simple the value of that column), setting “rdf:type” as the predicate instead of “vocab:SENSORDATA_SDT”.
I’ll create an image representing the automatically generated schema, to make clearer the difference between it and the planned one.

Hi, this is the first chapter of the ‘Derby Saga: Myr vs Derby’ who will be the winner???
I found online that lots of people encountered “suddenly” an error like this:

ERROR 25503: DDL is not permitted for a read-only connection, user or database.

I couldn’t register to all the forums in which I found this problem unsolved to post my personal solution, then I’m going to report here my experience. I was using derby in network-mode and to adjust everything has been sufficient to run ./${DERBY_HOME}/bin/startNetworkServer as root, because it need to access to derby.log placed at ${DERBY_HOME} which requires root permissions.
That’s all. see you at the next chapter