- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 14 Mar 2007 16:13:37 -0400
- To: public-rdf-dawg@w3.org
- Message-ID: <20070314201337.GP13846@w3.org>
http://www.w3.org/2007/03/13-dawg-minutes
[1]W3C
RDF DAWG Weekly
13 Mar 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
AndyS EliasT LeeF Orri PatH SimonR Souri SteveH ericP iv_an_ru
jeen
Regrets
Chair
LeeF
Scribe
EricP
Contents
* [4]Topics
1. [5]review action items
2. [6]unexpected/auto DISTINCT
3. [7]issues list purge
* [8]Summary of Action Items
_________________________________________________________________
<AndyS> SPARQL/Update :: a draft proposal for comment ::
[9]http://jena.hpl.hp.com/~afs/SPARQL-Update.html
<LeeF> Agenda:
[10]http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/014
6.html
-> [11]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
review action items
<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
[12]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
[13]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
[14]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
[15]http://www.w3.org/2007/03/06-dawg-minutes.html#action05]
[CONTINUES]
unexpected/auto DISTINCT
->
[16]http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/014
7 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 [17]http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> ACTION: LeeF to seek guidance about at-risk features from the
CG [recorded in [18]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 [19]http://www.w3.org/2007/03/13-dawg-irc]
issues list purge
<LeeF> [20]nested optionals
LeeF: I believe that the algebra in the document addresses nested
optionals
<LeeF> PROPOSED that the current algebra of rq25 addresses
[21]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
[22]http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> [23]bnodeRef
LeeF: I believe that the current draft addresses this
patH: yes
<LeeF> PROPOSED that the current treatment of bnode labels in rq25
addresses [24]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
[25]http://www.w3.org/2007/03/13-dawg-irc]
<scribe> ACTION: PatH to investigate closing the entailment issue
[recorded in [26]http://www.w3.org/2007/03/13-dawg-irc]
<LeeF> [27]open world issues
<AndyS> Example: "xyz"@en > "abc"@en
->
[28]http://www.w3.org/2001/sw/DataAccess/rq23/rq25#operatorExtensibili
ty 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
->
[29]http://www.w3.org/2001/sw/DataAccess/rq23/rq25#func-RDFterm-equal
11.4.10 RDFterm-equal
<LeeF>
<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 ->
[30]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
[31]http://www.w3.org/2001/sw/DataAccess/issues#openWorldValueTesting
+1
APPROVED: AndyS and patH abstaining
<scribe> ACTION: LeeF to close openWorldValueTesting issue [recorded
in [32]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
Summary of Action Items
[NEW] 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
[33]http://www.w3.org/2007/03/13-dawg-irc]
[NEW] 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 [34]http://www.w3.org/2007/03/13-dawg-irc]
[NEW] ACTION: LeeF to close bnodeRef issue [recorded in
[35]http://www.w3.org/2007/03/13-dawg-irc]
[NEW] ACTION: LeeF to close nested optionals issue [recorded in
[36]http://www.w3.org/2007/03/13-dawg-irc]
[NEW] ACTION: LeeF to close openWorldValueTesting issue [recorded in
[37]http://www.w3.org/2007/03/13-dawg-irc]
[NEW] ACTION: LeeF to seek guidance about at-risk features from the CG
[recorded in [38]http://www.w3.org/2007/03/13-dawg-irc]
[NEW] ACTION: PatH to investigate closing the entailment issue
[recorded in [39]http://www.w3.org/2007/03/13-dawg-irc]
[PENDING] ACTION: EricP to run the yacker tool over and annotate the
existing tests [recorded in
[40]http://www.w3.org/2007/03/06-dawg-minutes.html#action03]
[PENDING] ACTION: LeeF or EliasT to reply to Bjoern regarding (not)
POSTing application/sparql-query documents [recorded in
[41]http://www.w3.org/2007/03/06-dawg-minutes.html#action07]
[PENDING] ACTION: LeeF to remember that the wee, lost filter tests
should be put [recorded in
[42]http://www.w3.org/2007/03/06-dawg-minutes.html#action05]
[DONE] 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 [recorded in
[43]http://www.w3.org/2007/03/13-dawg-irc]
[End of minutes]
_________________________________________________________________
Minutes formatted by David Booth's [44]scribe.perl version 1.128
([45]CVS log)
$Date: 2007/03/14 20:10:55 $
References
Visible links
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0146.html
3. http://www.w3.org/2007/03/13-dawg-irc
4. http://mouni.local/2007/03/13-dawg-minutes#agenda
5. http://mouni.local/2007/03/13-dawg-minutes#item01
6. http://mouni.local/2007/03/13-dawg-minutes#item02
7. http://mouni.local/2007/03/13-dawg-minutes#item03
8. http://mouni.local/2007/03/13-dawg-minutes#ActionSummary
9. http://jena.hpl.hp.com/~afs/SPARQL-Update.html
10. http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0146.html
11. http://www.w3.org/2007/03/06-dawg-minutes
12. http://www.w3.org/2007/03/13-dawg-irc
13. http://www.w3.org/2007/03/06-dawg-minutes.html#action03
14. http://www.w3.org/2007/03/06-dawg-minutes.html#action07
15. http://www.w3.org/2007/03/06-dawg-minutes.html#action05
16. http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0147
17. http://www.w3.org/2007/03/13-dawg-irc
18. http://www.w3.org/2007/03/13-dawg-irc
19. http://www.w3.org/2007/03/13-dawg-irc
20. http://www.w3.org/2001/sw/DataAccess/issues#nestedOptionals
21. http://www.w3.org/2001/sw/DataAccess/issues#nestedOptionals
22. http://www.w3.org/2007/03/13-dawg-irc
23. http://www.w3.org/2001/sw/DataAccess/issues#bnodeRef
24. http://www.w3.org/2001/sw/DataAccess/issues#bnodeRef
25. http://www.w3.org/2007/03/13-dawg-irc
26. http://www.w3.org/2007/03/13-dawg-irc
27. http://www.w3.org/2001/sw/DataAccess/issues#openWorldValueTesting
28. http://www.w3.org/2001/sw/DataAccess/rq23/rq25#operatorExtensibility
29. http://www.w3.org/2001/sw/DataAccess/rq23/rq25#func-RDFterm-equal
30. http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality
31. http://www.w3.org/2001/sw/DataAccess/issues#openWorldValueTesting
32. http://www.w3.org/2007/03/13-dawg-irc
33. http://www.w3.org/2007/03/13-dawg-irc
34. http://www.w3.org/2007/03/13-dawg-irc
35. http://www.w3.org/2007/03/13-dawg-irc
36. http://www.w3.org/2007/03/13-dawg-irc
37. http://www.w3.org/2007/03/13-dawg-irc
38. http://www.w3.org/2007/03/13-dawg-irc
39. http://www.w3.org/2007/03/13-dawg-irc
40. http://www.w3.org/2007/03/06-dawg-minutes.html#action03
41. http://www.w3.org/2007/03/06-dawg-minutes.html#action07
42. http://www.w3.org/2007/03/06-dawg-minutes.html#action05
43. http://www.w3.org/2007/03/13-dawg-irc
44. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
45. http://dev.w3.org/cvsweb/2002/scribe/
Hidden links:
46. http://www.w3.org/2001/sw/DataAccess/rq23/rq25#func-RDFterm-equal
--
-eric
office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell: +1.857.222.5741
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Wednesday, 14 March 2007 20:13:48 UTC