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

Re: RDFa API comments from TimBL

From: Shane McCarron <shane@aptest.com>
Date: Fri, 08 Oct 2010 10:25:49 -0500
Message-ID: <4CAF37FD.9040209@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: nathan@webr3.org, Tim Berners-Lee <timbl@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, RDFA Working Group <public-rdfa-wg@w3.org>
  Great!  Someone please put this on the Agenda for next week so we can 
formally resolve that this is the strategy?

On 10/8/2010 4:00 AM, Ivan Herman wrote:
> Hey Nathan,
>
> I am afraid we are in a violent agreement here:-)
>
> Ivan
>
> On Oct 8, 2010, at 10:49 , Nathan wrote:
>
>> Ivan Herman wrote:
>>> 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.
>> apologies, our categorization may differ, I was thinking in terms of there being 4 parts.
>>
>> I've stripped my previous mail, and for the sake of clarity, let's define three parts as:
>>
>> (1) RDF API (RDF Interfaces, Data Interfaces, statementsMatching etc*)
>> (2) RDFa Extensions
>> (3) Removing triples, json serialization, smushing etc
>>
>> * as per http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0062.html
>>
>>> 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.
>> My preference/suggestion is also to have 1 and 2 clearly defined as a Recommendation, and for us to steer well clear of defining 3 all together.
>>
>>> 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.
>> Unsure whether one or two documents.. as for what should be in the first part being a judgement call I'm working on the basis of http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0062.html
>>
>>> 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...
>> taking part 3 as '(3) Removing triples, json serialization, smushing etc' then there are certainly things we could document which would be useful to people making RDF tooling and a future working group, whether that's in the form of a WG Note or just a Wiki page is another thing - I'd suggest we take the approach of putting it in a wiki page then review later on if it warrants publishing a Note.
>>
>>> 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
>
> ----
> 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
>
>
>
>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 8 October 2010 15:26:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC