- From: Nathan <nathan@webr3.org>
- Date: Thu, 05 Aug 2010 14:56:21 +0100
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- CC: Toby Inkster <tai@g5n.co.uk>, Manu Sporny <msporny@digitalbazaar.com>, Ivan Herman <ivan@w3.org>, W3C RDFa WG <public-rdfa-wg@w3.org>
Mark Birbeck wrote: > Hi Nathan, > >> Still remain unconvinced by projections... > > Yes...I realise that most people aren't convinced. :( > > Yet what surprises me on the issue is that SPARQL is probably the most > common form of querying RDF, and people almost always use the > projection form of queries when using SPARQL: > > SELECT ?name ?homepage ... > > There must be some reason why people favour this technique over > obtaining a ton of triples and working through each one, or using the > CONSTRUCT form? > > >> ...yet realise they do provide a >> workable approach, and given the aforementioned keep the rest workable too - >> i.e. could work with that :) > > In which I am inspired to keep chipping away at the 'unconvinced'. ;) Hi Mark, I follow and agree, to clarify, I meant unconvinced in this use case. I'm looking at SPARQL as taking a graph then repeatedly filtering till you get the values you want. Currently you can do this with the RDFa API for triples (using store.filter), but not for elements. To address this, currently most of the solutions look at linking the triples to the DOM Elements they came from. Whereas I'm trying to put forward that we could add matching filter methods to the document, or DOM Element interface so that we can do exactly the same, but get back elements/nodes rather than triples. Given this sparql: SELECT ?homepage WHERE { ?person foaf:name "ivan" . ?person foaf:homepage ?homepage . } we can get to the triple value in RDFa by doing var homepage = store.filter( null , "foaf:name" , "ivan" ) .filter( null , "foaf:homepage" , null ); so why not get the nodes by doing: document.filter( null , "foaf:name" , "ivan" ) .filter( null , "foaf:homepage" , null ); Simply let's us use RDF(a) as a selector for the DOM. Best, Nathan
Received on Thursday, 5 August 2010 13:57:27 UTC