RE: [via Web of Sensors Community Group]

Hello.

UPnP seems (to me) a very good solution, combined with SPARQL.

The browser does not have to support SPARQL, only the SPARQL endpoint does. The browser just sends a SPARQL query (a string) to the endpoint (using a simple HTTP POST, or SOAP/REST request) and the endpoint returns different formats (depending on the Accept header for instance). JSON is a valid format, and is already defined:
http://www.w3.org/TR/rdf-sparql-json-res/

http://www.w3.org/TR/sparql11-results-json/


So, the only thing missing today, to be able to use SPARQL & JSON in browser code is:

* The ability to call resources across different domains (for instance internet, where page might be located, and local network, where sensor gateway/SPARQL endpoint is located). This can be allowed in controlled networks (such as IP-TV networks), but for general solutions (i.e. combining web & home networks) security vulnerabilities makes this difficult.

* Detect resources. UPnP & DLNA use UDP & HTTPU. To be able to access these directly from a browser would also induce security vulnerabilities if combining web & home networks.

However, if you through the browser code could get access to UPnP Devices & Interfaces already recognized (for instance through an properties in the DOM), you could add a security model in the browser where you could control what pages would have access right (and what access rights) to individual devices and/or what interfaces. That would definitely be interesting for a multitude of reasons, not only sensor networking and home automation, but home entertainment as well. A UPnP device & interface description would have to be defined for SPARQL endpoints. (Much like the security models used for Windows 7 sensors, where privileges to individual sensors are controlled on a user level.)

And if you defined an UPnP interface for the SPARQL endpoint, which had a SPARQL Query action defined, you could perform the SPARQL query over UPnP (i.e. HTTP) instead of using the XHR object, and the cross domain problems would be solved as well.

SPARQL (see it as an SQL for semantic networks) is exceptionally powerful in that it does not pose limitations on how data is structured or linked, where individual data items reside, and allows for cross domain (and cross protocol) joins. SPARQL does for linked internet data what SQL did for relational databases that traditionally were accessed using procedural APIs. Nobody wants to use such procedural APIs anymore, if they have access to an SQL parser/endpoint (if they've taken the trouble to learn SQL).

If somebody wants to learn more about SPARQL:

SPARQL 1.0:
http://www.w3.org/TR/rdf-sparql-query/


SPARQL 1.1:
http://www.w3.org/TR/sparql11-query/


Best regards,
Peter Waher

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



On Wednesday, February 22, 2012 at 6:25 PM, Peter Waher wrote:

>  
> 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.)  
Out of interest, are there commercially available solutions of the above that are currently using semantic web technologies?   
> 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.  

Yes, it's annoying and overly complicated...   
> 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).


So, questions I have: no browser natively supports SPARQL (or any Semantic Web technology, and they have no plans to do so), but browsers will soon support IndexedDB (experimental builds are already coming from Moz, Google, and MS)… would it make sense to explore using an IndexedDB solution? Also, browsers support JSON natively, so why not try to build something on that (and see where it breaks down for the particular use cases… whatever they might be)?   

Also, given the proliferation of UPNP and DLNA devices… would it not be worth while to look at exploiting those first?  

--  
Marcos Caceres

Received on Thursday, 23 February 2012 07:46:24 UTC