Supporting SPARQL interoperability issues, Re: SEP - SPARQL Enhancement Proposal

Hi Karima,

Not Andy but willing to think along outside my co-chair role.
Regarding, paying for people to work on standards, this is expensive and 
difficult in any industry.

Research, is being funded to do new and novel things.
Not so often about how to validate that we are still interoperable.
So I agree that research funding is not the right solution.

There are a few options that might (or not) be worth investigating.
  * Open source spec, closed source test suite + trademark for compliance 
(think Java
TCK).
  * Patent and license (think mp3)
  * Foundation with the goal of supporting SPARQL long term.
    https://www.standict.eu/
  * Look into Standardisation Observatory and Support Facility EU H2020
  * Maybe, we can look into systems like Elixir which are supposed to 
support
    infrastructure (in that case in the life sciences)
  * ...

I think that the first two are incompatible with the W3C.
But at least the Standardisation Observatory and Support Facility could 
help those of us in EU/EFTA when it (re)-launches.

Regards,
Jerven

On 2019-10-28 11: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> 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

-- 
Jerven Tjalling Bolleman
SIB | Swiss Institute of Bioinformatics
CMU - 1, rue Michel Servet - 1211 Geneva 4
t: +41 22 379 58 85 - f: +41 22 379 58 58
Jerven.Bolleman@sib.swiss - http://www.sib.swiss

Received on Tuesday, 29 October 2019 20:22:25 UTC