W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

SPARQL TC 2012-09-11

From: Polleres, Axel <axel.polleres@siemens.com>
Date: Tue, 11 Sep 2012 07:51:46 +0200
To: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <9DA51FFE5E84464082D7A089342DEEE801463BA22BC4@ATVIES9917WMSX.ww300.siemens.net>
Dear all,

I am a bit at risk for today's call, at least I have only time until 16:30. So, since Lee sent regrets as well,
I'd be looking for someone to (at least partially) helping me out with chairing.

I know this is not optimal, but I'd still like to stick with the plan to vote for publications and finish up with comments this weeek.


Accordingly, here's the two items of the proposed agenda:


I) Wrap up on the last two open comments:

JL-4: sandro sent the response, there were still opposing responses by James Leigh http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Sep/0012.html
but Kjetil seems to be ok http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Sep/0011.html
and seems to point out a solution path ( i.e. that possibly the LDPWG could extend our design)

My take on it would be that the group decides in the Telco how to go on: I'd suggest that we respond alongthe lines that the behavior that James wants will not make it into this round of the spec, but maybe a future WG or the Linked Data Platform Working Group could take care of it (as Kjetil points out). We could/should put refinements of GSP in these direction on the Future Work Items list and we should be done, I hope.

2)RC-2 (you rersponded) also has still opposing voices from Richard http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Sep/0008.html <http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Sep/0008.html>

Also here, I think we should find some solution to close the issue. I am not really swapped in here, so, I'd appreciate help/discussion on what other people think.

As far as I can tell, these are the only open comments.

II) Go through documents and resolve to republish as PR/CR where possible. We need to decide which docs can go to PR directly and which ones go to CR . I summarize my impression per document (to be confirmed by editors):

* Query: ready for PR (still potentially some more Test cases could help for clarification of corner cases, but I think we have decent coverage)

* Update: ready for PR

* Protocol: ready for PR/CR?

   Questions: a) do we have 2 full implementations?
              b) pending resolution of RC-2
              c) PR vs. CR. pending discussion of Carlos' ACTION-672 cf. http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0164.html <http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0164.html>

* Service Description: ready for PR/CR?

   Question: do we have 2 full implementations? (otherwise I'd suggest to go for CR)

* Entailment: ready for CR
    (as confirmed by Birte last time, we won't have enough implementation experience tro go directly to PR here)

* Federated Query: ready for PR/CR?

   Question: do we have 2 full implementations? (otherwise I'd suggest to go for CR)

* Result formats (both JSON+CSV/TSV: ready for PR

* Overview: ready for PR (no implementation needed)



Best regards,
Axel
Received on Tuesday, 11 September 2012 05:52:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:49 GMT