Re: RDFa API comments from TimBL

On Oct 8, 2010, at 24:22 , Nathan wrote:

> 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.

Our 'categorization' seem to differ... Under (3) I would like to separate those parts of the API that is necessary to work with RDF programmatically in general, but not really necessary for RDFa. My example was the removal of a triple from the store, but there might be others. 

This separation is important, see below...

> 
> 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

With the caveat of how I interpret the 3rd part... The issue is that this WG is not chartered to provide a generic RDF API. This is both a formal as well as a practical issue. 

Formal, because we should try to avoid rechartering: that would endanger the timely creation of an RDFa 1.1; there is, these days, a clear uptake of RDFa (we see new sites using it almost every day) and we should not be seen to be late; RDFa 1.1 includes a number of important new features. Practical, because this group may not have the expertise for the whole spectrum.

In view of that, my preference is to have parts 1 and parts 2 clearly defined, and have it as a Recommendation; the 3rd part can be defined by this group but _not_ as a Recommendation, only as, say, a Working Group Note. Whether the first two parts are defined as one document (as it is now) or as two documents is a secondary issue; at this moment, my feeling is that it should stay as is now, and the separate Note could then be on 1 and 3, to make it a self-sustaining document. I have the feeling that, actually, we should try to minimize the first part to what is strictly necessary, again to be able to successfully close what is on the charter although, clearly, what should be part of the first part and what should not is a bit of a judgement call.

I do not have an answer on which W3C group should then take 1 and 3 (ie, that Note) and turn it into a formal standard. None of the current working groups, that is for sure, and we may decide to set up a separate, tightly chartered group for that. Let us cross the bridge when we get there.

One example of an issue that this group may not be able to solve and is definitely not chartered to do. Nathan, you had some examples in one of your previous mails on the facility to access RDF triples with a formalism like graph[subject][predicate] (or something like that). In your answer on what that means[1] you said:

[[[
It's much easier in Javascript (much is an understatement) - essentially 
the full graph is turned in to an object of this structure
{
   ":nathan": {
     "foaf:name": ["nathan"],
     "foaf:knows": ["manu", "ivan", "mark"]
   }
   "subject2"...
}
]]]

which, for me, looks very close to a JSON encoding of a graph. Well, the new RDF Core group that we are discussing separately, may also have a JSON serialization of RDF on its charter; this means that this part of the functionality may have to be in line with what the serialization will look like. So this type of formalism, which is not strictly necessary for RDFa, could very well be part of part 3, and to be finalized later when there is a JSON serialization...

Thanks for all your efforts, Nathan!

Tim, how does all that sound?

Ivan


[1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0047.html





> 
> 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
> 


----
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