Re: [w3c/sparql-12] Vote for charter.html acceptance at 5d2a2a9 (#75)

Rob,

We agree on the need for implementation experience and feedback. Each 
feature can have it's own lifecycle - I don't think anyone has proposed 
a single waterfall. It is "new features" so a feature can go as far down 
the path of requirement->definition as that group chooses to understand 
the full impact of the feature. The base line is to capture the use case 
and requirements - having "straight to spec" isn't helpful long term.

It is not just this group that decides what moves forwards overall - it 
is the implementations. Reasons for adopting a feature, or not, will 
include factors outside any standardisation such as their resources, 
priorities and their customers.

Another area I personally would like to see is "Best Practice" notes to 
capture experience. Sometimes, it is not a feature change needed but 
sharing experience. Addressing every possible use case with a feature 
leads to an overall confusing tangle.

My experience of W3C Working Groups is that their charter covers the 
core of what they do and communicates the general area they are working 
in. There are mechanisms for any full working group to go beyond that 
core with each "extra" making its own case. I do not see that creating 
an initial charter that is defined to cover every future possibility is 
useful; the "extras" need to make their own case. One theme that came 
through consistently when I first floated the idea of a SPARQL 1.2 work 
was "don't break what there already is".  People signed up to the scope 
statement and that is where I think we will provide the most effect to 
move SPARQL forward.

     Andy


On 22/04/2019 19:39, Robert Sanderson wrote:
>
> Thanks for the response Andy!
>
> I absolutely appreciate and agree with the need for use case review 
> and analysis as a foundational step towards any specification. Specs 
> not based on real world use cases tend to have very poor adoption. 
> However, in my experience, even more important for adoption of a 
> specification is implementation experience of proposed solutions in an 
> iterative, engaged manner. By addressing issues in a purely waterfall 
> approach of gathering requirements, and the (lengthy) proposal of a 
> single technical solution, the next step of implementation has often 
> lost some of the momentum and understanding of the use cases in the 
> first place.  By iterating on solutions, and engaging with the 
> proposers of the requirements to ensure that the request has full 
> understanding on both sides, progress is made more visibly and people 
> can come and go as needed.
>
> Let me propose a compromise then, that tries to maintain focus on the 
> review, but at the same time not lose energy and attention to 
> technical details.  As the UCR process occurs and document is written 
> up, champions for each issue should self-identify and propose possible 
> solutions in topic-specific, labelled github issues. These solutions 
> can then either be a record to come back to, or to act as further 
> discussion points to demonstrate that the process is not just about 
> talking, but also about doing something :)  If no one is willing to 
> champion an issue, that's also a good sign for the UCR that it might 
> not be as valuable as initially thought.
>
> Rob
>
> On Mon, Apr 22, 2019 at 11:00 AM Andy Seaborne <andy@apache.org 
> <mailto:andy@apache.org>> wrote:
>
>     (Taking this comment to the emailing list)
>     https://github.com/w3c/sparql-12/issues/75#issuecomment-485452783
>
>     On 22/04/2019 16:38, Rob Sanderson wrote:
>     > Community groups can produce specifications, just not W3C blessed
>     > technical reports. For example, the Open Annotation CG produced a
>     > specification that was implemented by many and then adopted as the
>     > baseline for the Web Annotation Data Model. The JSON-LD WG produced
>     > specifications that were adopted in the WG almost wholesale.
>     Plus many more.
>     >
>     > I think the charter should say that a SPARQL 1.2 specification
>     will be a
>     > deliverable, intended as the input to a WG with SPARQL in its
>     scope in
>     > the future. The trend in the W3C towards incubation in CGs is quite
>     > strong, and just white papers aren't sufficient demonstration of
>     > importance and adoption.
>     >
>     > So I'm 👎 as I feel the charter does not go far enough, but this
>     is not
>     > the equivalent of a formal objection.
>
>
>     Rob,
>
>     The current state of the issues is very strong on the "demand"
>     side of
>     the equation but weak on the "supply" side (e.g. implementations
>     input;
>     overall consequences).
>
>     This is where a "use case and requirements" step comes in.
>
>     An earlier message (April 2):
>
>     > It would be a success on the way to a future SPARQL to produce the
>     > features document. If there is sufficient energy, then we may
>     continue
>     > into a Specification but for the moment, I think we need to 
>     focus on
>     > the initial goal which is a necessary step anyway.
>
>     The SPARQL 1.1 Working Group had a two step charter - first, a
>     charter
>     to produce the UCR document then a charter for the REC of SPARQL 1.1
>
>     I believe a straight-to-specification approach is too ambitious,
>     being
>     "under construction" for a long period. We can be clear that we are
>     undertaking the first step of use case and requirements. Having a UCR
>     document is itself a success. Then the amount and nature of the
>     work on
>     a specification (or specifications) will be clearer.
>
>     Maybe some features will find their way into implementations
>     sooner than
>     others - that is not something that this group as a whole can decide.
>
>          Andy
>
>
>
> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049