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).