W3C home > Mailing lists > Public > public-rdfa@w3.org > February 2009

Re: HTML5 & SQL Engine Persistence

From: Dan Brickley <danbri@danbri.org>
Date: Tue, 17 Feb 2009 14:10:34 +0100
Message-ID: <499AB74A.9090007@danbri.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>, public-rdfa@w3.org, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Sam Ruby <rubys@intertwingly.net>
On 17/2/09 13:50, Kingsley Idehen wrote:
> Dan Brickley wrote:
>> Can the advanced facilities in HTML5 (eg. SQL persistence) be usefully
>> combined with RDFa usage scenarios. For example, can we
>> load/store/cache parsed RDFS/OWL schemas within the browser? Can we
>> use the browser's crypto APIs to check the schema hasn't been
>> maliciously interfered with? Can we serialize the in-page RDFa triples
>> into the browser's SQL store and perform SPARQL queries on it (i)
>> within the SQL environment through query rewriting (ii) using
>> in-memory .js SPARQL implementations...
> All,
> Dan's comments above just rekindled another point of confusion and
> concern for me re. HTML5. Why do we have the notion of SQL persistence
> instead generic DBMS persistence? There are many DBMS models for
> persisting data, and each is accessible for queries and CRUD via
> standard APIs.
> Why aren't we considering a more generic notion of DBMS persistence
> instead of model specific SQL persistence?

(OK we're getting a bit off the original topic here so I'm slimming the 
Cc: list)

I guess because HTML5 builds out from common implementation experience 
amongst the mainstream Web browsers. Several of which have been bundling 
and exposing SQLLite in recent years.

Kingsley, in your experience, how close is the SQL API in
http://dev.w3.org/html5/spec/Overview.html#sql to one that would be 
needed to access SPARQL database facilities?

We could of course just make new wrapper APIs and use the browser SQL 
store, ... but on the optimistic assumption that browser had some native 
SPARQL powers, ... I'm interested to know how much the HTML5 SQL API 
would need to change, to allow it to be used directly to talk to SPARQL.

"A future version of this specification will probably define the exact 
SQL subset required in more detail." suggests there is wiggle room here, 
if a single API could be constructured that allows for SQL and SPARQL 

Naively, both can involve sending a string beginning "SELECT blah 
blah..." and returning a table of rows/fields.

http://dev.w3.org/html5/spec/Overview.html#sqlresultsetrowlist be used 
today with Javascript-based SPARQL engines or remote SPARQL endpoints, 
for example? If not, are there any unobtrusive API changes that would 
make this work?



Received on Tuesday, 17 February 2009 13:11:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:03 UTC