W3C home > Mailing lists > Public > public-sparql-12@w3.org > April 2019

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

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Mon, 22 Apr 2019 15:32:13 -0400
To: public-sparql-12@w3.org
Message-ID: <82701cb2-1931-142d-c245-0fb6ac1b8ee0@gmail.com>
Hear, hear!  Not only implementations, but proposed changes to the formal
parts of the SPARQL spec.


On 4/22/19 2:39 PM, 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
Received on Monday, 22 April 2019 19:32:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:45 UTC