Re: SEP - SPARQL Enhancement Proposal

This sounds like a great plan. Thanks for writing it up, Jerven and Andy!

As some time has passed since most of the issues were created, I’m planning on re-reading them all and trying to get a better handle on what the big categories are, and what some of the first SEPs might try to address.

Thanks,
Greg


> On Oct 24, 2019, at 5:10 AM, Andy Seaborne <andy@apache.org> wrote:
> 
> 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 Saturday, 26 October 2019 04:22:00 UTC