Re: SEP - SPARQL Enhancement Proposal

> On Oct 29, 2019, at 2:07 PM, Andy Seaborne <andy@apache.org> wrote:
> 
> 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.

Tests are quite useful, and my practice has always been to develop tests alongside the spec, which is how JSON-LD has evolved.

To that end, it might be useful to create a new category, or test options in https://github.com/w3c/rdf-tests <https://github.com/w3c/rdf-tests> (perhaps /sparql12bis, or similar), or duplicate that test infrastructure into https://github.com/w3c/sparql-12/tests <https://github.com/w3c/sparql-12/tests>, where people could submit their proposed tests to go along with proposals. It would be useful to flesh-out the corners of different proposals. Of course, it’s better if the feature has been implemented someplace first.

Gregg

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