Regrets. Re: SPARQL TC 2012-09-11

Hi all,

My regrets. I won't be able to make today's meeting.

Thanks,
Matt


----- Original Message -----
From: andy.seaborne@epimorphics.com
To: public-rdf-dawg@w3.org
Sent: Tuesday, September 11, 2012 4:47:05 AM GMT -05:00 US/Canada Eastern
Subject: Re: SPARQL TC 2012-09-11

(pre meeting inout as we have time constraints)

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

Agreed - I think Kjetil's point is the key here - the GSP is a 
practical, experience-based solution to managing graph stores.

It is not a general REST interaction protocol.  Indeed, this WG, or a 
future version, isn't obviously the place for that.  LDP is closer, and 
in a UC&R phase, so at least let's encourage James to comment there.

A general theory of REST interaction for RDF needs real-world 
experimentation and deployed experience first - and it's not clear to me 
that it is a W3C thing at all.

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

Reading Richard's last response, I don't quite get it.  The proposal is 
that the spec suggest (non-normatively) that sensible, use specific 
messages are put in the status line (IMHO - correct use of HTTP).  if 
they get mangled, then surely it's a system issue?

The whole issue of internationalization has not been discussed.  Body 
content must pay more attention to this.

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

I see a few other red ones - if these are not correct, could you (as 
chair) rule on them and mark them done.  We can use the page as evidence 
of responsiveness when going to REC.

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

(just to repeat my view)

Some of my recent comments about tests were prompted because of question 
I have got from people outside the WG wanting to run the tests and 
finding issues.  (e.g. DotNetRdf).

The tests are not a comprehensive verification of correct implementation 
(you'll need your own test as well :-) but they do matter to 
people/systems outside the WG.

 Andy

>
> * 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 13:00:39 UTC