See also: IRC log, proposed agenda
scribe: KendallC + EricP
RESOLVED to approve minutes 7 Jun , minutes 14 Jun
Regrets (partial): HowardK
RESOLVED to meet again 5 Jul per regular schedule; EricP to scribe
Note: 4 July is a holiday in the US.
There is an offer to host in BRS, from HP for most (but not all) of the weeks in August
<DaveB> I like brs in august :)
<Yoshio> in which week of August?
<kendall> I'll be in Houston for some 7 to 10 day stretch during August, but I'll try to avoid overlap with f2f.
<ericP> ericP +1 to BRS in august in the range of 8-Aug - 18-Aug
note HP offer again.
Chair suffers ennui, capitulates for now. :>
public-rdf-dawg-comments archive
DanC has a long outstanding comment re: INSERT...
discussion of blank node comments
Tests affected by the proposal:
<DaveB> 08: WHERE { :a. x.: : . }
WHERE { :a. x.: : . }
Is there any new evidence to reopen the dots-in-qnames decision?
<kendall> Other than that people keep being unhappy about it?
EricP completely ambivalent.
PatH wonders whether redefining qname syntax is any of our business, suggests intra-spec consistency more important than minor (?) bits of convenience
<kendall> +1 for XML qname rules from me
<SteveH> yes, +1 for XML rules
Differences from XML: _foo:bar are not allowed.
Differences from XML: foo: are allowed.
<DaveB> andy says _:a is not allowed - diff from xml
<DaveB> and currently _foo:bar also not allowed
JosD notes considerable deployment of { a b c. }
<DaveB> turtle's never allowed a b c.
<kendall> (hmm, epistemic sins may seem to license future sins! :>)
<SteveH> ericP, generated queries would need special rules for qnames with .s
<DaveB> they'll need special rules anyway to escape <s, "s etc. etc.
EricP: Note that qnames are just
short-hand; in the general case, you can write out the full
URI.
a:b a:c <http://example.org/#foo.>
vs.
a:b a:c c:foo.
In a larger context:
{ a:b a:c c:foo. .
a:d a:e a:f }
<ericP> DaveB, i read c:foo.... as <$ns{c}:foo....>
<AndyS> Is < legal in an IRI at all?
<DaveB> you can use \u002E always anwyay
<kendall> eek
POLL: (a) not dots in qnames (b) dots in qnames except at the end (c) dots in qnames even at the end
a -4
a -5
b -1
c -1
c -2
<kendall> and qname rules are already maximally arbitrary, so one more bit isn't really one more! :>
RESOLVED: to allow dots in qnames except at the end. Dave, Pat abstain
<ericP> i'm happy for a decision
<kendall> ACTION: JosD to fix up the relevant tests [recorded in http://www.w3.org/2005/06/28-dawg-minutes.html#action01]
tests/data/i18n/normalization-01.rq
ACTION: EricP add a note that users should be aware of non-canonicalization of IRIs
ACTION: SteveH to review the relevant test case re: IRI normalization
Refining Optionals from AndyS
ACTION: PatH to review new optionals defintions, if any
example from AndyS in reply to comments from KendallC
<kendall> That would help, I think, make the design more clear.
ACTION: AndyS to rework CONSTRUCT def'n
ACTION: AndyS to add new construct examples, with solution modifier(s), to spec
souri: making sure folks are conciously not including COUNT(*)
<kendall> i could see the utility of COUNT, but i think we have to punt till 2.0 at this relatively late date
<kendall> Need something in the results format to serialize it, as well
<AndyS> Better design for ASK. Low cost for COUNT(*)
<DaveB> we'd be adding a new result format
<DaveB> that means new services, new xml formats
<SteveH> AndyS, COUNT can be considerably more expensive than ASK
<AndyS> Steve - ASK = SELECT EXIST in Souri's message
<SteveH> AndyS, yes
<DaveB> is EXIST a SQL keyword?
Souri: we could have the results of COUNT as a new return type ala ASK
Souri suggests a whole range of cardinality queries motivate this
<Yoshio> I share the need for COUNT, remember the need I mentioned of giving the user the chance to polish the query...
<ericP> AndyS: next step, GROUP BY, is expensive
<kendall> simple v. complex (arbitrary) aggregates, basically
<kendall> Souri suggests ASK is a kind of simple aggregate already
<ericP> Souri: COUNT covers EXISTS (ASK) but is slightly more expensive
<ericP> AndyS: are we ruling out or making later grouping functionality inconvenient
<kendall> Yeah, +1 to pat's question
<ericP> PatH: how?
<ericP> AndyS: probably an unfortunate syntax choice
<kendall> AndyS largely worried about syntax that might not be forward compatible
<kendall> COUNT * only for now; then add COUNT var ... GROUP BY ...
EricP wants to wait till we do aggregates generally.
<kendall> (I agreed with that till Souri argued that ASK is already a simple aggregate which COUNT * would also be...)
<kendall> Souri would be content w/ a deferral at this point
RESOLVED: to add a count/aggregate issue and postpone it, due to schedule considerations
Reviewing decision from last week:
PROPOSED: to publish rq23 (1.395) , addressing FILTER and 3 editorial changes, with KendallC & JosD reviewing these changes post 1.395, as a Last Call Working Draft
DanC trying to figure out what the LC vote meant ...how much editing is up to the editors
(1) optionals, andy/pat, (2) IRI non-normalization, ericp (3) ...
<DaveB> & pick a namespace name for xmlresults?
<DaveB> I pick http://www.w3.org/2005/06/sparqlResults
<kendall> Do the editor's intend the doc to [go to] LC w/ the red sections about consensus issues still in the doc?
TODO list for the spec:
strike "@@Ensure markup around examples enables XSLT extraction."
drop "@@Labeling when document is TOC-stable"
<scribe> done @@Matching is on a graph from a dataset.
"@@Prefix - sec 1.1 - See if there are any - consider rewriting if a just a few." -- strike.
RESOLVED: http://www.w3.org/2005/06/sparqlResults for results namespace name
ACTION: DanC to put a doc at the new results format namespace
RESOLVED: to publish SPARQL ql as last call, v1.406 + 9 changes, contingnent on review as follows
ADJOURN.