Re: RDFa API comments from TimBL

Tim, Ivan, All,

I strongly agree that the collective API needs defined, considered and 
produced as 3 separate parts, a core RDF API, an RDFa extension, then an 
extension which considers working with RDF programmatically, and I 
believe that's the approach we have and are taking (I know I personally 
am - implementing constrains that it is done that way).

I'd also like to point out that any implementation of the RDFa API which 
is to be usable, requires the functionality of all 3 parts.

Thus, Tim, perhaps if I refine the question to ask, which of the 
following approaches would you recommend:

(1) Define all 3 parts separately, and in parallel as we are now, within 
the RDFa WG, releasing as a single document which is clearly split in to 
three key parts.

(2) as per 1, but releasing two separate documents, one RDF specific, 
and one with the RDFa extensions in it - we currently have "RDFa 1.1 
API" and "RDF TripleStore APIs (optional)" under milestones, this could 
be leveraged.

(3) Have all 3 parts defined by different working groups

If (1) or (2) then is there anything you would like to see happen, or 
anybody you would like us to work closely with, to ensure technical 
excellence? (Ivan can you confirm no change of charter would be needed?)

If (3) then there are many questions, who when where, how does this 
affect our charter and timeline, could a parallel WG be opened and 
completed by April 2011? and so and so forth.

I guess my simple response would be, if not us, now, as part of the RDFa 
API; then who, when and where?

Perhaps it's just me but I feel that the members of this group are 
uniquely positioned to consider all angles and in a sense fast track 
something extremely beneficial to the web through standardization (and 
needed now, if not yesterday), whilst both ensuring a technically sound 
API that's proven by implementation and incorporation in to existing 
libraries, and ensuring open communication and feedback from those who 
are extremely experienced in RDF APIs and tooling.

Best,

Nathan

Ivan Herman wrote:
> Actually, I think we are on a good track with all that, although Nathan is the one who can really tell us. Looking at
> 
> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0061.html
> 
> and Nathan's reply
> 
> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0062.html
> 
> seems to say that it is possible to
> 
> 1. have a core RDF API which, with minor tweaks, is almost the same as what we have now in the document, but is also compatible with the Tabulator API (though it constitutes only a subset of the Tabulator API)
> 2. have the RDFa API built on top of this core, which is essentially what we have already
> 3. have some additional features that are part of an RDF Core API and the Tabulator API, but is not needed by RDFa (though is useful/necessary for a general RDF API; the typical example is the removal of triples from the store).
> 
> This WG is chartered to do #2 which requires #1, and that can be done (again, per Nathan, who knows both). This group is not chartered to do #3; it may choose to write it down in a note (if it has the time an energy), on a wiki, or whatever, and some other group will have to pick that up in future. 
> 
> The important point is, for this discussion, #1, at least in my view. Ie, if a future group does #1 and #2, it should not be forced to do something incompatible with the RDFa API. 
> 
> Ivan 
> 
> 
> 
> On Oct 7, 2010, at 17:17 , Manu Sporny wrote:
> 
>> On 10/07/10 09:55, Shane McCarron wrote:
>>> Sure, but you didn't answer the key question here, Tim.  WHERE should
>>> that RDF API work happen?  We think it should happen in the RDFa Working
>>> Group because 1) there is one, and 2) we have already done lots of the
>>> work.  What do you think?
>> Not to mention that stopping/moving the RDF API part of the RDFa API
>> work from this group is going to be incredibly disruptive to our charter
>> and timeline. We are chartered to produce an RDFa API.
>>
>> We need a solid RDF API if we are going to have a solid RDFa API - one
>> of the reasons that we asked Nathan to join the RDFa WG was to ensure
>> that the RDFa API work took the Tabulator work, and thus, the RDF API
>> work, into account.
>>
>> We have a good head of steam behind us, I'm wary of disrupting that as
>> we're closing in on something that is getting positive feedback from the
>> community.
>>
>> -- manu
>>
>> -- 
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> President/CEO - Digital Bazaar, Inc.
>> blog: Making Payments Frictionless, Saving Journalism
>> http://digitalbazaar.com/2010/09/12/payswarm-api/
> 
> 
> ----
> 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 Thursday, 7 October 2010 22:23:30 UTC