- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Tue, 5 Jul 2016 17:44:56 -0700
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: public-sparql-exists@w3.org
On 07/05/2016 04:17 PM, Gregory Williams wrote: > On Jul 5, 2016, at 2:55 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote: >> >>> I believe there's probably general agreement on what the intuitive results should be in many uses of EXISTS. I suspect (and would love to see/gather implementation reports to confirm or refute) that there is probably a lot of overlap in what implementations are already doing when it comes to EXISTS queries. And I believe the goal here should be to find agreement on the desired semantics informed by existing implementation behavior, and to produce a better definition of EXISTS to match the desired semantics. >> >> That's an interesting issue. I don't know if there is indeed general >> agreement between implementations for the majority of the problematic cases of >> EXISTS. There is certainly one place where there is known disagreement. >> There might be others. Getting implementors in the CG and having them willing >> to quickly run test cases would be very useful. > > Yeah. It's only a suspicion of mine… I'm certain there are cases where there is divergence (you've already shown some), but my instinct says there's a large class of relatively simple, useful EXISTS queries where we might find agreement in both intuition and in many implementations. Definitely agree regarding the benefit of quickly running tests… I see several implementors are already members of the group, so hopefully that won't be too difficult. > >> Getting agreement on the desired meaning of EXISTS, and having that match >> current implementations, is indeed my hope here. I think that a nearly >> necessary precursor to this is getting agreement on what the current >> specification says, as I don't think that the CG can just replace some >> reasonable part of the current specification just because implementations >> don't do that. > > Hmmm… yeah. I guess that might depend on what people think of as "reasonable" parts of the spec. As you've pointed out, there are cases where the spec text seems clear, and example queries that do not violate it in any way, but which seem problematic nonetheless. I'm not sure what sort of overall scope we have regarding an eventual (lowercase "r") recommendation, but I would think that those cases would be prime targets for this group. If it turns out that many/most implementations aren't following the letter of the spec in those problematic cases, all the better for trying to align intuition, implementations, and our recommendation, in my opinion. > > thanks, > .greg Yes, my hope is that people (almost) uniformly agree about most problematic parts of the spec and what to do about them. However, for the places where implementations differ and not everyone quickly agrees on what should be done I think that a close, legalistic examination of the spec is required. Not to say that the end result should be what the spec dictates but to lay out the groundwork for a community-recommended change to the spec. I also think that even where there is agreement on what to do the CG recommendation will have more force if it says "the spec says this but it's wrong and needs to be changed to that" instead of "the spec is ambiguous and this interpretation is the one to use" when the spec is not ambiguous. peter
Received on Wednesday, 6 July 2016 00:45:26 UTC