See also: IRC log
Jan 16. minutes http://www.w3.org/2007/01/16-dawg-minutes
<SimonR> (Sorry, it always does that and I have no idea how to turn it off. It's probably a security feature...)
Approved, AndyS seconding
Jan 23. minutes http://www.w3.org/2007/01/23-dawg-minutes
Approved, AndyS seconding
<SimonR> Meet again next week (Feb 6), SimonR to scribe
<SimonR> LeeF: solicits comments on the agenda (additions, deletions) -- no requests from the group for changes
<scribe> ACTION: AndyS to reply to http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0041 mentioning the possibility of banning the same bnode id from appearing in multiple BGPs in a query [DONE] [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action01]
<scribe> ACTION: LeeF to look back through minutes and mailing list to determine if the group has made a past decision on blank node scope [DONE] [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action02]
<scribe> ACTION: AndyS to reply to Bob M noting changes in examples in curent algebra [CONTINUES] [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action03]
<scribe> ACTION: EricP to run the yacker tool over and annotate the existing tests [CONTINUES] [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action04]
<scribe> ACTION: Jeen to mark approved tests as dawg:approved [CONTINUES] [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action05]
<AndyS> No progess on my action item.
<scribe> ACTION: LeeF to remember that the wee, lost filter tests should be put [CONTINUES] [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action06]
Test sutie status from Jeen: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0050.html
LeeF: <explains blank node label scope issue as per http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0055.html>
AndyS: Sometimes you need to use
blank node labels instead of square brackets (e.g. shared
objects)
... Question is then what is the scope of these labels -- right
now you can't refer to one blank node from a different BGP, but
you can reuse the label to mean a different bnode
... this is confusing
... I'd rather put the burden on the application writer so that
it is something that is caught by the parser
ericP: I'm content with that restriction;
<SimonR> If I recall correctly, we prohibit a variable from being reused between parallel OPTIONAL clauses. I'm still of the impression that when the bnode syntax occurs in a query, it's not an existential (as it would be in a graph), but an `undistinguished' variable. So, the prohibition of reusing variable labels would apply to the undisinguished ones as well.
<AndyS> SimonR : not any more. Can reuse the var - has a natural meaning in the algebra.
<patH> hi, sorry late
<SimonR> AndyS: Turns it into some sort of UNION...?
<ericP> scribe: patH
<AndyS> Turns it into "try this, if not try that"
<SimonR> AndyS, so the order of the OPTIONAL clauses makes a difference now?
<AndyS> SimonR : yes - that is true for SQL left join as well (in the same way)
<LeeF> Straw poll: What do you think about the proposal to make it illegal to include the same blank node label in multiple BGPs in a single query?
simon: like it
eric: yep
suri: happy
<SimonR> If two things are different, the syntax checker forces you to label them differently.
ori: good
pat: as good as itgets
<SimonR> PatH: Doesn't like it, but supports it as the lesser evil
lee: pity about invalidating existing, but good
<LeeF> PROPOSED: Blank node labels are scoped to the BGP in which they appear; it is an illegal query to include the same blank node label in multiple BGPs in a single query
pat: second
<LeeF> RESOLVED
<LeeF> ACTION: AndyS to add text clarifying the prohibition on blank node labels in multiple BGPs to rq25 [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action08]
<LeeF> Andy's test cases on blank node label scope: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0056.html
<LeeF> Andy's test case on the extent of BGPs: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0052.html
<AndyS> Example: { <x> :p _:a . FILTER(true) . <x> :q _:a }
Issue: does a filter break a BGP into two BGPs?
<LeeF> AndyS: tension between principles of FILTERs applying to group and BGPs being adjacent triple patterns
<LeeF> AndyS: If we decide that FILTERs do not break-up a BGP then we probably want a slight grammar change
<sdas2> Was there ever a discussion on banishing FILTER to the far right end?
<LeeF> ericP: I'm imagining a pattern of query writing that highly interleaves triple patterns with the constraints on those patterns, and I'd like to be able to include the same blank node through all of those
<AndyS> Souri - yes - there has been a little.
<AndyS> A balance between that and placing close to the thing it restricts.
<ericP> { _:who foaf:mbox ?mbox FILTER regexp(?mbox, "^mailto:") _:who foaf:name ?name FILTER LANGMATCHES(?name "EN") }
<LeeF> patH: Feels strange to have FILTERs break up scoping which is otherwise in line with the curly braces
<AndyS> c.f. inserting OPTIONAL or even {} which will break the BGP regardless.
<LeeF> AndyS: the principle for demarkating the edges of a BGP has been adjacency of triples
<LeeF> other example: { _:a <p> <o> . { ?x ?y ?z } . _:a <p2> <o2> }
<sdas2> That looks like three BGPs.
<AndyS> { _:a <p> <o> . OPTIONAL { ?x ?y ?z } . _:a <p2> <o2> }
<ericP> { ?a <p> <o> . ?a <p2> <o2> OPTIONAL { ?x ?y ?z } }
<ericP> { ?a <p> <o> OPTIONAL { ?x ?y ?z } . ?a <p2> <o2> }
<LeeF> ericP: is there a difference between the above two constructs?
<LeeF> AndyS: In simple entailment, no; but in higher entailments, perhaps.
<ericP> { _:a <p> <o> . OPTIONAL { ?x ?y ?z } . _:a <p2> <o2> }
<ericP> A
<AndyS> Different again: {OPTIONAL { ?x ?y ?z } . { ?a <p> <o> } ?a <p2> <o2> }
<ericP> { ?a <p> <o> . ?a <p2> <o2> OPTIONAL { ?x ?y ?z } }
<LeeF> patH: If we decided that that *is* one BGP, then that's the way it is and it could/would be sent to a (e.g.) DL engine that way
<LeeF> <discussion of what's the nice design here>
<AndyS> UNION, GRAPH, extra {}
<LeeF> ericP: possibility, say FILTER does not break up BGPs ...
<ericP> '{' pattern '}'
<LeeF> AndyS: I would probably change the production rule name
<LeeF> straw poll: What's your feeling on whether a FILTER should break up a BGP?
<LeeF> patH: does not break up
<LeeF> Orri: at first no, but concerns over passing parts to reasoning engines
<LeeF> Orri: slight preference for not breaking it up
<LeeF> AndyS: slight preference for breaking it up
<LeeF> Souri: prefer not breaking it up
<LeeF> Souri: (since we can always push filters to the end (eqiuvalent meaning), then they shouldn't break up a BGP
<LeeF> ericP: not breaking it up
<LeeF> SimonR: not break it up
good man
<LeeF> PROPOSED: FILTER clauses do not break up a BasicGraphPattern; a BGP is an adjacent block of triples, possibly with interleaved FILTER clauses
<LeeF> ericP seconds
<SimonR> AndyS: abstains
<LeeF> RESOLVED, AndyS abstaining
<LeeF> ACTION: AndyS to clarify the extent of BGPs is not broken up by FILTER clauses and to change production rule name in the grammar [recorded in http://www.w3.org/2007/01/30-dawg-minutes.html#action09]
<LeeF> ericP: I think in a bag language such as SPARQL that existentials have a cardinality of 0 or 1
<LeeF> ericP: current rq25 text uses the word "existential" to describe blank nodes
<LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006OctDec/att-0175/28-dawg-minutes.html#item04
<AndyS> Text in http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#QSynBlankNodes
<AndyS> """Blank nodes in query patterns act as existential variables, not as references to specific blank nodes in the data being queried."""
<AndyS> If it's the text that a problem, what would be better text?
<SimonR> I'm (still) under the impression that graph patterns *never* contain real existential bnodes in the same way that RDF graphs do. You could never assert that an existential in a graph is the same existential in your query, which we determined wasn't very useful back in November. We use the same syntax that was developed for bnodes in graph patterns, but it means undistinguished variables instead.
<SimonR> See Definition 4 in http://www.debruijn.net/publications/ppswr-05.pdf
Simon, there isnt a real diference between undistinguished varaible and existential when we are limited to simple (or RDF.RDFS) entailment. They are the same.
Until you get to the DL case.
<SimonR> Pat, okay, let me meditate upon that. :)
<LeeF> AndyS: I think would be tough to map to SQL with a cardinality of 1 because can't have partial DISTINCT projections in SQL
Simon, the killer change in DL is that the language has disjunction in it. So the 'binding' can be either-this-or-that.
<SimonR> Pat, ahhhhh...
<AndyS> This is the only use of "existential" in rq25.
<SimonR> Pat: it would be okay to treat existentials and non-distinguished variables until to get to an interpretation with disjunction in (such as DL), in which case it causes problems.
much discussion of wording of 4.1.4. Lee thinks essential point is this sets up to fix a possible misunderstanding. Andy thinks nondistinguished better than existential.
maybe.
<sdas2> Aside: Is '?' right in Rule [13] ('WHERE' ? GroupGraphPattern)
<SimonR> We have two kinds of interpretation functions, the ones that satisfy the RDF graph's model (which interpret the bnodes) and the query solutions (which interpret the query variables, nondistinguished and otherwise).
<LeeF> Souri, yes, the WHERE keyword is optional
<sdas2> I see. So, SELECT ?x {?x :name <John>} is ok?
<AndyS> Souri, yes.
<sdas2> Thx.
<AndyS> ASK { ?x :name "John" }
<SimonR> Accept-language: en-SQL, en-logician, en-webdeveloper
<AndyS> unsatisfiable!
Pat apologises in writing for being a lousy scribe.
<AndyS> ADJOURN
<SimonR> ADJOURNED at 15:45 Z