See also: IRC log
<LeeF> Scribe: EliasT
<SimonR> Andy, found a solid answer: dc:author never existed. Totally in my imagination. :) http://askdcmi.askvrd.org/default.aspx?id=17213&cat=1720
<LeeF> SimonR, are you calling in?
<LeeF> and iv_an_ru, will you be calling in?
<iv_an_ru> Start without me
<SimonR> Trying, Lee.
<SimonR> Feel free to kick off. I'll wrangle it eventually.
<LeeF> minutes from 13 February: http://www.w3.org/2007/02/13-dawg-minutes
AndyS: seconds minutes from Feb 13
<SimonR> I'll scribe next week.
<LeeF> meet next Mar 6, SimonR to scribe
<LeeF> ACTION: Elias to add wording for PROPOSED: ed(The SPARLQ Protocol does not derefrence query URIs so 5.1.3 does not apply. Per 5.1.4, services must define their own base URI, which may be the service invocation URI.) [DONE] [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action01]
<LeeF> ACTION: Lee to talk to protocol editors re: POSTing application/sparql-query [DONE] [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action02]
<LeeF> ACTION: AndyS to add text clarifying the prohibition on blank node labels in multiple BGPs to rq25 [CONTINUES] [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action03]
<LeeF> ACTION: EricP to run the yacker tool over and annotate the existing tests [CONTINUES] [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action04]
<LeeF> ACTION: LeeF to remember that the wee, lost filter tests should be put [CONTINUES] [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action05]
<LeeF> Eric's suggestion: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0111.html
<LeeF> Andy's response: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0118.html
<LeeF> original comment: http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2007Feb/0005.html
<AndyS> Original : http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2007Feb/0005.html
<LeeF> Andy's summary: http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0098.html
<SimonR> The only comment I have is that I vaguely thought that language codes were not case sensitive. The list traffic I read gave me the impression we weren't stripping case before doing comparisons.
<LeeF> Andy: The text currently says you can't use extended definition of < to do ORDERing, which I take as a bug
<LeeF> Andy: We can't define a total ordering
<LeeF> SimonR, language codes are case insensitive, according to RDF Concepts
<SimonR> LeeF, I'm surprised and newly enlightened!
AndyS: SPARQL doesn't support
language tags
... I think we should support language tags in the spec
SimonR: I think we should. If we don't, we'll get hell from i18n.
<SimonR> (That was Pat, not me.)
<patH> that was patH
<patH> we brits al sound alike.
<AndyS> @en-uk
LeeF: Unless there's a proposal that we revisit language tags support, we should discuss extensions and less-than only.
AndyS: We do date, but would like datetime.
<AndyS> Mute is 61# / unmute is 61#
AndyS: We do datetime, but would like date support.
LeeF: does anybody have any thoughts on making it explicit on the text that implementations of extensions that extend less than can affect the order of solutions?
PatH: No strong feeling. Pitty we can't follow some precedence.
Orri: We inherit the SQL ordering.
SimonR: We support LIMIT/OFFSET so we need to provide a stable ordering support.
<AndyS> "001"^^xsd:integer and "01"^^xsd:int
LeeF: Given AndyS and ericP's comments + the community feedback, convinces me that we need to allow for implementation to extend ordering in the less-than operator. Although this could result in less interoperability in our spec in regards to ordering.
ericP: The main risk we run is that a new implementation will affect somebody's expected slicing.
SimonR: In order to solve this problem for real, we need to have a separate protocol that holds on to the answers in order for you to obtain correct slices from it.
Orri_Erling: We can inherit a scrollable cursor from SQL.
<LeeF> PROPOSED: ORDER BY comparisons respect extended implementations of < that operate on types beyond what's given in the operator table
SimonR: Mulgara supports a holding-results set.
AndyS: Seconds it.
SimonR: Is < the only operator that gets extended in this way?
AndyS: We only use one operator to build the table.
patH: what is R.E.S.P.E.C.T?
<LeeF> PROPOSED: ORDER BY comparisons may use extended implementations of < that operate on types beyond what's given in the operator table
<LeeF> so RESOLVED.
<SimonR> Would extended versions of equality (particularly for datatype processing, affect DISTINCT?
<AndyS> DISTINCT is term distinct, not value distinct.
<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 [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action06]
<AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2007Feb/0014.html
<LeeF> test case: http://www.w3.org/2001/sw/DataAccess/tests/#modifer-limit
<LeeF> ericP: Fred is in favor of explicitly NOT having auto distinct
ericP: If people really wanted
that, we could add a keyword, but only until someone
proposes.
... I'm with Fred.
<LeeF> zkim, mute ericP
<LeeF> SimonR: Mulgara always does auto distinct
<LeeF> ACTION: LeeF to talk to SteveH and JeenB about auto distinct behavior in implementations [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action07]
<AndyS> I'm currently working through the reviews sent by KendallC, Bijan and SimonR.
<LeeF> Thanks all reviewers for their reviews sent so far and welcome any more reviews from the WG.
LeeF: Does anybody have anything invested in posting SPARQL queries?
AndyS: Joseki can POST a plain query. It doesn't have to be in the specification.
Orri_Erling: For our purposes it's ok as it is.
ericP: I don't care.
<LeeF> ACTION: LeeF or EliasT to reply to Bjoern regarding (not) POSTing application/sparql-query documents [recorded in http://www.w3.org/2007/02/27-dawg-minutes.html#action08]
ADJOURNED