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

Re: SEP - SPARQL Enhancement Proposal

From: Karima Rafes <karima.rafes@gmail.com>
Date: Mon, 28 Oct 2019 11:47:43 +0100
Message-ID: <CALsrFgOxX-Wd0FY_pePQ5iUXN-KHX+hjtMVhKvLqeindc=TqPA@mail.gmail.com>
To: "SPARQL 1.2 Community Group" <public-sparql-12@w3.org>
Cc: Andy Seaborne <andy@apache.org>
Thanks Andy but I see a problem in this method (always the same).

Only publishers have a real business and can afford to work on SPARQL.
Impact: Only recommendations with a task force (of editors) are selected
and interoperability issues are always postponed/ignored.

I am tired of this method of W3C. I have a question but no solution. Maybe
the SPARQL community has a real answer?

How to finance the works and controls related to the interoperability of
the SPARQL protocol in the long term ?
(please no answers such as "researchers can do it ...", I tried and It is
insufficient in the long term)


Le jeu. 24 oct. 2019 à 14:10, Andy Seaborne <andy@apache.org> a écrit :

> We now have a large body of material in the issues for improvements to
> SPARQL. The next step is to consolidate the discussions and bring
> together related issues into a number of proposals that represent a
> degree of consensus in the community. At the moment, the great ideas in
> the issues need the reader to go through all the material.
> The idea is to pull material together into a number of "SPARQL
> Enhancement Proposals" - SEPs - which are design documents.
> Someone, or a small group of people, would be technical editor to lead
> the creation of a balanced assessment and consolidation of the material;
> that does not mean the editor(s) do all the work!
> Active SEPs also give a way for there to be a focus of our time and
> effort. We have a lot of material - the suggestion is that we focus on a
> small number of areas at a time, and get them to a consolidated state
> with rough consensus and notable alternatives.
> The next steps:
> 1/ This message; comments and responses.
> 2/ Identify the first SEPs to initiate the process.
> 3/ Learn and refine
> There is a draft template below.
> At the same time, there is also writing-up best practice [issue-58].
> This also needs someone to help it move forward.
>      Jerven & Andy
> [issue-58] https://github.com/w3c/sparql-12/issues/58
> ---- SEP - draft template
> This description should cover most proposed changes but should not be
> seen as hard requirements. Some common format helps later readers. Not
> all sections will apply equally to every SEP.
> (This is modelled after Python PEPs).
> ## Title
> ## Short name
> ## SEP number
> ## Authors
> The people active in contributing content.
> ## Abstract
> A short description of the technical issue being addressed. Up to ~200
> words.
> ## Motivation
> This section should clearly explain what the use cases are and why the
> existing specification is inadequate. Often, that is a simply "SPARQL
> 1.1 does not cover this".
> It also frames the scope - is this a change in a specific part of the
> spec or does it have wider implications?
> ## Rationale and Alternatives
> The rationale describes why a particular design decisions were made. It
> should describe alternate designs that were considered.
> ## Evidence of consensus
> ## Specification:
> The details.
> ## Backwards Compatibility
> ## Tests and implementations
Received on Monday, 28 October 2019 10:47:58 UTC

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