See also: IRC log
andys comments that the agenda is rather long; kendall agrees
<SimonR> Discussion of correction to minutes: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0113.html
bijan: specification definitely needs tightening
<bijan> ?x ?y
<bijan> _:x :mochi
<bijan> :Bijan :mochi
bijan: andys thinks that this is a possible correct answer for a distinct query, I do not
<LeeF> bijan, are you saying that you read DISTINCT as NOT-REDUNDANT ?
<bijan> :bijan :loves :mochi
<bijan> _:x :hates :mochi
<EliasT> :elias :loves :mochi
<kendallclark> I despise it.
<EliasT> :kendallclark :hates :mochi
<kendallclark> a discussion in where?
andys: we had a discussion with enrico about this earlier, and we agreed that DISTINCT meant term-distinct, not non-redundant
<kendallclark> ah, 'with enrico'
<Zakim> ericP, you wanted to say that I've been modeling everything based on SPARQL query symbols (no logical entailment necessary)
bijan: think making leanness available is important
ericP: i've been doing all this based purely on symbols, not on entailment
<SimonR> If we choose not to treat bnodes as existentials, are we basically choosing not to use RDF Semantics...?
<SimonR> I agree, and I'm rather alarmed by that.
<kendallclark> At the very least, it's a problem that I have to take to SWCG, I believe.
andys: I don't understand why this is affected by rdf semantics, because we are talking about a result set here, not a graph
bijan: it depends on how see the relation with entailment, and also there is a possible issue when looking at CONSTRUCT
bijan volunteers for an action item on this
<Zakim> ericP, you wanted to suggest that bijan has proposed a keyword that lets andy and bijan agree on at least one form of redundancy
ericP: bijan mentioned "DISTINCT" vs. "LEAN" as two keywords
<SimonR> My take would be this: whatever form of entailment you are currently using, a solution which is entailed by another solution may be eliminated from the solution set without loss of information. Only the order of co-entailed solutions is arbitrary in that case, I think.
<SimonR> Order of elimination, rather.
<bijan> ACTION: bijan to show that the "strong" version of DISTNCT doesn't interfere with intermittent algebraic operations [recorded in http://www.w3.org/2006/08/15-dawg-minutes.html#action01]
<AndyS> bijan, could you also describe the reduction algorithm as well? I think I know what it is informally but it would be good to see it formally. And that can go in the doc.
<bijan> AndyS, yes, that's in the plan
<kendallclark> bijan: let's add another action for that, please
kendall: the utility of the tool is one consideration, but another consideration is (PR if you will) respecting RDF semantics
ericP: analogy is an XQuery engine that respects xml:ID
<kendallclark> ACTION: Bijan to describe reduction algorithm [recorded in http://www.w3.org/2006/08/15-dawg-minutes.html#action02]
<Zakim> AndyS, you wanted to talk about the range of use cases (a difference between AndyS and Bijan)
AndyS: I think that we have a spec that allows writing queries that respect RDF semantics, but some things are a bit outside that
<SimonR> Treating the bnode identifiers like names rather than existentials basically would mean they we're choosing a...drat, what the name for? In logic, where you have a model by interpreting the symbols back to themselves...it's named about someone.
bijan: we are chartered in the light of existing specs, so we have to make _very_ clear that are compliant or, if we deviate, where exactly.
<SimonR> Herbrand model, that's what I was thinking of....
kendall: it's not currently clearly marked where we depart from rdf semantics, so that is at least a possible and useful thing to do
<bijan> I would work on an appendix detailing the differences
AndyS: I understand and appreciate bijan's concerns with distinct, but what I would like to see is support from other people on the issue
<kendallclark> Question: Is respecting RDF semantics w/r/t DISTINCT important to your organization?
SimonR: i think we should base our semantics on rdf, bnodes are existential variables there and that should be reflected
LeeF: if it turns out that the choice is between RDF semantics or not, then we should respect. I can see use cases for both ways of distinct though.
FredZ: I don't know the opinion of my
... still forming my own opinion on the issue
ericP: in favor of keeping simple. (symbol based)
jeen: agrees with ericP mostly
<ericP> oh weak, just remembered my other point: i wanted to say that saddle could express higher level semantics
jeen: needs to form a more thorough opinion on the issue though
EliasT: what Lee said. I also want what is simplest for the user of SPARQL, which might be seeingonly lean result sets
EliasT:I think simple distinct as ericP defines it, it's fine because one could post-process to get a lean answer. But I'd rather SPARQL have LEAN and DISTINCT.
AndyS: I am not so worried about redundant solutions, it doesn't violate rdf semantics
bijan: there are a number of points
where we need alignment. both forms of distinct are useful. if we
are going to sacrifice one of them we need to be very clear
... i could go either way, as long as we're very clear
<bijan> Well, that's what people disagree :)
<SimonR> The particular interpretation's ability to infer extra statements is directly related to the ability to determine whether solutions are equal. Similarly to the way we leave it up the engine to choose to infer extra statements, it's the enginer rather than the query which can prove that solutions are redundant.
AndyS: i propose "if the graph matching does entailment then distinct does as well."
<SimonR> What kinds of equalities do we have? In simple entailment, we have syntactic equality by name. In D-entailment, we might have additional equalities from the datatype processor. In OWL, we have explicit statements of equality. Any others?
<bijan> There are entailed equalities in OWL
<bijan> And tehre are entailed inequalities wrt the various XSD types in RDF +D-entailment
bijan: there is some question about how to understand literals with lexical types that do not correspond to the datatype
ericP: my approach is that we do not expect tools to handle this
bijan: it is underspecified, and
there are choices that can be made. I do not find ericP's apparent
choice unreasonable per se. but we need to explore the options and
clarify at least
... also have concerns about some of the options being outside our charter
... (but I don't know for sure if that is the case)
andys: does this discussion apply to all operators?
<kendallclark> PatH: sounds like a use/mention issue
<kendallclark> (sorry, UPS at the door)
<kendallclark> jeen: i'm trying to take over
<kendallclark> PROPOSED to meet 22 Aug 14:30 UTC, with PatH scribing
<kendallclark> PROPOSED to adjourn
<kendallclark> ACTION: [DONE] EricP to redraft section 11 to support extensible datatypes [recorded in http://www.w3.org/2006/08/08-dawg-minutes.html#action08]
there is some irc bot wizardry involved in publishing the log and creating the minutes right? can someone help me out?
<kendallclark> ACTION: EricP to redraft section 11 to support extensible datatypes [recorded in http://www.w3.org/2006/08/08-dawg-minutes.html#action08]
<kendallclark> ACTION: [PENDING] LeeF to To review rq24. [recorded in http://www.w3.org/2006/08/08-dawg-minutes.html#action04] [DONE]
<kendallclark> ACTION: [PENDING] DanC to review PFPS's comments for more test cases [recorded in http://www.w3.org/2006/08/08-dawg-minutes.html#action06] [PENDING] [CONTINUED]
<kendallclark> ACTION: [PENDING] EricP to turn FredZ's test case sketches into tests. [recorded in http://www.w3.org/2006/08/08-dawg-minutes.html#action07] [DONE]
kendall: that link contains something which looks relevant to publishing minutes
<kendallclark> ah, thanks