Re: [via Web of Sensors Community Group]

On Thursday, February 23, 2012 at 7:43 AM, 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.
True  
> 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/

The only reservation I have is that it requires understanding the data set at the SPARQL endpoint and requires the developer to have the ability to formulate SPARQL queries (both are non-trivial… and neither is UPNP, as it's also terribly over/badly engineered). Ideally, an API could abstract away the protocol and query language.  

> 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.
As Michael already stated, CORS addresses some of this… as might Web Intents :http://webintents.org/   
> * 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.

Right, a native component might be needed (again, Webintents might have a role to play)… though I have seen people use (Opera) browser extensions to find devices in the home. I've also seem Dave Raggett do some pretty cool demos just using the browser to find locally attached devices (though I can't remember the details about how he did it).   
> 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.

Exactly :)   
> 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.  
I don't dispute the power of SPARQL, though I've yet to see it be used in a noble way outside an academic setting and the occasional "cool demo". I still believe that SPARQL may have a role to play for particular applications (e.g., where there happens that there is some preexisting SPARQL endpoint that spits out data from a sensor), but it should be just one of many possible solutions: there are much lighter, and less complex, ways of interrogating data sources without having to bring out all the Semantic Web machinery on which SPARQL depends… I don't know of any backends that support SPARQL out of the box, for instance - and adding a SPARQL interface/proxy between the client and sensor seems like a long way around… instead of just getting at the sensor data directly (e.g. over a Web socket or server-sent event).   
> 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/
>  

Thanks for the links. I'll make an effort to educate myself a bit more on SPARQL.  

In the interest of full disclosure to both groups, you've all probably gathered that I am not a big fan of Semantic Web technologies - as I did quite a bit of research into their application throughout my (previous) academic career and found them to be fundamentally flawed, generally inapplicable, and (as a developer) infuriatingly difficult to use… and picked up a further distain for them hanging out with, and working directly for, browser makers.  

Having said that, and FWIW, I am willing to be convinced of the applicability of SPARQL and related technologies to this area (though not that my acceptance matters much). However, do expect me to have occasional outbursts if namespaces, XML Schema, and talk of ontologies or the like start leaking through. Having personally been hurt by Semantic Web technologies in the past, it's only natural to have passionate opinions, so take my occasional outbursts with a sense of humor :)… but perhaps the situation has improved over the last decade, so I'll do my best to be open minded.   

Kind regards,
Marcos

Received on Thursday, 23 February 2012 10:19:39 UTC