See also: IRC log
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0211.html
<kendallclark> ah, right, thx LeeF
<bijan> pointer to that email, eric?
ericP: Comments on the agenda: Would like to see some additional issues; will mail to list.
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/att-0204/05-dawg-minutes.html
<kendallclark> Plus: Add PatH to regrets list
PROPOSED: to approve minutes from Sep 5 teleconference, with addition of PatH to regrets
RESOLVED and seconded by SimonR
<EliasT> sure.
<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]
RESOLVED to meet again on Sep 20, with EliasT as scribe
<bijan> Simon, mute yourself. The typing is LOUD
bijan: ACTION to review FredZ's constructive semantics -- bijan has reviewed it but not written up.
kendall: Requests review of constructive semantics sent via the list.
PatH, also to continue semantics review.
kendall: Review also continues.
SimonR: Has read FredZ's, hasn't written up yet, continues.
<AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0199.html
Kendall: This issue was opened Aug 30, Bijan's been carrying the ball on this. Andy has taken a position on (as per above URL)
<AndyS> Not per that URL - that's the proposal from the agenda ... one moment ...
Kendall: Is there any one else who would be willing to participate in this issue?
<AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0220.html was my somewhat rushed summary to help the telecon
<bijan> WOOHOOOO!
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> (sorry, exogenous happiness making event)
<bijan> I couldn't follow the hat hat, etc.
<patH> bijan, glad life is so good for you.
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 ltrl." What is the proposed text change?
ericP: datatype of a node for SPARQL's purposes doesn't take entailment into account, should just be the 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 renamed 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
<EliasT> ?
<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)
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
<bijan> 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.
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.
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 belive
bijan: It's not clear that it's always possible to do D-entailment by extending the graph; this is a dangerous direction.
<bijan> That's Pat
<bijan> Not me
Oops. Sorry!
<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
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: It is orthogonal, D-entailment and non-literal value testing.
<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
<bijan> and BNodes in internal tables, at least; there's no syntax to pass
<bijan> that into result sets).
Kendall: Asking around the table about which position we favor.
AndyS: Support 1, caveats on exact wording.
EricP: Support 1, scared of 2.
Bijan: Support 2, don't mind 1.
<kendallclark> "fear" -- clearly a technical term :)
<bijan> Ooo, 3rd position
<bijan> 3) duel operators with each sense
SimonR: Thing 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 choose against D-entailment, everyone should be aware of this.
ericP: Trouble with introducing D-entailment is that it introduces contradictions.
(That was Eric, right?)
<EliasT> That was Bijan I think.
<bijan> It was me
Drat. I suck at this. :P
<kendallclark> PROPOSAL: "Restrict value testing to data values with literal form" -- or words to that effect
<patH> simon, you are better than me at it.
<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.
And the syntactic forms reside in some single, specific graph at all times?
<ericP> +!
<ericP> +1
<bijan> "Other data values, such as :x rdf:type xsd:integer, are not blah blah"
<bijan> H
<patH> what genus is Zakim?
<bijan> "URIs or BNodes, even if they denote data values, are errors"
<bijan> Maybe somethign liek 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 s4.8
<AndyS> Section 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.
<kendallclark> heh... +1 to distinguishing Perl scripts from civilization.
<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.
<kendallclark> eric: will you generate the minutes thingie for Simon?
<AndyS> EricP : help SimonR with the minutes??
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: SimonR Inferring Scribes: SimonR WARNING: No "Present: ... " found! Possibly Present: AndyS Bijan David EliasT Elias_Torres IPcaller Kendall Kendall_Clark LeeF P18 P20 P21 PROPOSAL PROPOSED PatH Plus SimonR SteveH eric ericp inserted kendallclark rdf rdfs You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: FredZ WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 12 Sep 2006 Guessing minutes URL: http://www.w3.org/2006/09/12-dawg-minutes.html People with action items: bijan bijanp eliast ericp WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]