Re: UPDATED Telecon Agenda - 6th May 2010, 1400 UTC

Hi Mark,

a few notes on the document you posted. I guess more discussions this afternoon...

1. I think having an explicit concept for a store and different parsers on the store is a good idea. I must admit that the constructions you have seem to be a bit too convoluted for my taste. Being obviously influenced by RDFLib (that have a similar concept), I think something like

data = document.data
data.parse("rdfa")
data.query(...)

should be enough. Yes, there could be a separate set of 'registration' for parsers on the data object if one wants to register, say, a direct turtle parser, but going through all this dance of creation of a query, and a parser all the time for all users seems to be an unnecessary drag:-( I think there is room for simplification there.

2. Obviously, the real issue is the specification of the query; that is the complex piece. 

First of all, from an RDF point of view, it is 'subject' oriented. Ie, I can get various triples for a specific subject, but you do not seem to allow for the search of subjects via patterns. That might cover a number of cases for RDFa, but if we really have a general concept of a store where I could also plug, say, a turtle parser, then this approach breaks down (because there is no reference to a DOM node any more...)

That issue put aside, what you seem to have is a select with

{ property1 : object1, property2 : object2 } 

patterns. But there are a couple of questions:

- can I have a variable for a property? Ie, can I search for a property, too?
- for the object (or predicate), how do I differentiate among
   - an object being a fixed literal
   - an object being a fixed URI reference (ie, a Resource)
   - an object being a fixed literal whose value happens to be a URI
   - an object being an unbound variable
   - an object being an unbound variable for a literal with a fixed or variable language or datatype?
   - (probably other issues)

Note that you use "?summary" as a pattern in general but that is incorrect: what if I have a fixed _literal_ whose value is "?summary"?

Answering all those questions leads, in my view, to an API for SPARQL. Ok, we may not define the OPTIONAL from a SPARQL pattern, we may not have references to graphs, etc, so it may be a simplified API, but it is certainly more complex, at least in my view, than what you outline. Which also means that it will require more work and the interface will be more complicated.

(Actually... I have been there. Some years ago I did develop a core SPARQL engine for RDFLib but I was lazy to add a parser to it, so I did it by defining some sort of an API. There is an old description that I have just put on the Web[1]. Full disclosure: I made the same mistake at first by overloading the string with a "?xx" for a variable until TimBL rubbed my nose into this:-))

3. All that being said, such a SPARQL API may good to have at some point. But... I fear it is way too complicated for those end users who do not really have a feel for RDF triples. So the question is where do we find the sweet spot of what is useful and still palatable? I am not sure I have the answer, to be sure. But I am afraid of the comparison between the microdata API (that is, on the surface, very simple, though some of the complications are hidden in the details) and what we are heading for...

I said 'may' be good to have, because an alternative is to go the PHP-SQL way, which is simply to be able to use a full SPARQL query string as an argument and that is it. The implementation may be more complicated, because you have to have a proper parser, but that may be cleaner and certainly with less headache.

'See' you this afternoon!

Cheers

Ivan


[1] http://www.ivan-herman.net/Misc/2010/sparqlDesc.html


On May 5, 2010, at 14:22 , Mark Birbeck wrote:

> Hi Manu/everyone,
> 
> I've re-jigged the document a little to make it more explicit that a
> library or platform can hide much of the initialisation code. I've
> also reinstated the getElementsByType() method.
> 
> But the other things I wanted to put in -- such as datatypes, actions,
> formatters, event handling, and a few other bits and bobs -- will have
> to wait until later today.
> 
> I realise that delaying any longer will make it difficult for some
> people to take a look before tomorrow, so here is a link:
> 
>  <http://code.google.com/p/backplanejs/wiki/RdfaDomApi>
> 
> Hopefully this will give people enough to orient themselves for
> tomorrow's discussion.
> 
> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
> 
> 
> On Wed, May 5, 2010 at 5:08 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> Hi all,
>> 
>> After speaking with Mark about the changes he plans to make (but hasn't
>> posted to the WG yet), and discussing some of these changes with Ivan,
>> Benjamin and Shane, a couple of things have become clear:
>> 
>> * Some of Mark's proposals have technical merit and could fundamentally
>>  affect the direction of the RDFa DOM API. We should review
>>  them before doing the FPWD.
>> * It will take time for everyone to come up to speed with what Mark is
>>  proposing, and how it affects (or doesn't affect) the current RDFa
>>  DOM API document.
>> * It will take time to reach consensus on these proposals.
>> * It will take time to integrate the consensus into the RDFa DOM API
>>  document.
>> 
>> Given these new events, we will have to push off our RDFa DOM API FPWD
>> for at least one month while we generate consensus around the proper
>> path forward for the RDFa DOM API. What follows is an Agenda that
>> attempts to move us towards consensus on the RDFa DOM API.
>> 
>> ==========
>> Thursday, May 6th 2010
>> Time: 1400 UTC, 7am San Francisco, 10am Boston, 3pm London
>> W3C Zakim bridge, telecon code: RDFA (7332)
>>   Phone US: +1.617.761.6200
>>   Phone UK: +44.117.370.6152
>>   Phone FR: +33.4.89.06.34.99
>> irc://irc.w3.org:6665/#rdfa
>> Duration: 60 minutes
>> Scribe: John, Jeff (on deck)
>> ==========
>> 
>> Agenda
>> 
>> 1) Overview of Mark's changes to RDFa DOM API (Mark)
>> 2) Consensus forming:
>>   * Having a gentler introduction to RDFa DOM API
>>   * Including more examples related to Google vocab,
>>     Facebook, Yahoo vocab, etc.
>>   * Support the concept of a low-level API
>>     (Store/Parser/Triples) and a high-level API
>>     (Projection/.select())
>>   * Moving API to document.meta or document.data
>>   * Defining the concept of a Store()
>>   * Defining the concept of a pluggable parser
>>   * Support the concept of projection
>>   * Support the .select() syntax
>>   * Determine how to merge all of this
>> 
>> -- manu
>> 
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> President/CEO - Digital Bazaar, Inc.
>> blog: PaySwarming Goes Open Source
>> http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/
>> 
>> 
>> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf