See also: IRC log
<AndyS> SPARQL/Update :: a draft proposal for comment :: http://jena.hpl.hp.com/~afs/SPARQL-Update.html
<LeeF> Agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0146.html
-> http://www.w3.org/2007/03/06-dawg-minutes minutes from 2007-03-06
PROPOSED: approve minutes from 2007-03-06 as a true record of the last meeting
APPROVED
next meeting: 2007-03-20T14:30Z, scribe: EliasT
<LeeF> ACTION: EricP to add text to spec noting that ORDER BY comparisons may use extended implementations of < that operate on types beyond what's given in the operator table [DONE] [recorded in http://www.w3.org/2007/03/13-dawg-irc]
action -1
<LeeF> ACTION: EricP to run the yacker tool over and annotate the existing tests [recorded in http://www.w3.org/2007/03/06-dawg-minutes.html#action03] [CONTINUES]
<LeeF> ACTION: LeeF or EliasT to reply to Bjoern regarding (not) POSTing application/sparql-query documents [recorded in http://www.w3.org/2007/03/06-dawg-minutes.html#action07] [CONTINUES]
<LeeF> ACTION: LeeF to remember that the wee, lost filter tests should be put [recorded in http://www.w3.org/2007/03/06-dawg-minutes.html#action05] [CONTINUES]
-> http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0147 Eric's summary of the DISTINCT issue
LeeF: any epiphones?
SimonR: partial DISTINCTness available via a clever OPTIONAL clause
default keywords
1 ALL DISTINCT
2 ALL DISTINCT, LOOSE
3 LOOSE DISTINCT
4 LOOSE DISTINCT, ALL
5 DISTINCT
Steve: -1 +.5 -1 +1 -1
Jeen: +1 0 0 0 -1
Orri: +1 0 0 0 -1
ericP: +.9 0 -.5 +1 -1
SimonR: 0 0 0 0 0
AndyS: +1 0 -1 -1 -1
patH: +1 +1 0 0 0
EliasT: +1 0 -1 -1 -1
LeeF: appears to be leaning towards 1
SteveH: implementing ALL easy
(and done)
... but I lose a lot of performance
... may implement it, but add a LOOSE keyword
<AndyS> Observation: LOOSE = ALL over an imaginary smaller dataset/graph.
<SimonR> DISTINCT/ALL is sort of the difference between COUNT(PROJECT(X)) and PROJECT(COUNT(X)) -- maybe if projection wasn't tied to the SELECT clause we'd have a better way. (As always, too much change required to explore this....)
Souri: 0 +1 0 0 0
<patH> Not always, I think, Andy. Because that smaller imaginary graph wouldnt give you all the real answers.
<AndyS> Simon - agree - there an overly tight binding of project and expressions
<SteveH> observation: noone disliked 2 explictly
<AndyS> Example: 1,1,1,2,2,2,3,3,3 ORDER BY, LIMIT 3 => 1,1,1 ; 1,2,2 ; 1,1,2 ; 1,2,3 ??
<patH> Can we do 2 but not REQUIRE that loose be supported?
<SteveH> patH, an impl of LOOSE = ALL or DISTINCT is valid
<AndyS> It would be the only optional feature in the spec.
<AndyS> And we have no service descriptions :-)
ericP: now +1 on 2
<LeeF> PROPOSE: SPARQL SELECT queries with no keyword following SELECT must return the precise cardinality of duplicate solutions specified by the algebra; SPARQL contains a @@ LOOSE keyword that allows duplicate solutions to be returned with cardinality of at least 1 and no greater than that specified by the algebra
SteveH: query modification to access functionality is fine for me
+1
AndyS: am reluctant introduce a new keyword for an seemingly arbitrarily selected optimization
<LeeF> Option 1: by default, ALL; only keyword is DISTINCT
ericP: we have a test with counting semantics already. AndyS, SteveH and I passed it but with different assumptions (1 vs 2)
<LeeF> Option 2: by default, ALL; add a @@ LOOSE keyword
EliasT: +1 0
patH: 0 +1
AndyS: +1 -1
<SimonR> SimonR: 0 0
ericP: 0 +1
orri: +1 0
jeen: +1 0
SteveH: -1 +1
Souri: 0 +1
<LeeF> 3 and 3
<AndyS> 3 and 4 on +1's :: each has a -1
LeeF: share andy's concearn, but can mark it "at risk" and let implementors define
AndyS: i think that putting it in and marking it "at risk" is setting the default
out of connearn for Steve-like implementations, i change to: -1 +1
<scribe> ACTION: ericP to draft text about a LOOSE keyword and run it by w3 folks to see if we're abusing the "at risk" mechanism [recorded in http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> ACTION: LeeF to seek guidance about at-risk features from the CG [recorded in http://www.w3.org/2007/03/13-dawg-irc]
LeeF: if that's acceptable, I
will propose 2, otherwise propose 1
... KendallC says we should say what's informative vs.
normative
... AndyS said that unless otherwise noted, numbered sections
are normative and lettered appendicies are informative
... i think that 2 and 3 are informative
I just labeled 2 and 3 informative
<LeeF> ACTION: ericP to mark sections 2 and 3 informative, Appendices B and D normative in the text and table of contents and 1.1 document outline [recorded in http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> nested optionals
LeeF: I believe that the algebra in the document addresses nested optionals
<LeeF> PROPOSED that the current algebra of rq25 addresses http://www.w3.org/2001/sw/DataAccess/issues#nestedOptionals
AndyS: I think it does
APPROVED
<scribe> ACTION: LeeF to close nested optionals issue [recorded in http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> bnodeRef
LeeF: I believe that the current draft addresses this
patH: yes
<LeeF> PROPOSED that the current treatment of bnode labels in rq25 addresses http://www.w3.org/2001/sw/DataAccess/issues#bnodeRef
<AndyS> And we aren't proposing the first part (exposing the labels in results)
APPROVED
<scribe> ACTION: LeeF to close bnodeRef issue [recorded in http://www.w3.org/2007/03/13-dawg-irc]
<scribe> ACTION: PatH to investigate closing the entailment issue [recorded in http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> open world issues
<AndyS> Example: "xyz"@en > "abc"@en
-> http://www.w3.org/2001/sw/DataAccess/rq23/rq25#operatorExtensibility 11.3.1 Operator Extensibility
<LeeF> """
<LeeF> Extended SPARQL implementations may support additional associations between operators and operator functions; this amounts to adding rows to the table above.
<LeeF> """
<AndyS> Example: "xyz"@en = "abc"@EN
<AndyS> Example: "abc"@en = "abc"@EN
<SimonR> (Say, weren't language tags case-sensitive...?)
"abc"@en = "abc"@EN
<LeeF> I think RDF C&AS says they are case insensitive
-> http://www.w3.org/2001/sw/DataAccess/rq23/rq25#func-RDFterm-equal 11.4.10 RDFterm-equal
<LeeF> "Plain literals have a lexical form and optionally a language tag as defined by [RFC-3066], normalized to lowercase."
<LeeF> "Note: The case normalization of language tags is part of the description of the abstract syntax, and consequently the abstract behaviour of RDF applications. It does not constrain an RDF implementation to actually normalize the case. Crucially, the result of comparing two language tags should not be sensitive to the case of the original input."
<LeeF> from -> http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality RDF C&AS
{ "abc"@en = "abc"@EN } => { "abc"@en = "abc"@en }
<LeeF> """
<LeeF> 11.3.1 Operator Extensibility
<LeeF> Extended SPARQL implementations may support additional associations between operators and operator functions; this amounts to adding rows to the table above. No additional operator support may yield a result that replaces any result other than a type error in an unextended implementation. The consequence of this rule is that extended SPARQL implementations will produce at least the same solutions as an unextended implementation, and may, for some queries, produce more
<LeeF> """
[[
SPARQL language extensions may provide additional associations between operators and operator functions; this amounts to adding rows to the table above. No additional operator may yield a result that replaces any result other than a type error in the above table. The consequence of this rule is that SPARQL extensions will produce at least the same solutions as an unextended implementation, and may, for some queries, produce more solutions.
]]
""No additional operator may yield a result that replaces any result other than a type error in the above table.""
<LeeF> PROPOSED that the text in 11.3.1 Operator Extensibility in rq25 addresses http://www.w3.org/2001/sw/DataAccess/issues#openWorldValueTesting
+1
APPROVED: AndyS and patH abstaining
<scribe> ACTION: LeeF to close openWorldValueTesting issue [recorded in http://www.w3.org/2007/03/13-dawg-irc]
LeeF: anyone intending to submit further reviews?
patH: insofar as my action entails a review of section 12, yes