- From: Myriam Leggieri <myriam.leggieri@deri.org>
- Date: Wed, 22 Feb 2012 16:05:31 +0000
- 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>
- Message-ID: <4F45124B.8090504@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
Attachments
- image/jpeg attachment: ssp_screenshot.jpg
Received on Wednesday, 22 February 2012 16:06:52 UTC