- From: james anderson <james@dydra.com>
- Date: Wed, 6 Jul 2016 07:34:34 +0000
- To: public-sparql-exists@w3.org
- Message-ID: <01020155bf213d5e-af5ec9f5-2446-4d71-98ce-3cfa0e375a39-000000@eu-west-1.amazonse>
good morning, > On 2016-07-06, at 02:44, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote: >> […] > > Yes, my hope is that people (almost) uniformly agree about most problematic > parts of the spec and what to do about them. > > However, for the places where implementations differ and not everyone quickly > agrees on what should be done I think that a close, legalistic examination of > the spec is required. Not to say that the end result should be what the spec > dictates but to lay out the groundwork for a community-recommended change to > the spec. > > I also think that even where there is agreement on what to do the CG > recommendation will have more force if it says "the spec says this but it's > wrong and needs to be changed to that" instead of "the spec is ambiguous and > this interpretation is the one to use" when the spec is not ambiguous. although we arrive at this point because either the sparql language, or the recommendation’s description of the language, or its readers’ comprehension of the relation between those is deficient, it does not matter which. the most useful starting point would be a simple table which sets out a collection of related datasets, queries and results, of which the results are required by the use cases which precipitated this endeavour. this basic set could be extended with additional cases which follow as variations and/or alternatives. the table need not mention either any interpretation of the recommendation, or any description of any implementation’s behaviour. best regards, from berlin, --- james anderson | james@dydra.com | http://dydra.com
Received on Wednesday, 6 July 2016 07:35:05 UTC