RE: [via Web of Sensors Community Group]

Hello all.

There's an obvious overlap in these two groups, just by reading the mail responses. Sorry if responding  to the wrong group.

Interesting to read about your individual contributions in the field, and that there are others actively working with open web standards (as well as other protocols) for sensor networks. I'm interested in the work made under SPITFIRE. Do you have a testbed where you invite 3rd parties? I'm very interested to see how different systems and sensor networks could interoperate using semantic technologies.

We're currently working with (among other things) small embedded residential gateways, that support SPARQL endpoints (JSON/XML/TURTLE) and both publishes and consumes semantic data from distributed resources using RDF/XML, RDFa, TURTLE, etc. We're also advocating an open service infrastructure not limited to certain platforms by inviting 3rd parties to work with us. Our main interest in semantic technologies is its loose coupling with underlying platforms, enabling 3rd parties to create services on-top of the sensor infrastructure without knowledge of the underlying systems/protocols involved, and without having to restrict services to custom APIs. (Here, the unifying API is the SPARQL endpoint.) It would be great if it was possible to interact with other systems publishing data using SPARQL (to test federated queries between different systems) or just raw semantic tuples.

Also, anybody has experience with the semantic rule languages available (for example RIF), with regards to home automation in semantic sensor networks? That would be an interesting topic to address also. The ability to define control rules that could by universally applied (as long as systems adhered to web standards). Anybody care to experiment with this?

When it comes to browser support for the semantic sensor networks, we have an interesting use case we would like to see realized: Consider IP-TV together with semantic home networks (for energy management, home automation, residential services, etc.) We work with both areas, but one problem that arises is this: How can the IP-TV system access and use sensors at home? Today, the sensor values have to travel from the sensors, through gateways to a centralized metering system, communicating with the IP-TV system, that then publishes the information to the user, a couple of meters away from the sensor. This, apart from inducing many items that could fail, also puts load on the network, and latency. However, if the set-top-box (running a browser) would be able to access the gateway (through XHR), locally, or using HTML5 extensions, could access the SPARQL endpoint in the local network, and all data there, a better architecture and solution would be available. This of course leads to a whole series of security issues, some more or less delt with if HTTP/HTTPS and authentication is used, but anyway. Also the issue of service detection (or endpoint detection in networks).

A lot of companies today work with set-top-boxes that publishes sensor networks. But these are all proprietary solutions (for instance set-top-boxes publishing z-wave devices using its own particular local API). A better and more general solution would be to be able to access local semantic endpoints, and define a security model that makes it easy to configure in a browser or set-top-box.

Another item we would like to experiment with, is the extension of semantic sensor networks onto peer-to-peer networks using XMPP. This would solve many aspects that are problematic using HTTP, such as presence, network topology, security, etc.

Thanks for your time,
Sincerely,
Peter Waher

 

-----Original Message-----
From: Myriam Leggieri [mailto:myriam.leggieri@deri.org] 
Sent: den 22 februari 2012 17:06
To: Marcos Caceres
Cc: Peter Waher; Arthur Barstow; public-sensorweb@w3.org; public-xg-ssn@w3.org WG; Manfred Hauswirth; Michael Hausenblas
Subject: Re: [via Web of Sensors Community Group]

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

Received on Wednesday, 22 February 2012 18:28:03 UTC