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: james anderson <james@dydra.com>
Date: Tue, 23 Apr 2019 04:48:13 +0000
Message-ID: <0102016a4885de05-33ee056c-73ab-4d68-bd01-60ab456ea63c-000000@eu-west-1.amazonses.com>
To: "SPARQL 1.2 Community Group" <public-sparql-12@w3.org>
good morning;

> On 2019-04-22, at 19:59:49, 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:
>> …
>> 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.
> ...
> 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 notion of a “formal objection” to the process in a community group is either quaint or revolutionary.
community group members do pretty much whatever their interests dictate.
to set the threshold, that they manage to integrate all issues into a specification, will not facilitate the process.
seaborne’s expectation is more realistic.
it will more than suffice, if our chairs manage to shepherd all issues to closure - either as not material or as concise descriptions of the use cases, requirements, examples and tests (aka “non-normative reports” and “test suites and other software”)

several issues already illustrate the value of a loose process, in that they capture
- aspects where sparql is incomplete : eg abstract graph designation
- deficiencies in the 1.1 recommendation which compromise interoperability : eg exists' failings
- requirements introduced by an evolving semantic data ecosystem  : eg json-ld integration, aggregation forms

should the group manage to resolve such issues to a point described by the existing charter, where they are coherent enough for some other process to carry forward, that will be valuable and worth the effort.

best regards, from berlin,
james anderson | james@dydra.com | http://dydra.com
Received on Tuesday, 23 April 2019 04:48:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 23 April 2019 04:48:38 UTC