Convene

I'll scribe

yay, me!

<LeeF> Scribe: kendallclark

<scribe> Scribe: kendallclark

+1

<LeeF>

PROPOSED to approve those minutes for last week...APPROVED

Next meeting: 19 Dec, 2006, usual time & place, EricP to scribe

CVS still broken... alas

<scribe> ACTION: Jeen propose test suite process (not do it all). [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action01]

CONTINUE

<scribe> ACTION: LeeF to review rq24-algebra [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action02]

CONTINUE

Review ACTION Items

<scribe> ACTION: KendallC to close formsOfDistinct issue [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action03]

CONTINUE

Operator mapping

<scribe> ACTION: KendallC to remember that the wee, lost filter tests should be put [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action04]

to the question

CONTINUE

<scribe> ACTION: PatH to change the entailment section around to talk about SPARQL [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action05]

first, then more general conditions in a normative appendix

CONTINUE

<scribe> ACTION: ericP to seek clarification on [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action06]

http://www.w3.org/mod/20061110085518567.00000002912@bmacgregor1

CONTINUE

Attendees: +PatH

<LeeF> We're talking about the operator mapping tables at: http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#OperatorMapping

<patH> ok.

<LeeF> ericP on operator mappings:

<LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006OctDec/0190.html

<SimonR> Is "simple literal" official RDF yet, or is it still just an informal name for a plain literal without a specified language?

<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/rq24#OperatorMapping [[

<AndyS> http://www.w3.org/TR/rdf-mt/#DtypeRules

<ericP> When selecting the operator definition for a given set of parameters, the definition with the most specific parameters applies. For instance, when evaluating xsd:integer = xsd:signedInt, the definition for = with two numeric parameters applies, rather than the one with two RDF terms. The table is arranged so that upper-most viable candiate is the most specific.

<AndyS> rules xsd 1a and 1b

<ericP> ]]

<LeeF> SimonR, in 11.1 our spec defines "simple literal denotes a plain literal with no language tag."

<SimonR> Thank you!

<LeeF> yw

<patH> yes, andy Ur right

<LeeF> PROPOSED: accept the changes to the operator mapping table suggested in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006OctDec/0190.html

<ericP> [[

<ericP> >A = B simple literal simple literal

<ericP> > op:numeric-equal(fn:compare(A, B), 0)

<ericP> >A = B xsd:string xsd:string

<ericP> > op:numeric-equal(fn:compare(STR(A), STR(B)), 0)

<LeeF> seconded by AndyS

<ericP> >A != B simple literal simple literal

<ericP> > fn:not(op:numeric-equal(fn:compare(A, B), 0))

<ericP> >A != B xsd:string xsd:string

<ericP> > fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 0))

<ericP> ]]

<LeeF> APPROVEd, no objections, no abstentions

who's that action on?

<scribe> ACTION: EricP to sort out some string literal thing for the operator table [recorded in http://www.w3.org/2006/12/12-dawg-minutes.html#action07]

ok, not the most accurate action, but I missed some of the discussion

Bob MacGregor's comments on UNSAID

<LeeF>

<ericP> Andy: not sure that simple literal arguments to fn:compare pass it an xsd datatype

<ericP> ... not sure that we need the STR()s

<ericP> .

btw, McGregor's demonstrably wrong about large scale reasoning systems. They don't *all* or even mostly assume UNA and CWA. That's just REALLY dumb.

<AndyS> quite

<patH> Yes, he does tend to overstate his case. But he does havea case.

well, not based on THAT claim. It's silly.

<SimonR> I'd say it's a lot easier to add UNSAID than to remove it. RDF's deliberately designed for *minimum* useful expressiveness.

<SimonR> (At a later date or in an extension, that is.)

I propose that we tell McGregory (and Axel!) thanks but no thanks.

<AndyS> I see no new information. Here, "Closed" for me means "closed for v1" = "posponed"

also a similarity with Mark Baker

FWIW

EricP: on behalf of the working group...

heh, just kidding!

yay!!!

do you promise?

FILTER interaction with OPTIONAL/LeftJoin

<LeeF>

<LeeF> {

<LeeF> ?x foaf:age ?age .

<LeeF> OPTIONAL { ?x ex:salary ?salary . FILTER (?age > 18 ) .

<LeeF> ?x foaf:name ?name

<LeeF> }

<sdas2> missing }

<LeeF> whoops =)

<AndyS> { ?x :q ?v . OPTIONAL { ?x :p ?w } }

<AndyS> { ?x :q ?v . OPTIONAL { ?y :p ?w FILTER(?x = ?y) } }

<LeeF> 10 01{ ?v :q ?x . OPTIONAL { ?w :p ?y FILTER(?x = ?y) } }

<SimonR> D'oh!

<patH> sounds like we all violently agree.

<LeeF> PROPOSED: FILTERs in the right-hand side of an OPTIONAL are scoped to include the left-hand side as well

<LeeF> seconded.

Souri abstaining

<LeeF> approved, souri abstaining

ericP's response to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Nov/0004.html

<ericP> [[

<ericP> The faceted navigation product that my company sells generates RDF

<ericP> queries that cannot be expressed in SPARQL because they frequently

<ericP> use an OR connective that includes both statements and filters within

<ericP> the disjuncts.

<ericP> ]]

<ericP> - example of such a query not expressible in SPARQL?

<ericP> recursive syntax

<ericP> - do you mean SUBSELECTs?

<sdas2> The link does not work for me.

<LeeF>

<LeeF> that one, Souri ?

<ericP> closed world semantics

<ericP> - specific examples that are specifically precluded by the open-world semantics

<scribe> *closed*-world semantics are impractical?

isn't the the opposite of what one usually hears?

<sdas2> nevermind

ah good :)

<sdas2> Thanks Lee

<LeeF> yw

<LeeF> [[

<LeeF> - The UNBOUND operator is inherently procedural in a fully-expressive

<LeeF> logic language. In PowerLoom, we added a "Prolog-mode" (we didn't

<LeeF> call it that) when we used operators that couldn't be reordered by

<LeeF> the query optimizer. The WHERE/FILTER blotch is inherently procedural,

<LeeF> which solves the problem, but in a bad way.

<LeeF> ]]

<ericP> If my recollection SPARQL omits n-ary computed predicates (implementing

<ericP> only n-ary functions).

<SimonR> Didn't the SWBP group publish a Note about how do deal with N-ary predicates...? (Can't recall for certain.)

<SimonR> ...to deal...

<patH> yes it did.

and for doing a good job today :)

<SimonR> I think it wouldn't hurt to have, say, syntactic sugar for something useful like N-ary predicates. We do enough for collections and containers, for instance.

<LeeF> kendallclark, two things:

ericp: will you do the minutes magic so I can prep them?

<LeeF> 1) ...

<LeeF> that was one

<LeeF> 2) can we setup a time to talk on the phone about process stuff ?