Re: SEP - SPARQL Enhancement Proposal

I have always been pleasantly surprised by the high level of 
interoperability in SPARQL implements when compared to other 
technologies. Yes, there are differences but users genuinely expect 
interoperability because general that is their experience.

Expectations are high - test suites have been very effective with the 
distributed working and with http://w3c.github.io/rdf-tests/ continue to 
evolve.

Your main on resourcing is a good one. We have a "supply and demand" 
situation where "demand" (expectations, suggestions) exceeds the 
"supply" (people to convert that into spec-ese, people to review and 
improve, triplestore providers to implement experimentally, ...).

I hope that having a few SEP "in progress" as a work focus is a small 
step to addressing that.

But only a small step - what other thoughts do people have on the subject?

     Andy


On 28/10/2019 10:47, Karima Rafes wrote:
> 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 
> <mailto: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 Tuesday, 29 October 2019 21:07:01 UTC