Re: SEP - SPARQL Enhancement Proposal

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)

Bye
Karima

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