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
