See also: IRC log
(Items 5-7 were on the agenda, but not reached during this meeting.)
The chair solicited comments on the agenda. Eric said that he would like to see some additional issues, and would mail to list.
<ericP> ACTION: ericP to send mail describing how http://www.w3.org/2001/sw/DataAccess/tests/#rdfsemantics-var-type-var and http://www.w3.org/2001/sw/DataAccess/tests/#rdfsemantics-bnode-type-var (posted in http://www.w3.org/mid/20060814121827.GC6336@w3.org) illustrate basic graph matching conflicts between LC1 and LC2 semantics [recorded in http://www.w3.org/2006/09/12-dawg-minutes.html#action01]
The chair proposed to accept the minutes of the Sep 5 meeting. Pat asked that they be amended to show that he had posted his regrets for not attending. The proposal to accept the previous minutes with the addition of Pat to the regrets list was seconded by Simon and RESOLVED.
It was PROPOSED and RESOLVED to meet again on Sep 20, with Elias as scribe.
Bijan, Pat and Simon all have ongoing ACTIONs to review Fred's constructive semantics. The general status is that they've read it but not written anything yet. The chair requested these reviews be sent via the list rather than being discussed in teleconference. All three actions CONTINUE.
Bijan and Kendall's ACTIONs to review Fred's comments from Aug 2 for inclusion into the issues list also CONTINUE.
Bijan's ACTION to see whether Pérez et al's paper offers any advice on filters was not discussed.
Kendall: This issue was opened Aug 30, Bijan's been carrying the ball on this. Andy has taken a position on this.
<AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0220.html was my somewhat rushed summary to help the telecon
Kendall: Is there any one else who would be willing to participate in this issue?
ericP: (1) Integrity of a literal in a graph, (2) integrity of literal constructed with ^^, (3) Integrity of literal constructed using....(sorry, couldn't follow last bit)
bijan: Is it about ill-formed literals, or non-literal value testing?
<EliasT> There are only 2 on Kendall's email.
<AndyS> rq24 says "Returns the datatype IRI of literal." What is the proposed text change?
ericP: datatype of a node for SPARQL's purposes doesn't take entailment into account, should just be what's syntactically after the ^^.
<bijan> Yeah, that's clear
<ericP> DATATYPE("-5"^^xsd:positiveInteger) = xsd:positiveInteger
<bijan> "abc"^xsd:integer< 1
<bijan> "abc"^xsd:integer = "abc"^xsd:integer
Bijan: Difficulty is in conflating the datatype, the datatype URI, etc.
<kendallclark> ACTION: BijanP to propose some editorial clarification text around DATATYPE [recorded in http://www.w3.org/2006/09/12-dawg-minutes.html#action02]
PatH: Should rename DATATYPE to DATATYPE_URI
<SteveH> IRI?
<ericP> datatypeThatHasNotBeenChecked
<EliasT> +1
<AndyS> datatypeIRI would be consistent.
<ericP> datatypeThatHasNotBeenCheckedtoMakePatHappy
<AndyS> but it does say "rdfs:Datatype datatype (typed literal ltrl)" so there is the signature as well.
<bijan> datatypeURI("-5"^^xsd:integer) = datatype("5"^^xsd:integer) ?
<patH> prepatteddatatype?
ericP: Inclined to be conservative and retain existing name; AndyS defers to eric.
<ericP> PlatonicDatatype?
<bijan> I'll proposed extra clarificatory text
<AndyS> datatype("") => xsd:string in the tests
<bijan> rdfs:Datatype datatype (typed literal ltrl)
<AndyS> datatype(""@en) => error
<bijan> rdfs:Datatype datatype (typed literal ltrl)
<bijan> Returns the datatype IRI of ltrl.
<ericP> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-typed-literal
<ericP> [[
<ericP> Typed literals have a lexical form and a datatype URI being an RDF URI reference.
<ericP> ]]
<AndyS> entailment rules: xsd 1a and xsd 1b
<EliasT> datatype(<uri>) => xsd:anyURI?
<AndyS> (at end of http://www.w3.org/TR/rdf-mt/#DtypeRules)
ericP: Without XSD-entailment, datatype("") is undefined, gives error.
AndyS: In one of our tests, datatype("") instead gives xsd:string.
<kendallclark> +1 to making this explicit
<EliasT> so URIs and bNodes are error as well?
<AndyS> Maybe ExprBuiltins/q-datatype-3.rq at least.
<kendallclark> i think so, yes, elias
<AndyS> I'm sure it's elsewhere as well: it's in the agenda later as well with a thread ptr
General consensus: datatype() should have a range of IRI rather than rdfs:Datatype
<AndyS> +1
<bijan> +1
<EliasT> datatype("") => xsd:string, datatype("abc"^^xsd:integer ) => xsd:integer, datatype(_:b0) => error, datatype(<anyURI>) => error, datatype("1"^^xsd:positiveInteger) => xsd:positiveInteger, datatype("foo"^^bar:type) => bar:type
<EliasT> ... I just wanted that for that record... in case we need a whole test suite on the decision.
<kendallclark> +1 Elias -- I'm willing to take yr comment as volunteering :>
<ericP> ACTION: ericP effect: DATATYE (RDF term) => IRI | "" => xsd:string, ""@foo => error, ""^^X => X, blank node => error, IRI => error [recorded in http://www.w3.org/2006/09/12-dawg-minutes.html#action03]
bijan: How should datatype values behave, when denoted using some other syntax other than a datatyped literal? (E.g., what if you give pi an IRI?)
<EliasT> i think it's important that there be some way to differentiate plain literals from literals typed as xsd:string in SPARQL
<bijan> isPlainLiteral
<bijan> isTypedLiteral
<bijan> isLiteralWithLang
<bijan> :)
<bijan> isPlainLiteral would be enough, actually
<bijan> Hmm
<bijan> Yes
<kendallclark> ACTION: EliasT to follow up w/ Andy on "the idiom" for plain literals/string literals [recorded in http://www.w3.org/2006/09/12-dawg-minutes.html#action04]
<AndyS> sameTerm("", ""^^xsd:string)
<SimonR> Do we get a problem if we're doing a multi-graph query, and the different graphs have different types describing the same node? What if one graph describes "IV"^x:roman, and the other "4"^^xsd:int?
<AndyS> So "sameTerm(?x, str(?x))"
<ericP> nice!
<LeeF> I'm happy with that, AndyS.
<bijan> It is obscure. Cool, but a tad obscure
<Zakim> ericP, you wanted to object to "we are supporting D-entailment"
<bijan> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#matchDEntail
<bijan> RDF defines D-Entailment where extra semantic conditions are allowed for datatypes. When matching RDF literals in graph patterns, the datatype lexical-to-value mapping may be reflected into the underlying RDF graph, leading to additional matches where it is known that two literals are the same value. RDF semantics does not require this of all RDF graphs.
ericP: Doesn't see where we're using D-entailment. Questions some of Bijan's reliance upon this assumption, which from a more conservative point of view may not hold.
<SteveH> my reading is hte same as eric's
Bijan: Worried if we use D-entailment in some places, but not all.
<kendallclark> we can split up readings on both sides and that even *more* proves the point that the text isn't sufficiently clear.
<kendallclark> hmm,i don't know how :)
<EliasT> DROP?
<AndyS> I'd like to strike the D-entailment text (section 4.8) because of this (as noted in email I think). We are open to other entailments than the core "simple" like D*.
<LeeF> ACTION -4
<kendallclark> in this as in most other things
<bijan> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#operandDataTypes
<EliasT> not for parenting... for sure.
<SimonR> Say, do with distinguish rdf:xmlLiteral-entailment from XSD-entailment...?
<AndyS> rdf:xmlLiteral is special - it is the RDF datatype (it says "the" in RDF concepts) :-)
<patH> so, simonR, yes.
ericP: D-entailment and the XPath functions in literal matching are similar, but only because they're both informed by XPath.
<AndyS> It is defined (value space etc - that's where I got the canonicalization stuff from) in concepts not covered by XSD-enatilment.
<SimonR> So, does simple entailment encompass xmlLiteral, or is it in addition to it?
<AndyS> (ARQ can match {:x :p 1 } on :x :p "1"^^xsd:byte but does not use that level for testing DAWG tests.)
<kendallclark> a point that has been made repeatedly, I believe
PatH: It's not clear that it's always possible to do D-entailment by extending the graph; this is a dangerous direction.
<kendallclark> that 'querying over the closure' is often impossible
<bijan> :x rdf:type xsd;positiveInteger.
<bijan> :y rdf:type xsd:negativeInteger.
<kendallclark> it makes the charter stuff about 'virtual graphs', well, *bad* IMO
<SimonR> Hmm. They seem to be meaningful; they just necessarily never have an extension....
<kendallclark> (hmm, s/often impossible/may be impossible in some cases/)
<AndyS> Ack to the modification.
PatH: It is justifiable to do selective D-entailment.
Bijan: D-entailment and non-literal value testing are orthogonal to one another.
<bijan> 1) Restrict value testing to data values with literal form
<bijan> (I think this is the implicit understanding)
<bijan> 2) Allow value testing to test non literal data values
<bijan> (Implementation wise, this would require preserving the type of URIs and BNodes in internal tables, at least; there's no syntax to pass that into result sets).
Kendall: Asking around the table about which position we favor.
AndyS: Support 1, caveats on exact wording.
EricP: Support 1, fears 2.
<kendallclark> "fear" -- clearly a technical term :)
Bijan: Support 2, don't mind 1.
<bijan> Ooo, 3rd position
<bijan> 3) duel operators with each sense
SimonR: Think neither really is viable, need to be able to support choosing one or the other. Abstain.
<ericP> i think we have done that by using specific XPath semantics
PatH: Agree with Andy, support 1.
EliasT: Support 1.
SteveH: Support 1.
Bijan: Followup question: If we were to support D-entailment, would that change your answer?
PatH: Yes, it would.
<ericP> is this a proposal to add a D-entailment?
Kendall: If choosing 1 is implicitly a choice against D-entailment, everyone should be aware of this.
bijan: Trouble with introducing D-entailment is that it introduces contradictions.
<kendallclark> PROPOSAL: "Restrict value testing to data values with literal form" -- or words to that effect
<AndyS> "Restrict to literals with explicit form"
<ericP> "Restrict value testing to ""^^ thingies"
<LeeF> +1 to that proposal
<kendallclark> ericp: see, colloquial is good :>
<kendallclark> PROPOSAL: To restrict value testing to literals.
<SimonR> And the syntactic forms reside in some single, specific graph at all times?
<ericP> +1
<bijan> "Other data values, such as :x rdf:type xsd:integer, are not blah blah"
<bijan> "URIs or BNodes, even if they denote data values, are errors" Maybe something like that?
RESOLUTION: Seconded by Eric, no abstentions.
<AndyS> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#matchDEntail
AndyS: Would like to strike reference to D-entailment in §4.8
Kendall: Inclined to open an issue on the support of D-entailment.
PatH: Why treat D-entailment specially?
EricP: Proposes to say in the section where datatypes are introduced, that we don't necessarily do D-entailment.
<AndyS> Is there a list of all the cases like ":x < :y" that have to be considered? booleans and cardinality, ... ???
<scribe> ACTION: bijan to write some text on the D-entailment issue [recorded in http://www.w3.org/2006/09/12-dawg-minutes.html#action05]
<AndyS> It would help me if it were quite soon (for publishing) - ideal world
<bijan> andys I'll try by tomorrow or thurs
<AndyS> Ta
PROPOSED to adjourn.