W3C

DAWG Weekly Meeting

19 Sep 2006

See also: IRC log

Attendees

Present
PatH, EliasT, LeeF, AndyS, SimonR, kendallclark, bijan, ericP, FredZ
Regrets
none
Chair
kendallclark
Scribe
EliasT

Contents


<LeeF> thanks, Zakim

<scribe> Scribe: EliasT

convene

<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0236.html

<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0241.html

<AndyS> regrets for next time (26 Sept)

<SimonR> I might be unable to attend next week; I'll be at a conference.

<AndyS> I'll be talking about SPARQL to W3C in the UK :-)

<SimonR> Proposed to skip next week and have the next meeting on Oct 3rd, with AndyS as scribe.

RESOLVED to meet again on Oct 3rd, with AndyS as scribe

action items

<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0238.html

<LeeF> Elias's action was withdrawn immediately after issued last week

<kendallclark> A

http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0248.html

<SimonR> Minutes: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0241.html

<scribe> ACTION: ericP to send mail describing how [VTV] and [BTV] (posted [PST]) illustrate basic graph matching conflicts between LC1 and LC2 semantics [CONTINUES] [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action01]

<scribe> ACTION: BijanP to to propose some editorial clarification text around DATATYPE [CONTINUES] [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action02]

contradictoryKB

<scribe> ACTION: ericP effect: DATATYE (RDF term) => IRI | "" => xsd:string, ""@foo => error, ""^^X => X, blank node => error, IRI => error [DONE] [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action03]

<scribe> ACTION: EliasT to follow up w/ Andy on "the idiom" for plain literals/string literals [DONE] [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action04]

<scribe> ACTION: bijan to write some text on the D-entailment issue [CONTINUES] [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action05]

<scribe> DONE: ericP effect: DATATYE (RDF term) => IRI | "" => xsd:string, ""@foo => error, ""^^X => X, blank node => error, IRI => error [DONE]

<scribe> DONE: EliasT to follow up w/ Andy on "the idiom" for plain literals/string literals

<bijan> a p ">"^^rdf:XMLLiteral

<bijan> a p ">".

<bijan> p range rdf:XMLLiteral

<ericP> in SGML, and perhaps XML, '>' is allowed, so '<' may be a better choice

bijan: The only contradiction cases come with data types in RDF.

kendallclark: So if we don't use data types, we have no contradictions.

bijan: entailment are built-in to RDF.

<kendallclark> hmm, not what I said, but -shrug-

kendallclark: If we don't support RDFS then we don't have a contradictory KB issue.

<kendallclark> elias? I didn't say that either!

<kendallclark> :)

:-)

<kendallclark> :)

kendallclark: loves mochi

<kendallclark> heh

<kendallclark> Straw poll:

<kendallclark> 1. say nothing about contradictory KBs at all

<kendallclark> 2. say explicitly that how contradictory KBs are handled is outside the scope of this document

<kendallclark> 3. say explicitly what implementatons must do when querying contradictory KBs

<LeeF> FROM <A> FROM <B> A and B get RDF Merged

FredZ: what if two graphs are consistent independently but not merged in the case of FROM <A> FROM <B>

bijan: in RDF Semantics all ill-formed literals are mapped to another resource not of that type to avoid the contradiction.

FredZ: could we throw an error if we find an inconsistency?

SimonR: We would have to use a specific logic to resolve consistencies but that will not happen.

bijan: as I read the SPARQL document, it said that we support D-entailment then we need to say something about contradictions.

<AndyS> 4.8 has been removed.

<AndyS> I de-D-entailed rq24.

<bijan> :)

<patH> sorry im late.

<SimonR> How about: "say explicitly what implementatons MAY do when querying contradictory KBs"?

Present, but late: PatH

<kendallclark> audio bad :)

<ericP> bijan, the sound just got better

<patH> sorry, can anyone point out the 1/2/3 options? URI?

10kendallclark: 01Straw poll:

10kendallclark: 011. say nothing about contradictory KBs at all

10kendallclark: 012. say explicitly that how contradictory KBs are handled is outside the scope of this document

10kendallclark: 013. say explicitly what implementatons must do when querying contradictory KBs

<AndyS> 10kendallclark: 011. say nothing about contradictory KBs at all

<AndyS> 10[15:50] kendallclark: 012. say explicitly that how contradictory KBs are handled is outside the scope of this document

<AndyS> 10[15:51] kendallclark: 013. say explicitly what implementatons must do when querying contradictory KBs

<bijan> See that uri

<patH> That URI is forbidden

<ericP> patH, on it...

SimonR: 1 would lead to confusion, 3 is too hard right now, so 2 is the closest to what's acceptable.

<ericP> patH, fixed

<patH> Ta.

<kendallclark> AndyS: prefers (2) explicitly saying that it's app/imple-defined

