See also: IRC log
<SimonR> I'll preemptively volunteer for Feb 6, though.
Meet next: 30 Jan, PatH to scribe
Orri: Orri of OpenLink Software
<SimonR> Orri's intro: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0037.html
Orri: background in AI and databases; main author of SQL and core functionality of Virtuoso database
Orri: sees RDF as the lingua franca for data integration on the Net and enterprise
<scribe> ACTION: Jeen to do further cosmetic rearranging of SyntaxDev tests and then commit them to CVS [DONE] [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action01]
<scribe> ACTION: LeeF to check if SteveH can eyeball Jeen's first group of tests pre-WG approval (LeeF and iv_an_ru will also try to eyeball) [DONE] [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action02]
<scribe> ACTION: LeeF to seek early and later reviewers of rq25 [DONE] [recorded in http://www.w3.org/2007/01/23-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/23-dawg-minutes.html#action04]
<scribe> ACTION: LeeF to remember that the wee, lost filter tests should be put [CONTINUES] [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action05]
Jeen's messages -> http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0026.html
<jeen> test suite reorg -> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/
LeeF: Ran the syntax tests --
failures were either from unknown functions or Unicode escape
problems (\u)
... eyeballed problem tests and were convinced that problems
were with implementation and not tests
Jeen: Similar for Sesame parser
-- failing tests seemed to be OK tests but implementation
problems
... one issue I ran into was with the resolution relative
URIs
<scribe> Scribe: LeeF
Jeen: our parser does not have a functionality for dealing with queries from an embedded entity so it does not handle base URIs set from outside the query
<ericP> eek!
<SimonR> So, the test is *requiring* local IRI support to pass.
<AndyS> http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#iriRefs
ericP: could we change the tests to not test that particular issue [relative URI resolution]?
<SimonR> Jeen: Including a BASE clause in the test would fix it.
jeen: as far as I'm concerned, adding a base URI would fix it
AndyS: queries already have a notion of a base as they're named by URI
<AndyS> rel URI is part of the grammar as noted above
AndyS: resoltuion of relative URIs *is* parse related
<ericP> PROPOSAL: not test anything hard
<AndyS> Opposed.
SELECT ?s ?p ?o { ?s ?p ?o }
<jeen> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/syntax-sparql2/syntax-general-01.rq
jeen: what if we added a specific parser test for relative URIs, and did not use them (or used them with a BASE clause) in the rest of the syntax tests?
<patH> Gicves DAWG a new meaning
<SimonR> EricP, it's an issue of being able to set up a standard test environment, when part of the environment is the location you're testing in. O_o
<AndyS> AndyS: the syntax-general* tests are about RDF termsand this is one feature for that.
<SimonR> Just adding BASE clauses means the non-BASE codepath doesn't get tested... :/
ericP: what if we have some queries whose only purpose is to test relative URIs with no BASE clause (and add BASEs to the rest) ?
jeen: Perhaps these queries are actually designed to test this particular feature
<AndyS> s/syntax-general/syntax-terms/g ???
<AndyS> syntax-function-01.rq
<SimonR> LeeF: Inquires whether the "unknown function" situation is related to this issue?
<jeen> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/syntax-sparql2/syntax-function-01.rq
AndyS: No guarantee of any functions that exist
ericP: We could make one up for tests and let people know that
AndyS: I think that q:name - http://example.org/name - is the only one we use
ericP: If we changed this to w3.org/.... we could put a resolvable document there
AndyS: I'd like to have a syntax test for zero arguments, one argument, two arguments, ...
<ericP> echo concat | tr A-Za-z N-ZA-Mn-za-m
<ericP> pbapng
<patH> I have to leave for about 5 mins. Back soon.
<patH> Back now.
-> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/syntax-sparql3/bnodes-missing-pvalues-01.rq
<AndyS> revision 1.1
<AndyS> date: 2005/06/30
<AndyS> ARQ passes 181 syntax tests.
PROPOSED: To approve the syntax tests referenced by http://www.w3.org/2001/sw/DataAccess/tests/data-r2/manifest-syntax.ttl conditional on renaming all negative tests to include -bad-
RESOLVED
<scribe> ACTION: Jeen to mark approved tests as dawg:approved [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action06]
<SimonR> No objection to skipping ahead to item 6.
<SimonR> LeeF: Souri, Orri and SteveH have agreed to do an early review of rq25 (~this week or next)
<SimonR> LeeF: Simon and Kendall have agreed to do later reviews.
<ericP> ericP's issues from rq25
<SimonR> EricP: Has noted various things during an editor's pass over rq25
<ericP> WHERE { _:who foaf:mboxMD5 "A2BA23432B434443D45DF655A6C6E6E";
<ericP> foaf:nick ?nick
<ericP> OPTIONAL { _:who foaf:mbox ?mbox } }
ericP: I think that this query is confusing with _:who acting as a different blank node in two different BGPs
AndyS: We need this for extension
- for instance, sending BGP components off to a DL reasoner
treating it as an existential
... If it were a named variable, you'd be obliged to come back
with a binding for it
patH: I think that's an implementation issue -- if we specify that the blank node is the same, they'll need to keep track
<SimonR> I think a better way to think of _:who is as a "blank variable" -- the only difference between it and a "named" variable is that we're obliged to project it away. (Not sure what the impact on cardinality is, off the top of my head.)
LeeF: Where do people lean on bnode scope?
<patH> me too
SimonR: look like blank nodes, but act like variables (this is what we worked through in November)
jeen: +1 Simon. Would like to check how our implementation handles it.
Orri: My initial reaction is that wherever something is referred to by a name it should be the same thing, but not familiar with counter arguments
AndyS: We can make it easier; need to respect that blank nodes are different than query variables - would suggest that it's illegal to use the same bnode label across graph patterns
<SimonR> AndyS: Suggests making it illegal to reuse bnode labels between BGPs.
<SimonR> PatH: Thinks the bnode ID scope ought to be the "document" boundary. In fact, thinks that scope should be across BGPs.
patH: i think the scope of the bnode IDs should be the "document" -- i think it violates RDF design to have bnode id scope smaller than document boundary -- implies that bnode id scope cross BGPs
ericP: Initial thought is that
the example in
http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0041
is a conundrum query
... andy's suggestion would work - would further differentiate
blank nodes, reserving some space for DL folks to work with
them
<SimonR> I think it'd be helpful to rename them as "bvars" to avoid confusion.
ericP: leaning towards they're just variables
<ericP> +1
<SimonR> Proposed and tacitly approved to go into extra time.
<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 [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action07]
<patH> suggest distinguish two issues: DL folk insist (correctly) that bnodes are not the same as unnamed variables (issue 1); but the scope of bnodes across parts of a query seems klike a different issue.
<patH> klike/like
<SimonR> LeeF: Thinks consensus seems to be forming around treating bnode IDs as scoped to the query. Would like Kendall's thoughts particularly for DL input.
<SimonR> LeeF: Will definitely put this on next week's agenda.
<SimonR> AndyS: Worried about reopening a previous decision that BGPs were the unit of entailment.
AndyS: Changing this would undo the principle of the LC1 decision to make the BGP the extension point
<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 [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action08]
-> http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0041
<ericP> 7 Matching Alternatives
<ericP> Query results involving a pattern containing GP1 and GP2 will
<ericP> include separate solutions for each match where GP1 and GP2 give
<ericP> rise to *different* sets of bindings.
AndyS: The algebra says that SELECT * { {?s ?p ?o } UNION {?s ?p ?o}} will hae duplicate solutions
AndyS: His examples will change when the algebra come along - what should we do about that?
<AndyS> { FILTER(?x) } will be a change
<scribe> ACTION: AndyS to reply to Bob M noting changes in examples in curent algebra [recorded in http://www.w3.org/2007/01/23-dawg-minutes.html#action09]
<SimonR> Adjourned at 15:50 Z.
<AndyS> The modified test names work for me.