See also: IRC log
DanC notes major technical: semantics are poorly specified
RESOLVED to accept minutes 17 Jan
RESOLVED: to meet again 26 Jan, lee to scribe
DanC: Activity extended through 1 May, (note wg schedule)
DanC: extension message cited in the histroy section
-> http://www.w3.org/2001/sw/DataAccess/#hist histroy section
<DanC> PROPOSED: that editor's draft of SPARQL QL editor's draft v1.613 2006/01/23 13:13:08 addresses issue rdfSemantics and is sufficient to postpone issue owlDisjunction.
<DanC> EF: 2nd
Enrico: agreed
<LeeF> There are still a bunch of @@'s in the current draft.
<LeeF> (Well, maybe not a bunch, but some.)
PatH: has options. needs editorial completion
AndyS: two proposals on how to frame
extensions in a separate document
... 1. set of hooks
AndyS: 2. extension document gives
relations back to the core (SPARQL Query) document
... pref to keep as much in the extension document as possible
PatH: my second issue (mail sent last night): definition of graph pattern
Enrico: PatH's proposal doesn't close
the RDFS and OWL entailment
... extensions have to *contradict* the standard
<patH> Enrico is wrong about that. For OWL we do need to adjust things.
Enrico: introducing simple entailment gives you upward compatibility problems
PatH: we can fix the wording to address this in the current text
<DanC> (musts and shoulds are for protocols)
Enrico: why not just have subgraph matching in the core document?
<kendallclark> I just don't believe shutting off discussion *in this way* is especially helpful or fair or even polite. My two cents.
Enrico: are we agreeing that we have a normative general definition?
PatH: should the SPARQL spec place
normative constraints on how logic extension behave?
... I think we can take your point under advisement and satisfy
your request
<patH> the current text has the general defintion as normative. We just said this is acceptable, up to editorail changes. Edirtorial changes do not change normativity , so :-)
<patH> That was adresed to Enrico.
EliasT: abstain
Enrico: Will we keep the definition of ordered merge and scoping set, ... all of section 2.5
Jeen: don't know -- abstain
Sven: i think that ordered merge definition is not formal enough
Sven: it's currently semiformal
KendallC: we're generally happy with that section
DanC: don't find ordered merge (seems complex) appealing, but if it describes peoples code, am reluctanly happy with it
PatH: don't think we need ordered merge. rest are fine
ericP: would like someone to write an extension document and see if it contradicts the spec. happy either way. more confident if the extension is attempted
LeeF: happier if we don't need ordered merge and e-entailment in the core spec, but if we need that for upwards compatibile, i'm happy
JosD: Disagree because it does not say that blank nodes in a graph pattern are variables
AndyS: current inclination is to not
use ordered merge and use the @@** text
... the ordered merge is not how implementations do it
<DanC> (it's not a priority for me that the formal definitions match implementation techniques)
AndyS: we've rushed through how SPARQL is extended. concentrating on simple entailment with as much latitude as is reasonable
<EnricoFranconi> implementations do subgraph matching, not ordered merge
<EnricoFranconi> ordered merge is useful only for upward compatibility
ACTION: PatH revise Enrico's "Proposed changes" on matching and entailment for solution sequences, esp w.r.t. RDFmerge/order. seems done; there has certainly been lots of relevant mail [DONE] [recorded in http://www.w3.org/2006/01/24-dawg-irc]
<DanC> proposal to edit readme http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0145.html
ACTION: Enrico to review draft text on matching and entailment for solution sequences seems done; there has certainly been lots of relevant mail [DONE] [recorded in http://www.w3.org/2006/01/24-dawg-irc]
ACTION: AndyS to implement test README change from http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0145.html [recorded in http://www.w3.org/2006/01/24-dawg-irc]
ACTION: JosD to make test case from Sergio's basic query patterns examples [DONE] [recorded in http://www.w3.org/2006/01/24-dawg-irc]
DanC: AndyS, what would the disposition of these tests be with would your favorite definitions?
AndyS: yes to 1. requires new text in the test cases doc.
PatH: current definitions break the second answer
ACTION: JosD to put http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0040 into a test manifest [recorded in http://www.w3.org/2006/01/24-dawg-irc]
<LeeF> The 3rd solution breaks some of the coreferentiality of _:a_0
ACTION: AndyS to revise rq23 to remove @@s from 2.5 [recorded in http://www.w3.org/2006/01/24-dawg-irc]
http://www.w3.org/2001/sw/DataAccess/rq23/#FunctionMapping
http://www.w3.org/2001/sw/DataAccess/rq23/#evaluation
<DanC> "Casting in SPARQL is performed by calling a constructor function for the target type on an operand of the source type."
http://www.w3.org/2001/sw/DataAccess/rq23/#operandDataTypes
<DanC> PROPOPSED: that http://www.w3.org/2001/sw/DataAccess/rq23/ 1.613 section 11 addresses issues#valueTesting
<DanC> (looking for comments pending on this issue... http://www.w3.org/2001/sw/DataAccess/issues#valueTesting )
<Zakim> DanC, you wanted to ask about Levering's question http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0011
<DanC> PatH: note equivilence typo
DanC: can you address Ryan Levering'S comment?
EricP: yes, current text addresses them
RESOLVED: that http://www.w3.org/2001/sw/DataAccess/rq23/ 1.613 section 11 addresses issues#valueTesting, UMD abstaining
quick sketch of TP f2f agenda, registration
<AndyS> F2F: 2/3 March at Cannes (W3C all groups meetng)
<AndyS> Agenda covers: LC issues + features to postpone + SPARQL v2
<AndyS> Also meeting #SWIG (Thurs) and RIF (MoTu), SWBPD?
<AndyS> SWBPD maybe Friday
<Zakim> DanC, you wanted to ask in stongest possible terms that we finish LC comments well before the TP
<AndyS> DanC suggests strongly not having LC issues on agenda
<kendallclark> I would love to come to Cannes again... but I didn't know we were meeting and I declined the trip when my boss asked. :)
<kendallclark> oh well
<AndyS> we conclude registration is open (for all meetings at AllGroups)
<DanC> (to repeat: I'm more likely to be at the IG meeting than at DAWG)
<patH> I very much doubt I will be able to make it, but could phone in to any discussions if its worth trying.
ADJOURNED