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

Re: a plea for parsimony

From: Marco Neumann <marco.neumann@gmail.com>
Date: Wed, 3 Apr 2019 15:21:22 +0100
Message-ID: <CABWJn4Tq=vvAuaOcrzkRH_XmTjjknHF_ah4Ex5CNbWtcFuYGwA@mail.gmail.com>
To: Boris Pelakh <boris.pelakh@semanticarts.com>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "public-sparql-12@w3.org" <public-sparql-12@w3.org>
Boris, and don't forget what I have mentioned earlier, there are a number
of features that are already wideley available in implementations or are
simple to add to any runtime. Here the community could benefit from
standardization. It's also explicitly mentioned in the charter of this
commnity group: "features found as extensions to available triple store"

Peter, while I have a generel idea what you are refering to here can you
please state what kind of formal description is currently lacking in SPARQL
1.1 and what would you like to see in a future SPARQL 1.2 specification.



On Wed, Apr 3, 2019 at 2:59 PM Boris Pelakh <boris.pelakh@semanticarts.com>
wrote:

> We are really in the brain-storming part of the process. We'll have plenty
> of opportunity to shoot ideas down, or put them on a back burner. Sometimes
> a person proposing a feature does not have the expertise to implement it,
> or even assess the feasibility of the implementation. DB vendors will weigh
> in on that aspect of the request, but we don't want to lose the ideas
> before they have been considered. Our primary gating criteria  right now
> should be 1) Is there a demonstrated need for this feature, and 2) does it
> fit well into the existing SPARQL paradigm.
>
>
> Boris
>
>
> ------------------------------
> *From:* Peter F. Patel-Schneider <pfpschneider@gmail.com>
> *Sent:* Wednesday, April 3, 2019 9:02:40 AM
> *To:* public-sparql-12@w3.org
> *Subject:* a plea for parsimony
>
> Maybe this is too early in the process of the CG to discuss this, but I
> already worry that there will be many, many cries for new features and not
> enough analysis of the new features for suitability or implementability or
> ease of use or ....
>
> It is easy to propose a new feature.  What gating conditions is the CG
> going
> to impose on what makes it into any report for a future WG?   I am in
> favour
> of stringent gating conditions, even to the point of formal description and
> actual implementation.
>
> peter
>
> --


---
Marco Neumann
KONA
Received on Wednesday, 3 April 2019 14:24:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 April 2019 14:24:08 UTC