W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2010

Re: ISSUE-29: Re: When is equal and when is it nonequal (eg, the IRI interface)

From: Nathan <nathan@webr3.org>
Date: Thu, 05 Aug 2010 15:46:04 +0100
Message-ID: <4C5ACEAC.5010400@webr3.org>
CC: Mark Birbeck <mark.birbeck@webbackplane.com>, W3C RDFa WG <public-rdfa-wg@w3.org>
Nathan wrote:
> 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'. ;)

[snip previously reply]

Sorry, i completely conflated that example by expanding it!

given a SPARQL of:

   <http://www.ivan-herman.net/foaf#me> foaf:name ?name .

one can get that same name from RDFa API with

store.filter("http://www.ivan-herman.net/foaf#me", "foaf:name" , null );

and I'm suggesting we could get to DOM Node by adding the same filter 
method to the document and return nodes, in addition to the store which 
returns triples.

"foaf:name" , null );

Different issue to the one you discuss (i think) yet it crosses paths 
because it too aims to decouple the node's from the triple/value whilst 
still allowing you to get to them simply.

All the other benefits of projections I completely follow and certainly 
it's worth having (imho) - that I am convinced of, whether it's the best 
or only approach to linking between some RDF s/p/o values and the source 
nodes I'm unsure :)


Received on Thursday, 5 August 2010 14:47:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:48 UTC