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

Hi Jerven

Thanks for this idea.

Quickly, I looked at the call "Reinforcing European presence in
international ICT standardisation: Standardisation Observatory and
Support Facility" (deadline 13 November 2019)  [1] [2]

Like all projects, the duration is limited in time (3 years here). SPARQL
interoperability is not limited in time. At the end of the projects for
each new feature, the problem of interoperability will inevitably come back.

I think it takes € 50,000 / year to have a single full-time engineer to
develop and maintain a test bed for SPARQL. This engineer is not there to
make scientific articles or sell a service / software / training but to
mediate and objectively judge really interoperable features and therefore
acceptable  in the SPARQL standards (1.2, 2.0, 3.0...).

How to finance this? By the W3C, a donation each year, a certificate paid,
or ...?

In order to develop real development tools for SPARQL, we need to know what
works for all or only for some. For the moment, it is impossible to know if
a SPARQL request (protocol and language) will work for all the editors
 that claim to be compatible with SPARQL. For me, it's a major issue for
SPARQL.

Bye
Karima

[1] Annexe K for this call
https://ec.europa.eu/research/participants/data/ref/h2020/other/wp/2018-2020/annexes/h2020-wp1820-annex-ga_en.pdf

[2]
https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/opportunities/topic-details/ict-45-2020

Le mar. 29 oct. 2019 à 21:22, Jerven Tjalling Bolleman
<Jerven.Bolleman@sib.swiss> a écrit :

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