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

SEP - SPARQL Enhancement Proposal

From: Andy Seaborne <andy@apache.org>
Date: Thu, 24 Oct 2019 13:10:00 +0100
To: "SPARQL 1.2 Community Group" <public-sparql-12@w3.org>
Message-ID: <642a3c37-2868-87dc-540d-4c571a070b0d@apache.org>
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 

## 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 Thursday, 24 October 2019 12:10:05 UTC

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