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

Re: [via Web of Sensors Community Group]

From: Michael Hausenblas <michael.hausenblas@deri.org>
Date: Thu, 23 Feb 2012 08:52:09 +0100
Cc: Marcos Caceres <w3c@marcosc.com>, Myriam Leggieri <myriam.leggieri@deri.org>, 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>
Message-Id: <3CAE9D98-3C80-47DC-AF1E-35EAC689C981@deri.org>
To: Peter Waher <Peter.Waher@clayster.com>

Peter,


> * 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.


We are actively advocating the upcoming W3C standard 'Cross-Origin  
Resource Sharing' (CORS) [1] to address this issue and to this end  
maintain http://enable-cors.org/ - feel free to ping me off-list if  
you want to discuss this.

Cheers,
	Michael

[1] http://www.w3.org/TR/cors/
--
Dr. Michael Hausenblas, Research Fellow
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

On 23 Feb 2012, at 08:43, Peter Waher wrote:

> 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:53:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 February 2012 07:53:04 GMT