See also: IRC log
See minutes of 12/Sept closes nonLiteralValueTesting
RESOLUTION: to accept the minutes of 12 Sept 2006
RESOLUTION: to meet Oct 10, scribe LeeF
Possible missing actions: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006OctDec/0014.html
<kendallclark> ACTION: bijan to review FredZ Constructive mapping semantics for [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action01]
<kendallclark> SPARQL 18 Aug [recorded in http://www.w3.org/2006/09/05-dawg-irc]
<kendallclark> DONE
<kendallclark> ACTION: [PENDING] Bijan to review FredZ 2 Aug and relate to WG issue list [DONE] [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action02]
<kendallclark> ACTION: [PENDING] KC to review FredZ 2 Aug for issue updates [DONE] [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action03]
<kendallclark> ACTION: Bijan to see if the Chilean's semantics paper offers any [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action04]
<kendallclark> advice re: filters
<kendallclark> CONTINUES
<kendallclark> ACTION: bijan to write some text on the D-entailment issue [CONTINUES] [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action05]
<kendallclark> ACTION: BijanP to propose some editorial clarification text around DATATYPE [CONTINUES] [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action06]
<kendallclark> ericP effect: DATATYE (RDF term) => IRI | "" => xsd:string, ""@foo => error, ""^^X => X, blank node => error, IRI
<kendallclark> DONE
<scribe> ACTION: [DONE] ericP to send mail describing how [VTV] and [BTV] illustrate basic graph matching conflicts between LC1 and LC2 semantics [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action08]
<ericP> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0248
discussion
around this to continue
... KC asks Eric to send email to push it up the stack
<bijan> AndyS, when I was reading rq24 I noticed that it seems like there has been introduced in a lot of the definition a sort of functional syntax for the algebraic operations. Is this right? Is it systmatic?
<LeeF> issue was cross-site xmlhttprequest
EricP: pub of rq24 depends on
Bijan's review - got conditional "yes"
... partial text removal (union red text)
Bijan: not conditional as such - can publish
EricP: What about the issues list comment?
Bijan: remove misleading
stuff
... union was one part of this
Bijan's email: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006OctDec/0001.html
<kendallclark> I'd like for it to be struck.
Kendall: wants text on costs removed.
<kendallclark> Hmm, no. I said I want explanatory, construction text removed.
<kendallclark> for the record :)
Bijan: text is not accurate and so may be confusing - better to not mention
<kendallclark> I said across the board I don't like meta-commentary in a spec.
<bijan> Why do we need to do this *now* for this pub?
<bijan> Why not later?
http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html is the doc itself
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/rq24#bnodeRef
<ericP> [[
<ericP> Costs: Tableau-based reasoners (at least, the Pellet Demo example 7) rely on the current, more expressive semantics to match implications that are not in a materializable RDF graph.
<ericP> ]]
<bijan> ericP was totally garbled for me
EricP: it tries to explain why we need non-distinguished variables
Bijan: two forms of variables
allows more expressive queries
... not about non-distinguished variables in patterns
<ericP> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#BasicGraphPatternMatching
<ericP> vs. http://www.w3.org/TR/2006/WD-rdf-sparql-query-20060220/#BasicGraphPatternMatching
EricP: explain why there is a change in the way bNodes got implemented
Bijan: why is this about Pellet?
EricP: key is why subgraph is not sufficient
Bijan: no materialization of a graph that allows OWL-DL reasoner to integrate
<kendallclark> Hmm, so, that's 8 minutes of discussion, and I still don't hear a *candidate* for text that everyone will agree with.
PatH: suggest drop cost/benefit sections
<kendallclark> I suggest dropping the whole 'pink box'.
<kendallclark> +50
PatH: it's harmless
Kendall: Bijan's has reviewed as
per the resolution
... Bijan wants it removed; Eric wants it to go as is.
Bijan: offer to send email on the topic after publication
<bijan> +1 to kendall
<bijan> My point is that the purpose of this pink box is to make a difficult issue clear, it just fails
Kendall: SW-CG want this
text.
... to get community feedback
Kendall: ErciP: what else would prevent pub this week?
EricP: nothing
EricP: nothing
[[ PatH chairs for this item ]]
Bijan: summarises issues for
literals
... equality is value space or term sensitive
PatH: could have a limited amout of value sensitivity - e.g. normal forms for lexcial forms
Bijan: Fred said that there might be impls that do not retain the input form.
<ericP> how many answers will you get with DISTINCT on the non-DISTINCT dataset?:
<ericP> | type | size |
<ericP> | shoe | "10"^^xsd:integer |
<ericP> | shoe | "10"^^xsd:float |
<ericP> | shoe | "010"^^xsd:float |
AndyS: nothing about canonical forms here - this is not about reading the graph.
EricP: arises for anything to do
with returning a variable in SELECT
... not about DISTINCT per se
Path: hears agreement on surface
form usage - Bijan: no
... meant two literals are equal if same lex + datatype.
Nothing about input
Bijan: need to do something about the loading process
AndyS: there is text around FROM for this.
<SimonR> Do we need to specify a minimum set of node equalities that MUST be evaluated, and a maximum set of equalities that may be distinguished? If they're not the same, then the implementations will possibly vary. Otherwise, we have to choose One True Equality, right?
Bijan: if this is clear, I'm fine with term distinct
<ericP> PROPSEO: DINSTINCTness depends of the surface form of the literal
<bijan> I don't find the langauge about "Dervied" on input
Bijan, I can't remember the keyword - there is something - it was a long debate a long time ago :-)
<bijan> Heh
PROPOSAL: DISTINCTness depends of the surface form of the literal (term distinct)
<kendallclark> proper search engine optimization :)
<kendallclark> We just spent nearly 20 minutes discussing informative text, so that may be overly optimistic.
Seconded: EricP
<ericP> APPROVED
<LeeF> can we get actions to get text in place for this?
RESOLUTION: DISTINCTness depends of the surface form of the literal (term distinct)
<ericP> APPROVED: Bijan abstains
<kendallclark> ACTION: KendallC to close formsOfDistinct issue [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action09]
<ericP> ACTION: Bijan to propose text regarding normalization (massaging in general) while reading graphs in [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action10]
<patH> Bijan requested that informative text be provided warning users about sensitivity of results to implementation stategies on graph input. (Bijan, OK??)
<scribe> ACTION: AndyS to edit text for DISTINCT = term-distinct [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action11]
[[ Kendall returns to the chair ]]
LeeF: 2 issues :: 1/ unbound variables and 2/ scope of filters
Kendall: let's talk about scope of filters
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Sep/0001
<
AndyS: Current 11.2 text discusses unbound variables
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/rq24#evaluation
<
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/rq24#ebv
AndyS: making 11.2.2. match 11.2
(11.2.2 is EBV)
<bijan> I'mnot ready to talk about scope of variables or filters at the moment, sorry
<kendallclark> PROPOSED: to accept the changes outlined in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Sep/0001
RESOLUTION: to accept the changes outlined in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Sep/0001<ericP> APPROVED: KendallC, patH and Bijan abstaining
LeeF has proposed that filter scope is the group, not the BGP alone
...believes that the scope is expected to be the group
<ericP> { ?who foaf:name ?name
<ericP> FILTER (?age > 7)
<ericP> ?who foaf:age ?age }
<LeeF> I think FredZ endorsed the group scope in his attachment to
<LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0277.html
<ericP> { ?who foaf:name ?name
<ericP> OPTIONAL { ?who foaf:age ?age }
<ericP> OPTIONAL { ?who my:age ?age }
<ericP> FILTER (?age > 7) }
<AndyS> Better example.
<ericP> 1st was just to illustrate the responsibility of FILTERing vars before they are bound
<kendallclark> LeeF: here's fred's agreement: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0251.html
<kendallclark> This looks like the best semantics to me.
<kendallclark> I think that in general users will want to be able to sprinkle their FILTERs
<kendallclark> throughout their patterns and they should not have to worry about subtle
<kendallclark> differences depending on where they deposit a FILTER.
<LeeF> thanks, Kendall
<ericP> { ?who foaf:name ?name FILTER regexp(?name, "^Bob")
<ericP> ?who foaf:age ?age FILTER (?age > 7 }
<bijan> But how does it interact withoptional?
<kendallclark> Hmm, I'm curious whether anyone has an opinion on the next move:
<kendallclark> 1. approve Lee's tests and vote on this next week
<kendallclark> 2. approve tests and vote now
SimonR: worried if we are saying
ordering is about impl hacks
... had a graph with the mathematical facts (infinite)
EricP: are we in agreement with FILTER/regex example above (filter with ?name)?
PatH: usually restrict to actual graph terms
EricP: FredZ proposed text
<bijan> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jun/0008.html
<bijan> May or may not be related
<AndyS> What exactly is the text?
AndyS:Bijan, no I don'think it is the same - they were talking about unbound, not placement
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0169.html
<bijan> mentioned in the FILTER condition to those in the pattern that is being
<bijan> filtered."""
<bijan> Sigh
<bijan> Stupid client
<kendallclark> ACTION: KendallC to put scope of filters at the top of next week's agenda [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action12]
<patH> bijan, sounds like Jorge is talking about possible syntactic error, right? If so I agree with him.
Tests are some fixes and some for datatype()
<ericP> here's what's currently in 11
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/rq24#operandDataTypes
<ericP> simple literal denotes a plain literal with no language tag.
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/rq24#func-datatype
<ericP> Returns the datatype IRI of ltrl if ltrl is a typed literal; returns xsd:string if ltrl is a simple literal; produces an error otherwise.
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0169.html
<bijan> Just for my curiosity, have we fixed the issues raised in: http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jun/0008.html ?
<kendallclark> ACTION: PatH to review the proposed tests in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0169.html and say yay or nay [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action13]
<bijan> E.g., """for some graph patterns P it is not always the case that {P . P} gives the same result as { P }."""
<kendallclark> ACTION: EricP to review the tests in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0180.html and say yay or nay [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action14]
<scribe> ACTION: Bijan review rq24 against http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jun/0008.html [recorded in http://www.w3.org/2006/10/03-dawg-minutes.html#action15]
Kendall: does not have time to
chair and edit the protocol spec
... asked Elias and Lee to become editors
... and they have agreed
<bijan> kendall, perhaps send an annouce of the appt to the mailing list?
<ericP> sounds good to me