- From: Dan Brickley <danbri@danbri.org>
- Date: Tue, 17 Feb 2009 14:10:34 +0100
- 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 scenarios. Naively, both can involve sending a string beginning "SELECT blah blah..." and returning a table of rows/fields. Could http://dev.w3.org/html5/spec/Overview.html#sqlresultset 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? cheers, Dan -- http://danbri.org/
Received on Tuesday, 17 February 2009 13:11:17 UTC