See also: IRC log
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0192.html
PROPOSED accept http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0192.html at true record oflast week's meeting
seconded and RESOLVED.
RESOLVED to meet next week, Tue Sep 12, with SimonR scribing
<bijan> I am on the call
<scribe> ACTION: bijan to review FredZ Constructive mapping semantics for SPARQL 18 Aug [CONTINUES] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<scribe> ACTION: Bijan to review FredZ 2 Aug and relate to WG issue list [CONTINUES] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<bijan> This is the message that raised the issue:
<bijan> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0186.html
bijan: LeeF's message on filter -> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0186.html
<kendallclark> elias: http://www.w3.org/2006/08/29-dawg-minutes
bijan: Chileans believe scope of filter variables should be fairly narrow
<kendallclark> complexity of SPARQL w/ nested optional is PSPACE?
bijan: nested OPTIONAL pushes up the worst case of SPARQL complexity quite high, which may be new information to reopen nested OPTIONAL issue
<EliasT> kendallclark, the minutes are fine, but the IRC log is 403.
<kendallclark> It's certainly new information, at least, IMO, -- the complexity results.
<FredZ> message 2006JulSep/0186 does not exist
<SimonR> I'm under the impression that we're pretty much obliged to support undecidable languages -- at the very least, OWL-Full...
<AndyS> In what way is it different from SQL?
LeeF: are we chartered to avoid putting constructs in the query language that bump up worst-case complexity?
bijan: not chartered as such, but it was input into decisions re: OPTIONAL at the Boston face to face and might be worth revisiting
<bijan> AndyS, I don't know. Perhaps that'll dispose of the matter. I.e., it doesn't matter
<FredZ> SQL committee routinely adopts features that are known to be difficult
kendallclark: this is new information; proposals to simplify language based on new information are in order, and we will discuss further
<FredZ> on the grounds that you let the user decide whether to run such a query
<AndyS> As far as I can see the complexity is the same as SQL - evidence: there is a mapping to SQL.
<LeeF> Right, that's my feeling as well. (Let the user decide whether to write hard or easy queries.)
<scribe> ACTION: KC to consider a new issue "entailment framework", somewhat like rdfSemantics, though perhaps different [DONE] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<bijan> A polynominal mapping?
<scribe> ACTION: KC to review FredZ 2 Aug for issue updates [CONTINUES] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<AndyS> FredZ, I agree
<scribe> ACTION: Lee to figure out the next step toward publication of SPARQL results format er.. JSON in particular [DONE] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<SimonR> I'll claim my action complete, with thanks to LeeF for forwarding it: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0195.html
<scribe> ACTION: PatH to review FredZ Constructive mapping semantics for SPARQL 18 Aug [CONTINUES] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<bijan> Look, I'm not against computational complexity in general
<bijan> obviously
<AndyS> 1-1 mapping of query to a single SQL statement
<scribe> ACTION: SimonR to review FredZ Constructive mapping semantics for SPARQL 18 Aug [CONTINUES] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<AndyS> (well - not 1-1 : 1 query in, 1 query out)
<bijan> My poitn is that people *have* raised that as a consideration against ceratin choices
<scribe> ACTION: Bijan to see if the Chilean's semantics paper offers any advice re: filters [CONTINUES] [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<bijan> Yeah, so that doesn't show that the compelxity is the same
<AndyS> Bounds it.
<bijan> Nope
<bijan> If you have to map it ot an exponential number of queries
<AndyS> How can the SPARQL query be more complex than it's implementation?
<bijan> Or even an infintie number of queries
<bijan> The implementation might not be complete
kendallclark: what are the editors thoughts on publishing rq24 as a working group WD to satisfy heartbeat requirement and let the community know where we are
<bijan> The implementation is SQL + the mapping
<bijan> If the mapping introduces exponentially many queries
<bijan> Then the complexity of sparql is greater than SQL
ericP: happy to publish as is modulo pubrules ; we have questions that we need to ask the world about the query language (e.g. graph query vs. rdf semantics)
<AndyS> One query => one SQL statement
<SimonR> AndyS, The spec might admit simple solutions rather than one perfect, correct solution. In that way, the implementation might be *very* simple compared to the overall subtlety of the query language itself.
<bijan> If the *size* of the query is exponential, it doesn't matte
<bijan> Same issue
<AndyS> It isn't expoential.
<bijan> Ok
<bijan> But you didn't say that
<bijan> And I'd want a proof that the reductioncaptures the semantics of the sparql
AndyS: what's the purpose of publishing something?
<bijan> (This is a standard technique for showing complexity: if you can give a polynominal reduction of one formalism to another of a known complexity, then you've established an upper bound)
kendallclark: we owe the world/community an update on what we've been doing
<bijan> (But, afaik, no one has shown that for SPARQL relative to SQL, though I'm no expert on SQL complexity)
<AndyS> Err - the implementations?
<bijan> That's not a proof
<FredZ> I am considering writing a general technique for SPARQL->SQL
<FredZ> is that of interest?
<bijan> Of course!
<bijan> Very valuable, IMHO
<AndyS> Yes - and I think it's been done at least twice already.
ericP: i prefer to publish both rq24 and JSON results format, since rq24 is where our recent energies have been going and we haven't looked at JSON results format in a while
<bijan> How do you know the implementation is acutally polynominal in every case?
<bijan> Argh, calling in failures are frustrating me
<scribe> ACTION: SimonR to review rq24 [recorded in http://www.w3.org/2006/08/22-dawg-minutes.html#action07] [DONE]
AndyS: what message are we trying
to give to the community?
... does publishing a WD remove us from CR?
<bijan> I understand from DanC, last week, the WD knocks us out
<AndyS> XPath/Xquery published in CR with fixes.
<SimonR> To remain in CR, I'd suggest Andy is right, it'd take another editorial pass.
AndyS: knowing what happens with the status of the document affects what I spend my time on with respect to getting the text up to publishing quality
SimonR: i think publishing rq24
is the right step forward; if published as is (the fastest way
forward), it's not CR material and we should publish as
WD
... if we want to stay in CR, i suggest we need to do some hole
patching, but most of the hole patching is almost
cosmetic.
... i say, go to WD and publish rq24
FredZ: i believe we should go to WD and I think current rq24 is better than current CR
ericP: i want to publish as quickly as possibly, but with a BIG RED NOTE asking for input into semantics
EliasT: i want to publish, but feel Andy's concerns about being careful going back into WD -- I think we need to make decisions quickly, and not go back into our pre-CR mode where we re-open lots of design decisions, etc.
<SimonR> If we drop back to WD, how long would it take to release a subsequent CR? Do we actually long any time that way compared to holding off on publishing until rq24 is tidied up?
kendallclark: Going to WD does not open all old decisions -- still need burden of proof of new information to open new issues
<AndyS> SimonR - yes, in practice I can't see it not having that effect
EliasT: I agree; I think it's important to psychologically stay in a mode where we try to close issues and keep moving forward
<kendallclark> IMO, having 7 open issues on the issues list means that the horse is already bolted from the barn -- to use a technical phrase :)
bijan: i don't think we can avoid
going back to WD (DISTINCT alone being underspecificed will
require significant changes to document that probably can't be
published as patch to current CR document)
... as Dan pointed out, we might be able to go straight from WD
to PR without having another CR
... i prefer to publish a WD sooner, perhaps with a list of
issues that we're trying to resolve (and appropriate
solicitation for help)
<AndyS> I do not agree with Bijan's summary of DISTINCT.
<bijan> Slight rephrasing of what LeeF scribed: I think putting in a nailed definition of DISTINCT is sufficient to trigger another LC. (There may be no other ramifications.)
kendallclark: my preference is to publish rq24 as is modulo pubrules -- in status of the document section I want to point people to editorial changes and to point to issues lists, particularly open issues, and say that the WG is working to close issues, but we're not sure whta changes if any the issues will make in this document
ericP: don't think we have an open issue for whether bnodes have different semantics from variable
kendallclark: think I overloaded and reopened bnoderef for that issue
<kendallclark> PROPOSAL: To publish rq24 as a Working Draft, including SOTD section written by EricP.
<kendallclark> LeeF, AndyS: no strong opinion
SimonR: Would prefer one more editorial pass
<kendallclark> SimonR: Ideally, after a brief editorial pass, but immediately is fine
kendallclark: prefers immediate publication, also happy with editorial pass if it took a day or two
FredZ: no opinion
JanneS: no opinion
<EliasT> EliasT: no strong opinion
ericP: no strong opinion other than wanting to put big red text in
<bijan> I prefer immediate, but am willing to defer to the editors, if they want to do some minor changes in a small timeframe
<bijan> I'm happy to do that review
<kendallclark> PROPOSAL: To publish rq24 on or shortly after 19 September, after a sanity-check review by BijanP, and after SOTD updates by EricP.
ericP: seconded
RESOLVED, no objections, no abstentions
<bijan> seconded!
<bijan> seconded again!
<bijan> seconded again!
<kendallclark> PROPOSAL: To publish json results doc as a WG Note
<kendallclark> erp
<kendallclark> PROPOSAL: To publish json results doc as a WG Note ASAP.
<kendallclark> heh
<bijan> seconded
<bijan> No
<kendallclark> PROPOSAL: To publish json results doc as a WG Submission ASAP.
<bijan> seconded!
<bijan> seconded!
<AndyS> We will need another WD after this one for SPARQL/language.
<bijan> yes, at least a lc wd
RESOLVED, FredZ abstaining
<bijan> But, as danc said last week, we could move to go to PR straight from LC
<AndyS> For the incompatible syntax changes.
<bijan> Heh. ok, then just substitute those for my point about distinct :)
<AndyS> There are no changes there - clarification is needed, not change.
<bijan> Andy, well, i disagree with that, but for my point *above* all I need is that there is *some* change requiring WD status
<bijan> And, for example, if we chose to use REALLYREALLYDISTINCT, which we could do, then I would imagine you'd feel that was a substantive change
<bijan> ta all
<bijan> secodn!
ADJOURNED.