- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Tue, 5 Jul 2016 16:17:34 -0700
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: public-sparql-exists@w3.org
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
Received on Tuesday, 5 July 2016 23:18:01 UTC