See also: IRC log
<DanC> 27 Sep minutes
RESOLUTION: Approve http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/att-0532/27-dawg-minutes.html 27 Sep minutes
<DanC> 4 Oct minutes
RESOLUTION: Approve http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0017.html 4 Oct minutes
Next meeting: 2005-October-18
Next meeting scribe: ericP
<bijan> unmute me
<DanC> 3 actions continue
With no news, continue Bijan's actions
<scribe> ACTION: Bijan to take a pass through the editor's draft, listing what will change with the new semantics understanding, and what will not [CONTINUED] [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action01]
<scribe> ACTION: Bijan to estimate impact of "abstract syntax entailment" etc. on WG test harness [CONTINUED] [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action02]
<AndyS> To be changed: http://www.w3.org/2001/sw/DataAccess/tests/#sparql-query-example-testing-values-isuri
<ericP> Revision 1.445 2005/07/27 17:36:40 eric
<ericP> ~s/isURI/isIRI/ <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jul/0062">potentially addressing</a> Bjoern Hoehrmann's <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jul/0040">comments</a>
<ericP> i thought i had some encouragement in this direction. i will look...
PROPOSED: Approve 21 tests from http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0491.html except http://www.w3.org/2001/sw/DataAccess/tests/#sparql-query-example-testing-values-isuri
RESOLVED: ericP abstains
<DanC> Oedipus test case (OWL-DL semantics)
<ericP> note for isIRI/isURI: i did not handle this correctly so i expect some turbulence.
bijan: re: http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0498.html first query has one distinguished variable (?x) - ?y can vary from model to model = 1 result. second query, ?y is distinguished -- leads to no results
DanC: this doesn't fit into our test harness because it requires taking the OWL DL closure of the graph
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0052.html
<DanC> test schema issues
<DanC> ericp's action continues
<AndyS> This changes a lot of bytes - including "out there"
<scribe> ACTION: EricP to fix test schema to match manifest with negative tests [recorded in [12]09/27-dawg-minutes.html#action16] [CONTINUED] [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action03]
<DanC> ACTION: DanC to follow up re optional test based on op:dateTime triple [CONTINUES] [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action04]
<ericP> are there negative and positive syntax tests "out there"?
<AndyS> There is code that processes manifests.
<scribe> ACTION: DaveB to to propose source test to approve [CONTINUED] [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action05]
<ericP> AndyS, yes, i'm trying to have 0 impact on the standard manifest-processing code
<DanC> 2.1.1 Query Term Syntax under http://www.w3.org/2001/sw/DataAccess/rq23/#WritingSimpleQueries
<ericP> the prob is that the positivie syntax tests don't match the older schema
<DanC> A.1 IRI References in http://www.w3.org/2001/sw/DataAccess/rq23/#grammar
AndyS: Believes http://www.w3.org/2001/sw/DataAccess/rq23/#WritingSimpleQueries and http://www.w3.org/2001/sw/DataAccess/rq23/#grammar are now consistent with each other
<DanC> PROPOSED: that rq23 v1.501 addresses badIRIRef
<AndyS> Note this include http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0019.html
PROPOSED: that rq23 v1.501 addresses badIRIRef
RESOLVED
<DanC> Re: SPARQL: BASE IRI resolution 7 Sep
<ericP> 2.1.1 Query Term Syntax
<scribe> ACTION: ericP to send [OK?] message to Bjoern. re ( http://www.w3.org/mid/431e392a.225659671@smtp.bjoern.hoehrmann.de ) BASE IRI resolution comment [CONTINUED] [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action06]
<DanC> yes, http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0019.html is editorial. pls respond to the commentor along those lines, Andy
<DanC> ACTION: DanC to notify www-rdf-comments about difference between RDF URI refs and IRIs, e.g. spaces [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action07]
<scribe> DONE: AFS to propose resolution to punctuationSyntax, folding recent yakker grammar into editor's draft.
<DanC> REQUEST FOR TESTCASE: _ as 1st char of varname, a la http://www.w3.org/mid/20050802193708.4AE45CF@mail.informatik.tu-muenchen.de
PROPOSED: that the grammar in
1.501 addresses issue punctuationSyntax, noting relevant last
call comments: twinql Retrospective, Please make sure the
grammar is directly machine consumable. SPARQL: Backslashes in
string literals, SPARQL variable names syntax
... that the grammar in 1.501 addresses issue
punctuationSyntax
RESOLVED: patH abstains
<DanC> ACTION: AndyS to respond to grammar comments (x3) [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action08]
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/#OperatorMapping
<AndyS> A<B is compare to 1
<AndyS> should be -1
AndyS: A < B def'n in XPath Tests table in rq23 should use -1 rather than 1
<ericP> op:numeric-equal(fn:compare(A, B), -1)
(Table 11.1)
<ericP> A < B xsd:stringxsd:stringop:numeric-equal(fn:compare(A, B), -1)xsd:boolean
<DanC> 10.1.3 ORDER BY "The "<" operator (see the Operator Mapping Table) defines the relative order of pairs of numerics, xsd:dateTimes and xsd:strings"
<AndyS> A >= B says -11
ericP: The second A < B line should be A > B . Will take 20 seconds.
<ericP> 1.507
<EliasT> The -11 is still there.
ericP: rq23 1.508 fixes both typos in table 11.1 -- AndyS concurs
<DanC> PROPOSED: that rq23 1.508 address issues#sort, specifically order of IRI terms
<scribe> DONE: EricP to extend < and relational ops to string, get review by Andy ( http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0484.html ) w/ fixes in 1.508
http://www.w3.org/2001/sw/DataAccess/issues#sort
PROPOSED: that rq23 1.508 address issues#sort, specifically order of IRI terms
RESOLVED
<DanC> ACTION: Eric to respond to "ORDER with IRIs" comment [recorded in http://www.w3.org/2005/10/11-dawg-minutes.html#action09]
<ericP> http://www.w3.org/2001/sw/DataAccess/rq23/#func-langMatches
<ericP> 11.2.3.5½ sop:langMatches
<DanC> (would it be helpful if I edited the TOC to be 3 levels deep, using XSLT?)
<DanC> langMatches("en_US", "EN")
<AndyS> Typo: s/_/-/
ericP: langMatches is hierarchical - matching up to hyphen
DanC: is this ours or did we take from XQuery?
ericP: It's ours since we already have [ string lang(node) ] made sense to do [ string langMatches(string, string) ]
AndyS: text at end of 11.2.3.5 1/2 brings up fact that lang(?v) when ?v is a lang-less literal is an error - AndyS does not think this should be the case
<ericP> sorry
<AndyS> Example: lang("abc")
patH: is there such a thing as a null language tag?
AndyS: in XML, they use the emty string
DanC: this is not a language tag, it's semantics for the value of xml:lang
patH: Nervous about it being a *type* error as opposed to some other sort of error
<SteveH> type erroris bad for laneg(?x) != "en" where you want matechs on untyped literals
AndyS: we use empty string in Jena, hasn't caused problems
ericP: datatype( ... ) returns URIs from typed literals, I've changed text to make datatype( ... ) on a plain literal a type error
DanC: inclined for datatype( plain literal ) to be xsd:string -- would like plain literals and string-typed literals to be indistinguishable
<EliasT> /me has to go to class at 11AM
<EliasT> 11:30 sorry.
<AndyS> I vote for proposals where datatype("abc") is not an error ( or we need hasDatatype(literal) )
LeeF: Had a one-off need the other day to be able to detet difference between plain literal and xsd:string typed literals
<ericP> are you proposing something like sp:unLangedString?
<patH> could (?) make it be something that isnt a URI, to avoid possible confusion.
<patH> Then BTW, its easy to generate an error if you want one.
<AndyS> Result is currently an xsd:anyURI
<DanC> odd. datatype("http:/.."^^xsd:anyURI) == datatype("foo")??!
DanC: motivation is to be able to query mixed datasets painlessly
<ericP> eek!
<ericP> super eek!
<AndyS> The result is of type xsd:anyURI (which is quite lax)
<SteveH> AndyS, yes, but id like not to, its silly
<DanC> POLL: on return from datatype("abc"): (a) type error (b) either type error or xsd:string (c) sparql:plain (d) "" (e) always xsd:string
<AndyS> Our experience is that users expect roundtripping of RDF/XML (e.g. lexical forms, xsd:strings) big :-(
<ericP> AndyS, c and e
<ericP> LeeF, ... please enter
<ericP> ahh, tx
<DanC> c/e c/d c/e e c/e e e
(a)
(b)
(c) +1 +1 +1 +1
(d) +1
(e) +1 +.5 +1 +1 +1 +1
<DanC> support for hasDataType()?
<DanC> (this design discussion is based on so little experience that it's pretty much a coin-flip.)
<DanC> Zakim next item
<DanC> ADJOURN.