Re: HTML5 & SQL Engine Persistence

Dan Brickley wrote:
> 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?
For us a non issue due to SPASQL (SPARQL inside SQL) support in 
Virtuoso. But I am not advocating for us [OpenLink], I am really 
advocating for anyone that provides structured data access and data 
management technology that support industry standards for the relevant 
DBMS models (RDBMS or Graph at the very least).
>
> 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.
You would have add a layer of abstraction for Storage atop Relational or 
Graph stores  (as Mozilla once did).
>
> "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.
Ideally, the original Mozilla work would have been fine (note: links to 
this work has vanished) since it catered for RDBMS or Graph (RDF) model 
storage.
>
> 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?
>
So this comes down to me pleading with everyone to dilute my own 
competitive advantage (I can do all of this with SQL, but RDBMS 
specificity just  isn't the right architecture for a Web standard) :-)

Kingsley

> cheers,
>
> Dan
>
> -- 
> http://danbri.org/
>


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Tuesday, 17 February 2009 20:26:50 UTC