Re: RDFa API comments from TimBL

Hi All,

#1 what is so far defined is almost perfected already, some minor tweaks 
to be made - only noticeable thing is handling CURIEs and IRIs, that 
could do with more work.

#3 is well on it's way and simply needs to be done as part of the RDFa API!

Personally I'd be fine to drop #4 (smushing etc) as even in deployed 
libraries these features are either not there or optional if they are 
included.

With regards #2, I'd suggest we cherry pick what's practically needed 
and add to the core RDF Interfaces (DataStore), then group the rest in 
with #4.

Specifically:

adding support for these two, which can be thought of as predefining 
"the most commonly used filter" and "the most commonly used existential 
  query"
  - statementsMatching(s,p,o)
  - mentions(iri)

adding the following new functionality:
  - each(s,p,o) which given two arguments returns an array of the third
  - describeSubject(iri) which returns a javascript object with 
properties as properties and an array of objects as the value for each 
property { "foaf:knows": ["Ivan","Tim","Mark"] )

preferably adding the following two, after discussion:
  - toIndex() which returns the graph as a structure s[p][o]
  - registerPropertyAction(callback) - easy hit which provides mountains 
of functionality and would encourage modularity of DOM based linked data 
applications.


Quite sure we could forget about methods like `remove()` as in many ways 
it's preferable to filter() and get a new store (similar to sparql 
construct returning a new graph) rather than DELETE-ing from an existing 
store. And everything else we can lump in with 4, and tbh probably 
forget about defining or mentioning at all.

The only addition I'll suggest, and handle under separate cover, is to 
consider something similar to $rdf.Namespace("http://...") 
functionality, and likewise some methods on IRI for comparison - as 
mentioned at the minute this is a really weak area of the existing API.

Best,

Nathan

Ivan Herman wrote:
> Mark, Nathan, Tim
> 
> I think there are several layers in the interface(s) that we may have to separate
> 
> 1. A 'core' RDF interface, with the store, the triples, the bnodes, etc.
> 2. Some additional features of the core RDF interface that are relevant for generic RDF management from Javascript but are not necessarily relevant for RDFa (eg, removing a triple from the store came up as a possible example here)
> 3. Specific methods for RDFa (eg, which refer back to the elements where the triple came from, things like that
> 4. Extra methods that the tabulator uses that are not necessarily relevant for the core RDF management or for RDFa. Tim referred to smushing (ie, owl:sameAs handling as one of those).
> 
> 
> It would be good to have a clear idea on which method/interface belongs to which of these categories. I think we can achieve a situation where #1 is aligned to the Tabulator API, and where #2, #3, and #4 are definable as 'extensions' (in some way or other) to #1. Formally, and per its current charter, I do not think that the RDFa WG should specify as part of its recommendation #2 and #4, only #1 and #3; publishing a WG note on #2 and #4 would be good, however.
> 
> So the question is: how far are we from that? Nathan, you have a view of both...
> 
> Ivan
> 
> 
> 
> 
> On Oct 5, 2010, at 17:19 , Mark Birbeck wrote:
> 
>> Hi Nathan,
>>
>> On Tue, Oct 5, 2010 at 3:55 PM, Nathan <nathan@webr3.org> wrote:
>>> Ivan Herman wrote:
>>>> Nathan,
>>>>
>>>> can you tell me what exactly the IndexedFormula and the IndexedDataStore
>>>> does?
>>>>
>>>> My purely admin issue is whether those features are related to the core
>>>> RDF part of the RDFa one. Put it another way, whether those are to be part
>>>> of an RDFa API. My worry is that the group is picking up too much onto its
>>>> plate. Maybe we have to stop by showing the way those features can be
>>>> bound/implemented with (on top) of what we publish might be enough in a
>>>> first round, leaving room for further work by a more dedicated group...
>>> Personally, I feel less like this is going the extra mile, and more like
>>> without this the spec is falling a mile short; that said I understand where
>>> you are coming from, especially when mentioning a more dedicated group -
>>> this is probably an area where yourself and the editors, Sando, Tim etc
>>> would be better to give feedback!
>> I had read your original email as discussing a change of syntax so
>> that the RDFa API aligns better with the Tabulator API. But it sounds
>> like you were actually saying that there are some features that are
>> missing from the RDFa API that are present in Tabulator?
>>
>> In that case it would be a good idea to say where you think the
>> current spec falls short, especially if it's 'by a mile'. :)
>>
>> 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)
> 
> 
> ----
> 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
> 
> 
> 
> 
>

Received on Wednesday, 6 October 2010 10:51:50 UTC