<kendallclark> Elias: prefer (2)

<AndyS> against 3, OK with 1 and 2

<kendallclark> FredZ: (2) only reasonable choice

<SimonR> We'd almost want release the current document as specifying what happens in the case of simple entailment, and perhaps a later extension defining how we deal with stronger entailment regimes, including the issues of inconsistency which then arise.

bijan: I like 3, but 2 is good since it mentions at least.

ericP: I'm happy with 1 and 2.

<ericP> looks like 2s have it

patH: 1 dishonest, 3 ambitious and 2 is fine.

<bijan> I'll take an action to write up a 2

<bijan> Take a vote then

<AndyS> I'd like to write it into the pub version in section 5 (which can be wordsmithed later like anything else)

<bijan> sorry, someone at the door

<ericP> PROPOSED: @@someplace near semantic or implication@@ [[Logical entailment may result in inconsistent RDF graphs. Theresult of queries on an inconsistent graph is outside the scope of this document.]]

<AndyS> "result of queries on contradictory KBs are implementation-defined" Discuss contradictory. Mention possible outcomes as error, nothing, some results.

<bijan> Yep

<bijan> That's what I had in mind

<bijan> Bit about RDFS/D-Entailment

<AndyS> also not necessarily the same each time.

<bijan> Maybe a bit about how future specs might constrain this

<ericP> PROPOSED: [[Logical entailment may result in inconsistent RDF graphs. Theresult of queries on an inconsistent graph is outside the scope of this document.]]

<bijan> I like this because it gives the community a heads up on that it is an issue and implemetners and users some thoughts about what they might do

<SimonR> Do we provide any facility (error code, etc) for the implementation to signal the condition, should it choose?

<bijan> Can we wordsmith later?

<AndyS> Only error 500

<bijan> I don't like that

<AndyS> error => "outside the QL spec"

<AndyS> that's been what we've done before.

<LeeF> The only errors mentioned are in the protocol document (and in FILTER evaluations, but that's neither here nor there for this issue), AFAIK.

<bijan> That's 3

<ericP> PROPOSED: [[Logical entailment may result in inconsistent RDF graphs. For example, "-1"^^xsd:positiveInteger is inconsistent with respect to D-entailment [INFORMATIVE]. The result of queries on an inconsistent graph is outside the scope of this document.]]

<bijan> Can we say that it is an error?

<bijan> (not returns)

<bijan> Yep

<bijan> I yeild

<bijan> As long as we can bulk up the first sentences with some specific mention of RDF and RDFS and pointers to RDFS

<AndyS> What is Eric's example not covering?

bijan: what's the mechanism for returning errors?

ericP: we don't have any mechanisms in the QL for returning errors
... the mechanism is in the protocol.

<ericP> PROPOSED: [[Logical entailment may result in inconsistent RDF graphs. For example, "-1"^^xsd:positiveInteger is inconsistent with respect to D-entailment [INFORMATIVE]. The result of queries on an inconsistent graph is outside this specification.]]

<kendallclark> With the proviso that this ought not be intepreted as precluding the possibility of returning errors

<AndyS> "The outcome of a query on a incon..."

<patH> The effect of a query

<patH> ?

<LeeF> "it might even blow up THE SUN!"

<ericP> RESOLVED

<SimonR> The results of logical entailment may be outside this specification -- that seems to accurately reflect the situation.

<kendallclark> ACTION: KendallC to close contradictoryKB issue [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action06]

formsOfDistinct

<patH> I have problems with the phrase 'results of logical entailment', will fix in email.

<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0200.html

<kendallclark> http://www.w3.org/2001/sw/DataAccess/issues#formsOfDistinct

<patH> "logical entailment may'//"The use of richer/stronger/other entailment regimes may" (?)

<AndyS> Can we make sure we cover publishing process today? Just to make sure there are no blocks in the next 2 weeks.

<kendallclark> Andy: yes

<AndyS> Ta

<ericP> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#modDistinct

<AndyS> That is also the text in rq24 (I restored an HTML error as I noted). Not sure when it happened.

<bijan> First choice:

<bijan> First

<bijan> 1) one form of distinct

<bijan> 2) more than one

<bijan> Second if 1) which:

<bijan> A) term distinct

<bijan> b) answer distinct

<bijan> c) source distinct

<kendallclark> Which form(s) of distinct do you prefer:

<kendallclark> Path: prefer (a), no strong view, will go w/ flow

<kendallclark> Eric: (a)

<kendallclark> bijan: (a) and (b)

<kendallclark> Leef: (a) suffices, but sees appeal to (b) and (c)

<kendallclark> FredZ: ^(c)

<bijan> Ooo, nice point

<bijan> hadn't thought of that

<kendallclark> Elias: (a)

