Re: a plea for parsimony

The SPARQL 1.1 specification does have adequate formal description of
SPARQL 1.1 features, as far as I can tell.   So that is not the problem
that I see.   What I see is the CG coming up with a laundry list of
proposed new features without any notion of how to define or implement them.

peter

PS:  I said that the SPARQL 1.1 specification has an adequate formal
grounding.  That doesn't mean that this grounding is everywhere reasonable,
or implemented, or even cohesive.  On the contrary, there is at least one
major part of the SPARQL 1.1 specification that is unreasonable,
unimplemented, and not even cohesive with the rest of the spec.  I was
hoping that this CG would look at  failures in the SPARQL 1.1 spec and come
up with suggestions on how to solve them, but this doesn't appear to be
part of the draft charter.


On 4/3/19 7:21 AM, Marco Neumann wrote:

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