During the last week I tried to modify the automatically generated mapping file in order to make it follow the planned rdf schema. That’s because I was thinking about taking advantage of the already existing sensorbase DB. However while exploring that DB, I noticed the strange absence of some constraints and fortunately I opened a discussion on the hackystat-dev ml. This was a fortune because during that discussion appeared that the usage of a relational db (and then the required mapping file) was not a good approach to persist the RDF dataset because the DB schema currently changes between different implementations for different back-ends, and could change also in future Hackystat releases. Moreover there should be the need for storing DPD, Telemetry and other more abstract data, which result in a very large amount of data. For these same reasons persisting the RDF model in the file system has to be excluded, too.
The only remaining choice is the in-memory storage mechanisms, which is really time and resource consuming. In order to limit these issues I proposed the following solution:

Initially only a really high level graph is provided to the users , showing only the class hierarchy. Then a user could choice to get a detailed view for only the particular parts of the graph that
- requires data already added to a cached model
and/or
- requires to query only one Hackystat service. The query result is then added to a model that is cached in a way similar to the DPD caching mechanism.

Moreover during the last week I created a sample project to illustrate the in-memory creation of a RDF model. I represented only the portion of the planned RDF schema involving the Code_Issue class (and then the Issue, Tool, Project, User, Strenght, Code_Quality and RawSensorData classes) using data extracting from the sensorbase through the sensorbaseclient, and then:
- list all the statements
- list only the statements having RDF:type as predicate and CodeIssue as object
- list only the statements having RDF:type as predicate and CodeQuality as object (this requires a reasoner to properly access the hierarchy through the subClassOf statements).
(see the ModelConstructionExample.java class).

For the next week:
It seems that the proposed solution described above to persist the RDF model has been approved on the mailing list. Then I’m going to:
- search for information about the DPD caching mechanism to use it also on my RDF model;
- extend the hackystat.rdf schema used in the sample project to include the whole planned rdf schema and start implementing the cache mechanism.