<patH> indeed.

<kendallclark> Andy: (a) only

<ericP> that's the danger of wearing the geek hat all the time

<kendallclark> Simon: no opinion

<bijan> (Some examples of B and C: http://www.cs.man.ac.uk/~bparsia/2006/row-tutorial/#slide35 )

<kendallclark> kendall: (a)

bijan: if we are going to do A, I'd like to have some text that explain it a bit more.

<ericP> +1

<patH> +2

<ericP> --

<ericP> =3

<patH> suggest it is worth spoending some informative time in spec to get this clear, as its one of the new topics that folk will be having new kinds of trouble with.

<ericP> yes

<bijan> Actually, as an artsy fartsy postmodernist, i resist hemogenistic attempst to "limit" the inscription of reality

<bijan> That's waht I would suggest

<patH> Ah, I knew I could smell derrida somewhere.

<AndyS> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#modDistinct is the current text. It uses set= : the = will tie to sameTerm for the RDF tem part of bindings in a set.

<SimonR> There's a certain parallel here to our earlier discussions about literals, compared by either syntactic form or by value.

<kendallclark> PROPOSAL: To close formsOfDistinct by defining distinctness in terms of term equality, and for BP to provide informative text to guide reader's expectations

<ericP> "01"^^xsd:integer "1"^^xsd:integer

<SimonR> (i.e. we're debated which sense of equality to use.)

<kendallclark> (for the record: our earlier decision re: contradictoryKB also closes that issue)

<AndyS> Ack to the closing thereof.

<kendallclark> PROPOSE: to extend meeting 10 minutes

<AndyS> Seconded

<kendallclark> thx

<bijan> For datatyped literals, a binding is equal either if

<bijan> 1) they are term-equal

<bijan> 2) they are = according to the datatype equality defined in value testing

<AndyS> { :x :p 1 }

<kendallclark> +3 to that symmetry

<kendallclark> if i grok it

<bijan> 3) they are - according to filter equality

<bijan> "filter equality"

<ericP> + a zillion

<bijan> 1) they are term-equal

<bijan> 2) they are equal by some other measure

<bijan> 3) both

<bijan> Term-distinct wrt bnodes

<AndyS> chnage it to "term/literal value (to be refined)"

<ericP> PROPOSED: to support some form of term-distinction

<kendallclark> PROPOSED: to support term distinctness w/r/t URIs and bnodes

<bijan> +1 to fred

<bijan> One of my objections to source distinct

<bijan> Conceptual

<bijan> No that wasn't the problem :0

<kendallclark> PROPOSED: to support term distinctness w/r/t URIs and bnodes, with literals to be decided

<ericP> RESOLVED

<bijan> Sorry

<bijan> I abstain

<bijan> tyes

<kendallclark> RESOLVED, with BP abstaining

<kendallclark> ACTION: KendallC to update formsOfDistinct issue to show progress [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action07]

<ericP> kendallclark, could you type "RRSAgent, please draft minutes\nRRSAgent, make logs world-access" after you adjourn? i have to run

<bijan> I am also supposed to "Quick skim" review

<patH> possibly? literals are not distinct if the datatype recognizes a normal form and they are the same when normalized (?) Weak but handles Fred-style cases.

<bijan> Hmm

<bijan> That seems to work, though I regret that I shall have to spelunk into XML Schema to find out what has normal forms

<patH> What else can be done, though? Its really seems to be up to the DT to make this decision.

<bijan> sure

<patH> Eg consider date formats.

<bijan> I would meet next week jus tto publish

<ericP> I have removed the DISTINCT issue from the document

<bijan> me!

<bijan> I'll need a day to review

<bijan> OR an hour

<bijan> or something :)

<patH> minute?

<AndyS> I'd like to be there if its a review.

<bijan> It's just supposed to be a sanity check, so I was going to send email message

<kendallclark> right

<FredZ> bye

<kendallclark> god, i hate a bot you have to say "please" to... that's absurd :)

Summary of Action Items

[NEW] ACTION: KendallC to close contradictoryKB issue [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action06]
[NEW] ACTION: KendallC to update formsOfDistinct issue to show progress [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action07]
 
[PENDING] ACTION: bijan to write some text on the D-entailment issue [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action05]
[PENDING] ACTION: BijanP to to propose some editorial clarification text around DATATYPE [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action02]
[PENDING] ACTION: ericP to send mail describing how [VTV] and [BTV] (posted [PST]) illustrate basic graph matching conflicts between LC1 and LC2 semantics [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action01]
 
[DONE] ACTION: EliasT to follow up w/ Andy on "the idiom" for plain literals/string literals [recorded in http://www.w3.org/2006/09/19-dawg-minutes.html#action04]
[DONE] 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/19-dawg-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/08/16 15:12:03 $