W3C home > Mailing lists > Public > public-xg-ssn@w3.org > February 2012

Re: [via Web of Sensors Community Group]

From: Myriam Leggieri <myriam.leggieri@deri.org>
Date: Wed, 22 Feb 2012 16:05:31 +0000
Message-ID: <4F45124B.8090504@deri.org>
To: Marcos Caceres <w3c@marcosc.com>
CC: Peter Waher <Peter.Waher@clayster.com>, Arthur Barstow <art.barstow@nokia.com>, "public-sensorweb@w3.org" <public-sensorweb@w3.org>, "public-xg-ssn@w3.org WG" <public-xg-ssn@w3.org>, Manfred Hauswirth <manfred.hauswirth@deri.org>, Michael Hausenblas <michael.hausenblas@deri.org>
Hi Marcos,

On 22/02/2012 14:08, Marcos Caceres wrote:
> Yes, that is exactly correct. Once we can actually talk to sensors in 
> the browser, then we can start to network then together into 
> "semantic" networks. But the first step is just to be able to talk to 
> them "natively", which currently we don't have a means to do through 
> Javascript.
>    
if I've correctly understood what you mean (please correct me 
otherwise), then we currently have such "direct access", among other 
things, in SPITFIRE (as Manfred already pointed out in the meantime).  
In the SmartServiceProxy [1] sensor data and sensor-related data are 
directly accessible, and even more interestingly, they can be aggregated 
based on the real thing they are associated to (becoming part of what 
we've called a "Semantic Entity", SE). You can not yet access the 
service right now, because of privacy policies (since sensor readings 
come directly from work offices), but a screenshot is attached here and 
a journal article is under review, where we evaluated the system against 
a use case and a real experiment.

In the screenshot you can see a list of sensor data descriptions which, 
thanks to them following Linked Data principles [2] (we used the SSN 
ontology which is included in the SPITFIRE one):
- are accessible through HTTP (important factor as you stated in your 
previous email)
- each particular data encoded in the descriptions can be directly 
accessed by a SPARQL query. The advantage over an ad-hoc API is that 
these are all either well established W3C (Web :) ) standards or W3C 
recommendations (almost standards). Here you can see one of the 
advantages of using Semantic Technologies.

> I don't agree that a "semantic sensor network" needs to be defined in terms of semantic web technologies. You can have a perfectly "semantic" network without the use of those technologies.
>    

Semantics of course, as you said, can be expressed in any data 
representation you prefer. Even while choosing an ontology everyone can 
choose any of the available ones or create a new one. But it's proved 
the convergence on specific ones, in the long-run.


> it sounds a bit presumptuous to assume the Semantic Web stuff can address the use cases of a networked set of sensors before we know what the use cases are)

I definitely agree that it's presumptuous (and inconclusive, too) to 
assume Linked Data can solve all the sensor related issues, without a 
proper use case and experiment in which the advantage of one approach 
over the several others is clear and evident. To clearly show such 
advantage is the current goal of my PhD research, indeed :)


> However, if the Semantic Sensor Network CG wants to exclusively focus on the application of Semantic Web technologies to constructing semantic sensor networks, then that gives us a good point of difference/departure. The Web of Sensors CG can focus on a more generalized framework that does not rely on Semantic Web technologies (unless there is a demonstratively beneficial reason to do so that would benefit the Web at large).
>    
Actually a list of clear, concise, list of issues addressed by both SSN 
CG and Web of Sensors CG, with corresponding different proposed 
solutions, should be good starting point for a collaboration.


Kind regards,
Myriam


[1] http://www.slideshare.net/SPITFIRE_EU/smart-service-proxy-11705804
[2] http://www.w3.org/DesignIssues/LinkedData.html



ssp_screenshot.jpg
(image/jpeg attachment: ssp_screenshot.jpg)

Received on Wednesday, 22 February 2012 16:06:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 February 2012 16:06:52 GMT