La Casa nel ~Mare~Running away from slavery

In this blog post I’ll make references to my last weekly status report blog post.

I discovered that what I called ‘fromFile’ or fromSource’ properties are already always included in every sensor data instance within the ‘Resource’ field LOL.
However there are some cases in which such properties should be included intentionally because of their utility, for example as a sensor retrieves information about a developer’s focus changing from one source to another one. Then I’ll still check if those properties are available.

Today I made my Restlet server providing more complex RDF data when someone looks up for resource of type ‘File’. This took me a little bit of time but I should be faster with all the other resource types as the mechanism is similar, and I’m going to explain some clue part of it here.
As I have a statement to be added to the model, I check if a statement with the same subject and predicate has already be added, and in case of a positive answer, I add the new one (substituting then, the previous one) only if the time at which that old one statement has been collected (that is the timestamp of its related sensor data) is equal or less recent than the collection time of the new one.

Now every URI is dereferenceable but the information provided by the server for each URI is very poor with the except of the resource types project, user, sensor data type, sensor data, file. I have to enrich info provided for all the other resource types.

Example of info provided as asking for the resource URI:
http://localhost:9875/linkedservicedata/source/file/__home__myrtill__Hackystat_linkedData__mysqlProva__workspace__hackystat-linked-service-data__src__org__hackystat__linkedservicedata__resource__sensordata__SensorDataResource.java

(every ’slash’ within the ‘fullPath’ field is substituted with a sequence of two consecutive underscores)
(consider that I manually sent very few sensor data information and a little set of all the properties that could be set have been set, so this server answer has only a little set of all the information potentially providable).

(I’ve deleted all the ‘<' and '>‘ because of Wordpress conflicts)


http://localhost:9875/linkedservicedata/projects/myrpandemon@yahoo.it/Default a http://usefulinc.com/ns/doap#Project ; http://dasha.ics.hawaii.edu:9875/linkedservicedata/vocab/ended "2010-01-01T23:59:59.999-10:00" ; http://dasha.ics.hawaii.edu:9875/linkedservicedata/vocab/modified "2009-05-24T18:02:33.401-10:00" ; http://usefulinc.com/ns/doap#created "2000-01-01T00:00:00.000-10:00" ; http://usefulinc.com/ns/doap#description "The default Project" ; http://usefulinc.com/ns/doap#maintainer "myrpandemon@yahoo.it" ; http://usefulinc.com/ns/doap#name "Default" .

In the next morning I’m going to write my weekly status report, don’t worry.
However I’ve implemented a restlet server which provides data coming from the Sensorbase service as RDF following a planned schema. I’m achieving the first three linked data principles:
- Use URIs as names for things
- Use HTTP URIs
- Provide useful information in RDF when someone looks up a URI
using external pre-existing vocabularies, too. Tomorrow it should be published the REST API for the resource types that I’ve created, while I already frequently commit the svn repository hosted on Google code.

As stated in my last weekly status report blog post I gave up with mapping files and relational databases. Today I finished a class which provides RDF models including all the data retrievable from the sensorbase (I used the SensorBaseClient) which are Project, Sensor and User data. It checks every time if the user logged in has the rights to access those data required to construct a proper model. In particular it’s possible to get out:

• all the sensor data for a given sensor data type and user (which must be the same of the logged-in user)
• all the user data for a given user (which must be the same of the logged-in user or must have the role of ‘Project Manager’
• all the project data for a given user (which must be the owner, spectator or member of that project

Additionally all the RDF models available in cache and representing data accessible to the given user, are unified with the model containing one of the provided information, described above. It’s used the UriCache provided by the Hackystat Utilities component (which uses Apache JCS), and models are grouped by user names. When a request for a model containing a certain kind of information arrives, the system firstly check if the uri obtained in one of the following ways

• for user data: userName(replacing the ‘@’ with ‘_at_’ to avoid the arising of possible conflicts with the O.S. because of rules in creating file names)
• for project data: userName(as above)/projectName
• for sensor data: userName(as above)/projectName/sensordatatype

is stored in the group cached data identified with the logged-in user name.
I know that there are lots of additional filters that could be specified to retrieve sensor and project data, such as the time stamp, but for the moment, I prefer to limit to these ones because I’m imagining a situation in which a user explore RDF data through a graph visualized in the GUI. He firstly visualize only the nodes representing classes in that graph and then clicking on “one” class (such as a sensor data type or the project or user class) he expand it to view all the related data plus all the other data avilable in cache, in such a way that even if it’s not possible to visualize the whole graph for performance reasons, he’s not limited to the graph portion selected but can although view other little portions.

Also I know that Apache JCS is not thread safe and I’m going to treat this issue from application level as the DPD service already does, that is through a HashMap between user names and client instances (there should be only one client instance for a unique user name). In the case of LinkedServiceData (I finally decided to call so my component) there would be as many user/client maps as the number of services from which is possible to retrieve useful RDF data (which currently is only the sensorbase but I’m going to implement RDF representations also for the DPD, Telemetry and maybe Tickertape data, too).
I’m going to organize all the packages etc. following the DPD project directives.