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

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