IRC log of rdfcore on 2003-06-20
Timestamps are in UTC.
- 14:02:24 [RRSAgent]
- RRSAgent has joined #rdfcore
- 14:02:31 [Zakim]
- +DanC
- 14:02:49 [DanC]
- agenda?
- 14:03:51 [bwm]
- agenda: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0134.html
- 14:04:11 [DanC]
- agenda + 20Jun http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0134.html
- 14:04:25 [Zakim]
- +??P18
- 14:05:37 [DanC]
- DanC has changed the topic to: rdfcore jun 20 telecon. scribe: jjc
- 14:07:35 [jjcscribe]
- agendum 1: scribe is jjc
- 14:08:07 [jjcscribe]
- Zakim, who's on the phone?
- 14:08:07 [Zakim]
- On the phone I see jjc, FrankM, bwm, DanC, ILRT
- 14:08:08 [Zakim]
- ILRT has JanG, DanBri
- 14:08:09 [bwm]
- zakim, who is on the phone?
- 14:08:09 [Zakim]
- On the phone I see jjc, FrankM, bwm, DanC, ILRT
- 14:08:10 [Zakim]
- ILRT has JanG, DanBri
- 14:08:21 [DanC]
- agenda + warm-up calesthetics or do the wave or something
- 14:08:38 [bwm]
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0151.html
- 14:08:53 [jjcscribe]
- agendum item 2 roll call complete
- 14:09:06 [jjcscribe]
- agendum item 3 review agenda
- 14:09:23 [jjcscribe]
- the chair plans to tkae AOB before item 15
- 14:09:27 [Zakim]
- Not knowing who is chairing or who scribed recently, I propose DanC
- 14:09:30 [jjcscribe]
- 4 next meeting
- 14:09:33 [Zakim]
- Not knowing who is chairing or who scribed recently, I propose JanG
- 14:09:36 [jjcscribe]
- no scribe volunteer
- 14:09:39 [Zakim]
- Not knowing who is chairing or who scribed recently, I propose FrankM
- 14:10:05 [Zakim]
- +EMiller
- 14:10:33 [jjcscribe]
- DanC volunteers to scribe, EM will cover
- 14:10:48 [jjcscribe]
- agendum 5 minutes approved
- 14:10:51 [jjcscribe]
- agendum 6 minutes approved
- 14:11:20 [DanC]
- oops; neglected to check "update concepts to reflect disposition of danc-01"
- 14:11:22 [jjcscribe]
- agendum 7 complete actions recorded
- 14:11:27 [DanC]
- I guess I'll get a formal "are you ok?"
- 14:12:28 [jjcscribe]
- agendum 8 witrhdrawn actions
- 14:12:42 [DanC]
- (is there a test that shows synonyms for XMLLiteral? maybe it can't be done)
- 14:13:38 [jjcscribe]
- jjc: note that synonyms for XMLLiterals are allowed
- 14:13:46 [jjcscribe]
- http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0173.html
- 14:13:54 [jjcscribe]
- agendum 9 OWL test cases
- 14:14:00 [jjcscribe]
- see msg above,
- 14:14:07 [jjcscribe]
- ACTION Jan review OWL Test Cases
- 14:14:17 [DanC]
- jjc's msg to webont http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0173.html
- 14:14:18 [jjcscribe]
- ACTION jjc clairfy scope of review of OWL Test Cases
- 14:14:56 [jjcscribe]
- agendum 10 value space of XMLLiteral
- 14:16:49 [gk]
- gk has joined #rdfcore
- 14:17:06 [gk]
- gk has joined #rdfcore
- 14:17:16 [gk]
- Oops, sorry I'm late. Dialling soon.
- 14:17:27 [bwm]
- welcome graham
- 14:18:49 [Zakim]
- +GrahamKlyne
- 14:19:45 [jjcscribe]
- jumping to agenda item 13 I18N comment
- 14:19:55 [jjcscribe]
- (jjc has explained what exlcussive canoncial XML is)
- 14:21:04 [jjcscribe]
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0150.html
- 14:21:21 [bwm]
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0025.html
- 14:21:25 [jjcscribe]
- (above msg contains exclusive canoncial XML discussion)
- 14:21:28 [DanC]
- the agenda doesn't cite the most relevant msg from I18N, to me http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0023.html
- 14:21:37 [bwm]
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0132.html
- 14:23:59 [JosD]
- JosD has joined #rdfcore
- 14:24:32 [Zakim]
- +??P14
- 14:24:54 [JosD]
- Zakim. ??P14 is JosD
- 14:25:37 [gk]
- q+ to say that having to look inside the literal to look for markup is very painful to me
- 14:29:25 [em]
- is daveb here?
- 14:29:46 [jjcscribe]
- discussion of I18N msg
- 14:30:17 [jjcscribe]
- should treatmnet of parseType="Literal" be dependent on markup in side string
- 14:31:53 [jjcscribe]
- q+ to mention Cannes, and problems of not being able to distinguish
- 14:32:26 [jjcscribe]
- dan suggests folliowng I18N suggestion ..
- 14:32:33 [jjcscribe]
- ^dan^danc
- 14:33:18 [jjcscribe]
- bwm clarifies that dan is proposing a change to the parser
- 14:35:02 [jjcscribe]
- bwm asks can we reject this on the graounds of lateness?
- 14:35:21 [jjcscribe]
- danc maybe ...
- 14:36:20 [gk]
- Is an XML literal *really* a *byte* sequence, unlike a string??
- 14:36:24 [danbri_dna]
- q+ to have jang ask about something
- 14:37:06 [gk]
- q-
- 14:37:56 [jjcscribe]
- danc: the I18N requirement is clear
- 14:38:21 [bwm]
- q?
- 14:38:27 [gk]
- q+ to make two suggestions: (a) restrict parsetype=literal, (b) drop XMLLiteral
- 14:38:35 [jjcscribe]
- danc: we need to talk to them some more if we choose not to address the req
- 14:38:58 [bwm]
- ack danbri
- 14:38:58 [Zakim]
- danbri_dna, you wanted to have jang ask about something
- 14:39:43 [jjcscribe]
- jan asks why not use strings in value space?
- 14:39:56 [jjcscribe]
- jjc I think there was a reason but I can't remember it
- 14:40:11 [bwm]
- ack gk
- 14:40:11 [Zakim]
- gk, you wanted to make two suggestions: (a) restrict parsetype=literal, (b) drop XMLLiteral
- 14:40:15 [bwm]
- q?
- 14:40:19 [bwm]
- ack jjscribe
- 14:40:34 [jjcscribe]
- q+ to explain why strings are not good
- 14:42:14 [jjcscribe]
- gk (a) could we restrict =literal to case when there is markup
- 14:43:20 [jjcscribe]
- jang: difficulties in serialization
- 14:44:16 [bwm]
- ack jjc
- 14:44:16 [Zakim]
- jjcscribe, you wanted to mention Cannes, and problems of not being able to distinguish and to explain why strings are not good
- 14:45:17 [gk]
- I think I disagree wioth jjc's entailment
- 14:45:30 [DanC]
- I hope it's in the test suite
- 14:45:50 [gk]
- DanC, I think it certainly should be
- 14:46:50 [gk]
- *is* XML a tree structure, or does in *encode* a tree structure
- 14:47:29 [gk]
- DanC says it's important to distinguish between a string that looks like XML, and "real" XML
- 14:48:18 [gk]
- GK asks: is it also important to distinguish between a string that happens to contain digits, and a string that denotes a number?
- 14:48:20 [DanC]
- that's the motivation for parseType="Literal", no?
- 14:48:47 [gk]
- DanC, that's not what I understood Ralph was claimed to say
- 14:49:06 [DanC]
- well, it's my motivation for parseType="Literal"
- 14:49:14 [jjcscribe]
- jos: can we use the datatype
- 14:50:27 [jjcscribe]
- does distinguishing XML and non-XML conflict with not distinguishing text from text?
- 14:50:36 [jjcscribe]
- gk: yes. danc: no.
- 14:51:34 [gk]
- q+ to offer another design
- 14:51:50 [DanC]
- consider <prop parseType="Literal">foo</> vs <prop>foo<//>
- 14:51:57 [DanC]
- ^bwm's example
- 14:53:13 [DanC]
- jjc: consider <prop parseType="Literal">foo & bar </> vs <prop>foo & bar</>
- 14:54:05 [gk]
- q-
- 14:56:25 [jjcscribe]
- fm: parseTytpe="Literal" implicitly makes datatype = "XMLLiteral"
- 14:57:25 [gk]
- q+ to ask if parsetype=literal doesn't of itself constitute a different representation
- 14:59:02 [jjcscribe]
- q+ to ask about charmod
- 15:00:17 [DanC]
- jjc/fm: consider <prop parseType="Literal">100</> where upstream groks xsd:integer. [?]
- 15:01:55 [DanC]
- how does this motivate different abstract syntax from <prop>100</>
- 15:02:03 [DanC]
- ?
- 15:02:20 [jjcscribe]
- jjc: perhaps not very compelling
- 15:03:26 [gk]
- Jos suggests if you *really* want xmlliteral, then specify datatype XMLLiteral (?)
- 15:03:40 [bwm]
- jjc: consider <prop parseType="Literal">foo & bar </> vs <prop>foo & bar</>
- 15:04:01 [jjcscribe]
- danc: the I18N group has not convinced RDF Core
- 15:04:05 [jjcscribe]
- q+
- 15:04:56 [DanC]
- ... not convinces RDF Core to accept the requirement that <prop parseType="Literal">abc</> and <prop>abc</> have the same denotation
- 15:05:03 [DanC]
- convinced
- 15:08:32 [gk]
- i.e. <foo>abc</foo> and <foo rdf:parsetype="Literal">abc</foo> are different representations.
- 15:08:36 [DanC]
- I'm not comfortable with "representation" here.
- 15:08:42 [em]
- i'm here... unmuted to speak but will follow up via irc
- 15:09:03 [bwm]
- ack gk
- 15:09:03 [Zakim]
- gk, you wanted to ask if parsetype=literal doesn't of itself constitute a different representation
- 15:09:30 [jjcscribe]
- fm: are plain literals same as xsd:string?
- 15:09:36 [jjcscribe]
- some yeses, one agnostic
- 15:09:43 [em]
- i had this on an agenda with tim yesterday to help prep for this meeting (in case this happened)... unfortunatly didnt get to this due to other agenda items. I agree wrt getting a sense on management here - willig to do this
- 15:10:10 [em]
- q+ to confirm the previously raised issue about contradictory information
- 15:10:19 [bwm]
- ack jjc
- 15:10:19 [Zakim]
- jjcscribe, you wanted to ask about charmod and to
- 15:10:27 [bwm]
- ack em
- 15:10:27 [Zakim]
- em, you wanted to confirm the previously raised issue about contradictory information
- 15:10:31 [jjcscribe]
- jjc: should we ask about charmod req
- 15:10:40 [jjcscribe]
- that we are contravening
- 15:11:30 [DanC]
- "management" includes the SemWeb CG, btw.
- 15:11:33 [jjcscribe]
- em: is this information consistent with cannes?
- 15:11:40 [jjcscribe]
- jjc: no it is not.
- 15:12:22 [jjcscribe]
- ACTION em get W3c mgmt feedback on I18N issue
- 15:12:44 [jjcscribe]
- ACTION jjc Dig out cannes minutes
- 15:13:20 [jjcscribe]
- ACTION bwm give feedback to martin
- 15:14:27 [jjcscribe]
- withdraw action bwm
- 15:14:32 [jjcscribe]
- ACTION danc give feedback to martin
- 15:14:51 [jjcscribe]
- end of I18N comment issue
- 15:15:00 [jjcscribe]
- back to value space of XMLLiteral
- 15:15:09 [jjcscribe]
- I18N issue seems to be parsing one
- 15:16:59 [jjcscribe]
- jjc: discusses jang preference against octet sequences
- 15:17:23 [jjcscribe]
- danc: qu are two bits of MXL equal is hard
- 15:17:39 [jjcscribe]
- danc: webont want equality
- 15:18:57 [jjcscribe]
- janG: every wg does its own thing on this
- 15:19:12 [jjcscribe]
- jang: is XML equality technically hard, or procedurally hard
- 15:19:26 [jjcscribe]
- danc: it is not hard, rather too easy, lots of answers
- 15:20:37 [jjcscribe]
- jjc: we had the requitement to have equality, the specs of the consortium that had this were the c14n specs, so thats why we have this
- 15:22:17 [jjcscribe]
- jang: the current value sapce is distasteful, but its not up to us to do better
- 15:22:55 [jjcscribe]
- jjc proposes XML Literal value space
- 15:23:00 [gk]
- The value space
- 15:23:01 [gk]
- is the set of all exclusive Canonical XML (with comments, with empty
- 15:23:01 [gk]
- InclusiveNamespaces PrefixList ), which when embedded within an arbitrary XML
- 15:23:01 [gk]
- start and end element form a document conforming to XML Namespaces [XML-NS].
- 15:24:32 [gk]
- "... canonicalized start and end element tags ..."?
- 15:24:41 [gk]
- (That last my comment, not quite)
- 15:25:58 [DaveB]
- DaveB has joined #rdfcore
- 15:26:16 [gk]
- BWM: "The value space of XML literals is a set of exclusively canonicalized XML"
- 15:26:27 [jjcscribe]
- jjc: clarifiies that editorial polishing may still be relevant
- 15:26:47 [jjcscribe]
- jproposes gk lines
- 15:27:31 [jjcscribe]
- proposed jjc, seconded jos, no abstentions, no agaionst
- 15:27:33 [jjcscribe]
- resolved
- 15:28:05 [jjcscribe]
- datatypes moved to email
- 15:28:10 [DanC]
- actions arising from that decision? is there a commentor waiting? [I feel a bit lost; never mind if I am, indeed, lost]
- 15:28:18 [jjcscribe]
- language tag or language identifier
- 15:28:45 [jjcscribe]
- semantics uses tag, primer neither
- 15:29:00 [jjcscribe]
- agendum 12
- 15:29:12 [gk]
- DaveB, does syntax doc refer to labguage tag or identifier ??
- 15:29:20 [DaveB]
- I don't recall
- 15:29:26 [gk]
- ;-)
- 15:29:55 [gk]
- We think preferred term is "language tag" ...
- 15:30:11 [gk]
- ... for consistency acrosos docs. Do we care?
- 15:30:29 [jjcscribe]
- editor has heard 'tag'
- 15:30:42 [jjcscribe]
- schedule
- 15:30:50 [gk]
- (RFC3066 uses "tag", and that's kind of the horse's mouth here)
- 15:31:05 [DaveB]
- hmm, I find 'language identifier' once at least
- 15:31:25 [DanC]
- re 14Jul... is that proposals from editors, or reviewed text for publication?
- 15:32:06 [DanC]
- em, what form of "done" do you have in mind for 14Jul?
- 15:32:59 [DanC]
- what's clear to me is that if we don't have a request for PR by 4 Aug, REC by ISWC is at risk.
- 15:33:05 [jjcscribe]
- fm: primer aimed to be ready by 1 July
- 15:33:11 [jjcscribe]
- jjc: concepts is ready
- 15:33:20 [em]
- i think what i described last week.... all open issues resolved and docs at a level that they could be ready to publish for a 2nd last call (*not* suggesting this is required, but thought of this in terms of worse case schedule scenario)
- 15:33:20 [DaveB]
- syntax is, or will be ready
- 15:33:25 [jjcscribe]
- danbri: schema waiting on peter a bit
- 15:33:33 [DaveB]
- (small items, I remembered a couple todo)
- 15:33:51 [jjcscribe]
- semantics -
- 15:35:01 [jjcscribe]
- bwm: which of PatH's version do we want?
- 15:35:19 [jjcscribe]
- Gk: want entailement rules, but don't care about completeness claim
- 15:35:26 [jjcscribe]
- jos, fm: +2
- 15:35:51 [jjcscribe]
- danc: implementation experience?
- 15:36:11 [danbri_dna]
- bwm, brian do you want to be muted?
- 15:36:20 [gk]
- DanC, does implementation experience count for non-normative material?
- 15:36:26 [DanC]
- I'm trying to work from the "mother may we have PR status?" perspective.
- 15:37:05 [jjcscribe]
- bwm: I don't believe we need the completeness claim
- 15:39:38 [DanC]
- ack danc
- 15:39:38 [Zakim]
- DanC, you wanted to say I thought the rules were normative. I'm pretty sure lots of implementations are based on them. I think they actually do specify the interoperability of RDFS
- 15:39:41 [gk]
- In support of jeremy: the benefit would be that we draw implementer feedback if we're wrong, so can move more quickly towards being truly complete. That said, I still don't care
- 15:42:55 [jjcscribe]
- danc asks whether rules should be normative
- 15:43:13 [jjcscribe]
- lots of people use the rules
- 15:43:29 [jjcscribe]
- (connolly, jena, de roo .... lots of others)
- 15:43:49 [jjcscribe]
- Ones that aren't: OWL Lite - DL implementations
- 15:45:03 [gk]
- q+ to say I think this debate is not really important. To the extent that the closure rules are a logical consequence of normative semantics, they *are* normative.
- 15:45:08 [Zakim]
- +Pat_Hayes
- 15:46:23 [jjcscribe]
- Path speaks against normativity of closure rules
- 15:46:51 [jjcscribe]
- they are valid it is a fact
- 15:46:59 [jjcscribe]
- that they are complete is probably false
- 15:48:05 [gk]
- q+ to argue against DanC's "effective decision procedure"
- 15:48:09 [jjcscribe]
- q+ to ask pat about completeness
- 15:49:41 [jjcscribe]
- PatH is not prepared to prove that RDFS is logically complete
- 15:50:22 [bwm]
- ack gk
- 15:50:23 [Zakim]
- gk, you wanted to say I think this debate is not really important. To the extent that the closure rules are a logical consequence of normative semantics, they *are* normative. and
- 15:50:25 [Zakim]
- ... to argue against DanC's "effective decision procedure"
- 15:50:43 [em]
- q+ to balance picking our battles in the context of limited (and reducing) resources
- 15:51:19 [bwm]
- ack danc
- 15:51:19 [Zakim]
- DanC, you wanted to make the point about users expecations again
- 15:51:29 [bwm]
- ack jjc
- 15:51:29 [Zakim]
- jjcscribe, you wanted to ask pat about completeness
- 15:51:58 [bwm]
- ack em
- 15:51:58 [Zakim]
- em, you wanted to balance picking our battles in the context of limited (and reducing) resources
- 15:51:59 [DanC]
- I thought the relevant theorem was "F1 rdfs-entails F2 iff datalog-closure(F1, rdfs-rules) rdf-simple-entails F2"
- 15:52:37 [bwm]
- regrets from mike dean, patrick
- 15:53:44 [jjcscribe]
- q+ to propose keeping editors conjecture as a compromise between normativity and dropping the rules
- 15:55:43 [jjcscribe]
- danc: do we expect RDF RDFS reasoners to interoperate?
- 15:55:57 [bwm]
- ack jjc
- 15:55:57 [Zakim]
- jjcscribe, you wanted to propose keeping editors conjecture as a compromise between normativity and dropping the rules
- 15:55:59 [jjcscribe]
- gk, path, bwm: we do not define reasoners etc
- 15:58:08 [jjcscribe]
- jos was surprised to see rules move to an appendix
- 15:59:12 [jjcscribe]
- danc: when there is a bug where rules and model theory differ
- 15:59:22 [jjcscribe]
- danc: is this a bug in the rules or the mt?
- 15:59:33 [jjcscribe]
- path: in the rules by defn
- 16:00:34 [jjcscribe]
- gk: I don't want to be forced to use the rules for everything.
- 16:00:43 [jjcscribe]
- q+ to talk about datatypes
- 16:01:18 [jjcscribe]
- danc: suggests banana as an RDF implementation!
- 16:02:02 [DanC]
- this tells me that RDFS is too complicated. I thought it was 12 horn rules.
- 16:03:06 [jjcscribe]
- chair believes that it is late to raise normativity of rules
- 16:03:35 [em]
- q+
- 16:04:39 [danbri_dna]
- the wg is out of time. we have to finish. i'm happy moving rules to appendix if that's the only way to finish...
- 16:04:50 [bwm]
- ack jjc
- 16:04:50 [Zakim]
- jjcscribe, you wanted to talk about datatypes
- 16:05:10 [bwm]
- ack em
- 16:06:32 [jjcscribe]
- em speaks about how to get to PR
- 16:07:27 [jjcscribe]
- bwm proposes closure rules remains in semantics doc and claim of completeness remains
- 16:08:22 [jjcscribe]
- no formal decision
- 16:08:25 [DanC]
- bwm, WG decisions are expensive. beware of saying "the WG must decide ..."
- 16:08:38 [jjcscribe]
- pat offers to strengthen RDF case with a proof
- 16:08:52 [em]
- i'm really sorry folks... i'm late and have to run. will lurk on irc for remainder of meeting
- 16:08:58 [Zakim]
- -EMiller
- 16:09:19 [jjcscribe]
- Meeting closes.
- 16:09:22 [Zakim]
- -??P14
- 16:09:28 [Zakim]
- -FrankM
- 16:09:42 [Zakim]
- -GrahamKlyne
- 16:09:47 [Zakim]
- -bwm
- 16:14:18 [gk]
- DanC, to fly a kite, my story to the director would be that the entailment rules, though non-normative, to the extent that they are a logical cosequence of the normative semantics have normative force. Therefore there's no need for them to be normative.
- 16:31:59 [Zakim]
- -ILRT
- 16:55:23 [Zakim]
- -DanC
- 16:55:24 [Zakim]
- -jjc
- 16:55:34 [Zakim]
- -Pat_Hayes
- 16:55:35 [Zakim]
- SW_RDFCore()10:00AM has ended
- 19:01:47 [Zakim]
- Zakim has left #rdfcore
- 19:23:52 [DanC]
- DanC has left #rdfcore