W3C RDF Core Working Group IRC Chat Logs for 2003-04-04

13:00:01 Users on #rdfcore: @logger

14:52:14 * bwm waves to jadobe

14:52:24 * bwm goes to get some tea

14:53:42 <DaveB> good plan ;)

14:56:05 <danbri> danbri has changed the topic to: 2003-04-04 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0041.html

14:59:40 <bwm> zakim, who is on the phone?

14:59:40 <Zakim> sorry, bwm, I don't know what conference this is

14:59:41 <Zakim> On IRC I see em, Zakim, danbri, bwm, DaveB, logger

14:59:58 <bwm> zakim, this is rdfcore

14:59:58 <Zakim> ok, bwm

15:00:04 <bwm> zakim, who is on the phone

15:00:04 <Zakim> I don't understand 'who is on the phone', bwm

15:00:11 <bwm> zakim, who is on the phone?

15:00:11 <Zakim> On the phone I see ??P3, ??P13, FrankM

15:00:42 <bwm> zakim, mute ??P13

15:00:42 <Zakim> ??P13 should now be muted

15:00:57 <bwm> zakim, ??p13 is bwm

15:00:57 <Zakim> +bwm; got it

15:01:03 <bwm> zakim, unmute bwm

15:01:03 <Zakim> bwm should no longer be muted

15:01:09 <Zakim> +??P14

15:01:20 <Zakim> +PatH

15:01:22 <Zakim> +EMiller

15:01:28 <bwm> zakim, ??p14 is patS

15:01:28 <Zakim> +patS; got it

15:01:39 <bwm> zakim, ??p3 is steveP

15:01:39 <Zakim> +steveP; got it

15:01:55 <em> zakim, this is RDF

15:01:56 <Zakim> this was already SW_RDFCore()10:00AM

15:01:56 <Zakim> ok, em

15:01:59 <Zakim> +??P16

15:02:00 <em> zakim, who is here?

15:02:00 <Zakim> On the phone I see steveP, bwm, FrankM, patS, PatH, EMiller, ??P16

15:02:00 <Zakim> On IRC I see cmjg, em, Zakim, danbri, bwm, DaveB, logger

15:02:00 <bwm> Zakim, who is on the phone?

15:02:01 <Zakim> On the phone I see steveP, bwm, FrankM, patS, PatH, EMiller, ??P16

15:02:07 <cmjg> zakim, ??p16 is ilrt

15:02:07 <Zakim> +ilrt; got it

15:02:18 <cmjg> zakim, ilrt has DaveB JanG

15:02:18 <Zakim> +DaveB, JanG; got it

15:02:26 <cmjg> cmjg is now known as jang_scribe

15:03:09 <Zakim> +DanBri

15:03:15 <Zakim> +??P17

15:03:33 <jjc> Just joining ...

15:04:02 <danbri> Zakim, ??P17 is Jeremy

15:04:02 <Zakim> +Jeremy; got it

15:04:34 <DaveB> agenda http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0041.html

15:04:48 <jang_scribe> agenda http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0041.html

15:04:52 <jang_scribe> snap

15:04:58 <jang_scribe> roll call

15:05:03 <bwm> zakim, who is on the phone

15:05:03 <Zakim> I don't understand 'who is on the phone', bwm

15:05:06 <bwm> zakim, who is on the phone

15:05:06 <Zakim> I don't understand 'who is on the phone', bwm

15:05:09 <bwm> zakim, who is on the phone?

15:05:09 <Zakim> On the phone I see steveP, bwm, FrankM, patS, PatH, EMiller, ilrt, DanBri, Jeremy

15:05:11 <Zakim> ilrt has DaveB, JanG

15:05:25 <jang_scribe> regrets..?

15:05:34 <jang_scribe> bwm thinks none

15:05:39 <jang_scribe> daveb leaving 5pm BST

15:05:45 <jang_scribe> (quick agenda check)

15:05:53 <jang_scribe> comments... aob?

15:06:12 <jang_scribe> DaveB: reorder to suit me?

15:06:35 <jang_scribe> item 21, but it might run on

15:06:47 <jang_scribe> DaveB: in that case chas-01, item 16

15:06:57 <jang_scribe> timbl01 timbl 02 early too if poss

15:07:01 <jang_scribe> that's sufficient for now.

15:07:13 <jang_scribe> bwm: svg early, too?

15:07:16 <jang_scribe> DaveB: yeah

15:07:32 <Zakim> +Mike_Dean

15:07:52 <DaveB> (items 12, 16, 18, 19)

15:08:16 <jang_scribe> next telecon same time next week:

15:08:22 <jang_scribe> jjc to scribe

15:08:32 <jang_scribe> @carroll@ volunteers to scribe

15:08:40 <DaveB> hi gk, you dialling in?

15:08:43 <jang_scribe> minutes of last meeting?

15:08:44 <gk> Yes...

15:08:49 <DaveB> great

15:08:56 <jang_scribe>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0097.html

15:09:04 <jang_scribe> carried forward, give time to review

15:09:12 <Zakim> +GrahamKlyne

15:09:12 <jang_scribe> status of completed actions:

15:09:18 <jang_scribe> ok\

15:09:25 <jang_scribe> item 7

15:09:32 <jang_scribe> cc/pp

15:09:36 <DaveB> in msg http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0186.html

15:09:48 <jang_scribe> comments on this?

15:09:59 <jang_scribe> DaveB: I read them, seemed fine to me

15:10:10 <jang_scribe> are we going to discuss the suggestion on using typed literals?

15:10:26 <jang_scribe> DaveB: we've discussed this on the list, is patS ehre?

15:10:44 <jang_scribe> pats: if we don't make any reccommendation that's fine, we'd certainly be happy to advise cc/pp

15:11:04 <jang_scribe> I wouldn't oppose rdfcore saying used typed literals, but I'm not against saying nothing

15:11:51 <jang_scribe> bwm: at the time they took the decision to use "ordianry" rdf literals, since that's all there way

15:12:08 <jang_scribe> my interpretation is that they want to finish up this time around, then lok to adopting rdf typed literals next time

15:12:19 <jang_scribe> DaveB: happy as they are, but think they _should_ be using typed literals?

15:12:43 <jang_scribe> bwm: my own feeling is that I hope they will move to using datatypes in the future

15:13:27 <jang_scribe> miked: xsd:int = 32 bits, xsd:integer = integers

15:13:51 <jang_scribe> pats: art B said that cc/pp received a proposal to adopt DT lits, it was apparently very well received

15:14:05 <jang_scribe> so do we reiterate this?

15:14:25 <jang_scribe> pats: if there's strong consensus in the WG that they should adopt DT literals,

15:14:46 <jang_scribe> why not say, "we thibnk you should adopt these, but it's not critical if you can't do it this time around"

15:15:02 <jang_scribe> DaveB: sounds like bwm comments should be modified to that effect, if it can be put diplomatically

15:15:17 <jang_scribe> bwm: eg, we suggest that cc/pp consider the use of rdf datatypes, either now or

15:15:27 <jang_scribe> at some fuiture iteration of their docuemnts

15:15:33 * em might suggest leaving off the last part of your comment brian

15:15:53 <em> [/me might suggest leaving off the last part of your comment brian]

15:16:15 <jang_scribe> ie, remove ", either now or..."

15:16:17 <gk> q+ to query comment on ...

15:16:17 * Zakim sees gk on the speaker queue

15:16:23 <jang_scribe> bwm: anyone disagree with that?

15:16:34 <jang_scribe> jjc: that's flexible enough as it is, I think

15:16:47 <jang_scribe> no disagreement with that?

15:16:59 <jang_scribe> anyone oppose approving these comments with that mod?

15:17:04 <jang_scribe> gk takes up comment first...

15:17:12 <jang_scribe> comment on 4.1.4

15:17:27 <jang_scribe> saying rational 1/2 = decimal 0.5

15:17:42 <jang_scribe> saying @this may be potentially troublesome in the future@, why say that?

15:18:02 <jang_scribe> bwm: I've concern over the overlapping or otherwise of value spaces of XML dts

15:18:48 <jang_scribe> gk: in explanatory terms I find it hard to envisage a situation where 1/2 <> 0.5

15:19:24 <jang_scribe> gk: if this issue comes out of xsd, then xsd is saving up problems for everyone

15:19:32 <jang_scribe> jjc: we've commented to xsd in that regard

15:19:42 <jang_scribe> gk: fine, as long as it isn't tacitly lose

15:19:52 <jang_scribe> bwm: would you prefer that comment removed?

15:20:37 <jang_scribe> jang_scribe: polish maybe so that they know who to persue on the issue?

15:20:42 <jang_scribe> bwm: could do, is it vital?

15:20:52 <jang_scribe> (consensus that it isn't)

15:21:24 <jang_scribe> pats: value in a second group asking this question?

15:21:47 <jang_scribe> bwm: can we move on...

15:21:49 <jang_scribe> any other comments?

15:21:59 <jang_scribe> propose these approved with the addition above

15:22:06 <jang_scribe> pats: propose, second jang

15:22:11 <jang_scribe> against? no...

15:22:21 <jang_scribe> abstain? gk

15:22:27 <jang_scribe> done

15:22:41 <jang_scribe> skipping to item 12

15:22:43 <jang_scribe> RDF in SVG

15:23:02 <jang_scribe> see http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0020.html

15:23:22 <jang_scribe> comment along the lines that it's easier to embed rdf in svg than it is in html

15:23:41 <jang_scribe> bwm summarises efforts thus far to draft a 'how to embed rrdf in svg'

15:23:52 <jang_scribe> daveb happy to work on a short item for inclusion in syntax doc

15:24:00 <jang_scribe> (in collaboration)

15:24:16 <jang_scribe> pats: why not notes?

15:24:25 <jang_scribe> DaveB: we've had comments on this before, it ought to go in the spec

15:24:35 <jang_scribe> ACTION daveb: work on rdf in svg for inclusion in syntax doc

15:24:38 <jang_scribe> item 16

15:24:51 <jang_scribe> proposed disposition http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0026.html

15:25:25 <jang_scribe> any comments on daveb's response?

15:25:35 <jang_scribe> seconded, thirded by all and sundry

15:25:40 <jang_scribe> jjc seconds. daveb proposes

15:25:44 <jang_scribe> no against, no abstain

15:25:46 <jang_scribe> done

15:26:05 <jang_scribe> ACTION daveb to send response outlined in http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0026.html

15:26:27 <jang_scribe> moving to...

15:26:40 <jang_scribe> item 18, timbl-02

15:26:53 <jang_scribe>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0031.html

15:27:04 <jang_scribe> gk: gave a choice here

15:27:11 <jang_scribe> (this is ditching reification completely)

15:27:30 <jang_scribe> gk outlines three options

15:28:16 <bwm>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0031.html

15:28:45 <jang_scribe> the right message, the subject indicates timbl-01 but this is about -02

15:29:13 <jang_scribe> three options:

15:29:25 <jang_scribe> (a) reject comment, some actual use

15:29:33 <jang_scribe> (b) accept comment, remove reification

15:29:53 <jang_scribe> (c) 'fudge' - it's not removed but deprecated

15:30:10 <jang_scribe> bwm: straw poll, (a) (b) (c)?

15:31:02 <jang_scribe> path daveb jang jjc gk, like (a)

15:31:26 <jang_scribe> pats also

15:31:55 <jang_scribe> [this is just the reification vocab first]

15:32:11 <jang_scribe> support for (b) - ...

15:32:16 <jang_scribe> support for (c) danbri

15:32:32 <Zakim> -Jeremy

15:32:35 <em> q+ to argue

15:32:35 * Zakim sees gk, em on the speaker queue

15:32:44 <jang_scribe> danbri deprecate on the grounds of use/mention

15:32:49 <jjc> what's the passcode?

15:33:07 <Zakim> +??P11

15:33:15 <DaveB> jjc: 7332#

15:33:16 <jjc> Zakim, ??P11 is jjc

15:33:16 <Zakim> +jjc; got it

15:34:22 <jang_scribe> path: I'll take editorial action to emphasis this is not quotation in semantics

15:34:37 <jang_scribe> ACTION path: comment in semantics underlining that reification is not quotation

15:34:37 * gk switches preference from reject to deprecate

15:34:48 <jang_scribe> ACTION danbri comment in schema that reification is not quotation

15:35:43 <jang_scribe> frankm: it's useful to have standard vocab to refer to parts of a statement,

15:35:58 <jang_scribe> the fact that it doesn't do what people might expect needs outlining

15:36:04 <em> q?

15:36:04 * Zakim sees gk, em on the speaker queue

15:36:16 <jang_scribe> pats: deprecation is too strong: suggests it'll go away in the future

15:36:18 <em> ack gk

15:36:18 <Zakim> gk, you wanted to query comment on ...

15:36:19 * Zakim sees em on the speaker queue

15:36:20 <bwm> ack GK

15:36:20 * Zakim sees em on the speaker queue

15:36:25 <jang_scribe> gk: reads out proposal (a) from email

15:36:50 <jang_scribe> sorry, reads out (c) the deprecation proposal

15:36:52 <jang_scribe> jjc: too strong

15:36:56 <DaveB> +1

15:38:54 <bwm> q?

15:38:54 * Zakim sees em on the speaker queue

15:39:00 <jang_scribe> em: from a pedagogical point of view, reification is THE biggest stumbling block for communities to get their heads around rdf

15:39:00 <bwm> ack em

15:39:00 <Zakim> em, you wanted to argue

15:39:01 * Zakim sees no one on the speaker queue

15:39:02 <danbri> danbri: "prob w/ reification: you can't losslessly and harmlessly put one RDF graph 'inside' another using M+S reification vocabulary, because inferences associated with statements at the outer layer, will screw with your data"

15:39:32 <mdean> q+

15:39:32 * Zakim sees mdean on the speaker queue

15:39:57 <danbri> q+ to say reification has done nothing but harm

15:39:57 * Zakim sees mdean, danbri on the speaker queue

15:40:21 <jang_scribe> [danbri - do those problems stem from URIs not being _universal_ identifiers?]

15:40:49 <gk> q+ to say one thing I wanted to contemplate was relieving RDF applications of need to understand reification

15:40:49 * Zakim sees mdean, danbri, gk on the speaker queue

15:41:01 <danbri> [stem from interactions with owl:IndividualAs]

15:41:07 <jang_scribe> pats: I use reification, am _I_ deluded? :-)

15:41:26 <bwm> ack mdean

15:41:26 * Zakim sees danbri, gk on the speaker queue

15:41:34 <jang_scribe> miked: I don't particularly care about quoting, but statements about statements are important to me

15:41:38 <jang_scribe> we make very heavy use of that

15:41:56 <jang_scribe> we use reification machinery for that - if it went away it'd be a major loss

15:42:11 <jang_scribe> em: do you have pointers you can send me on this?

15:42:19 * DaveB thought we had agreement to keep this, with health warning...

15:42:21 <jang_scribe> miked: I'll paste pointers into IRC log.

15:42:44 <bwm> q?

15:42:44 * Zakim sees danbri, gk on the speaker queue

15:42:44 <DaveB> RolandS says he's using it a lot too

15:43:08 <jang_scribe> frankM: seconded, we also have an app that does the same thing

15:43:22 <danbri> ack danbri

15:43:22 <Zakim> danbri, you wanted to say reification has done nothing but harm

15:43:23 <bwm> ack danbri

15:43:23 * Zakim sees gk on the speaker queue

15:43:23 <jang_scribe> em: a strong argument for point(a) is a working rdfcore member application that uses reification

15:43:24 * Zakim sees gk on the speaker queue

15:43:39 <jjc> RDF Core member application: Jena has reification support.

15:43:51 <gk> If we keep reification, note in response that MDean, RolandS, PatrickS all say they use it.

15:43:58 <jang_scribe> danbri: I think this is damaging, confusing, unsettling

15:44:10 <jang_scribe> health warnings are ok, ripping out vocab will cause outrage\

15:44:23 <jang_scribe> second part is burden on parser implementors, but that's timbl-01

15:44:27 <jang_scribe> (bwm which we're coming to next)

15:44:35 <em> q?

15:44:35 * Zakim sees gk on the speaker queue

15:44:35 <bwm> q?

15:44:35 <jang_scribe> q?

15:44:36 * Zakim sees gk on the speaker queue

15:44:37 <gk> ack gk

15:44:37 * Zakim sees gk on the speaker queue

15:44:38 <Zakim> gk, you wanted to say one thing I wanted to contemplate was relieving RDF applications of need to understand reification

15:44:40 * Zakim sees no one on the speaker queue

15:44:45 <bwm> ack gk?

15:44:45 * Zakim sees no one on the speaker queue

15:44:58 <jang_scribe> gk: sounds like we're about to move onto that...

15:45:23 <jang_scribe> path: some time ago we made these parts of the semantrics doc non-normative, that's by itself caused quite a bit of discussion

15:45:38 <jang_scribe> but it means an app is able to ignore this if it decides.

15:45:53 <jang_scribe> bwm: ok, any further discussion?

15:46:04 <jang_scribe> then, patS proposes reject, jjc seconds.

15:46:10 <jang_scribe> anyone against? no

15:46:12 <jang_scribe> abstain?

15:46:13 <jang_scribe> no

15:46:22 <jang_scribe> ok, that's then settled

15:46:57 <jang_scribe> ACTION gk send response WRT timbl-02

15:47:31 <danbri> (danbri and pat actioned already; see above)

15:47:39 <jang_scribe> bwm suggests draft of comment to -core first

15:47:42 <jang_scribe> gk - absolutly(!)

15:47:44 <gk> I need to be clear that this is that we retain the *vocabulary*, with health warings in the docs. Parser support to be dealt wothj separately

15:47:54 <jang_scribe> bwm: item 19

15:47:56 <jang_scribe> timbl-01

15:48:16 <jang_scribe> see http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0031.html

15:48:17 * gk Is this just badId, or is this rdf:Id too?

15:48:27 <gk> s/badid/bagId/

15:48:35 <jang_scribe> DaveB: rolandS uses this a lot, he says it's useful

15:48:43 <jjc> bagID only

15:48:43 <jang_scribe> bwm: anyone want to argue in favour of removing it?

15:48:46 <jang_scribe> jjc, danbri says yes

15:49:05 <jang_scribe> danbri argues against bagID:

15:49:14 <jang_scribe> reification doesn't livce up to original promise

15:49:35 <jang_scribe> it's not widely used enough, I'm not convinced that it's doing what people think it's doing

15:49:45 <jang_scribe> I'm happy to leave it but make optional parser behaviour

15:49:47 <gk> q+ to ask: what about rdf:Id on property elements (that generate reification triples for single stmt, IIRC)

15:49:47 * Zakim sees gk on the speaker queue

15:49:51 <jang_scribe> jjc: if you want it optional, kill it

15:50:06 <DaveB> gk: that would kill reification in syntax pretty totally

15:50:22 <jang_scribe> jjc: bagId has a number of faults

15:50:25 <em> q+ to ask implementation experience from mike, frank, et.al.

15:50:25 * Zakim sees gk, em on the speaker queue

15:50:33 <jang_scribe> a minor fault is the ambiguous one, attribute ordering

15:50:43 <jang_scribe> it doesn't reify the kind of triples people want reifying

15:50:58 <jang_scribe> it only reifies top level triples, not everything

15:51:10 <jang_scribe> highly baroque, generates bazillion of triples from a single attribute

15:51:29 <jang_scribe> it's much more aesthetically displeasing than rdf:id which you know how much damage it's doing

15:51:50 <jang_scribe> bagid was related to aboutEach, when we killed the latter we should've killed the former

15:52:12 <jang_scribe> DaveB: people HAVE implemented it, according to current test suite - all that jjc says is true

15:52:25 <jang_scribe> jjc: only new information is that we've had external review and it's been negative

15:52:34 <jang_scribe> DaveB: I found one person after fishing around who's using it

15:52:37 <em> q?

15:52:37 <jang_scribe> anyone else use it?

15:52:37 * Zakim sees gk, em on the speaker queue

15:52:53 <jang_scribe> danbri: it didn't do what I'd hoped when I tried, so I stopped trying

15:53:01 <jang_scribe> bwm: anyone willing to argue for not removing it?

15:53:15 <jang_scribe> DaveB: ... not really

15:53:27 <jang_scribe> I've already said there's one user I can find of it

15:53:37 <jang_scribe> ack gk

15:53:37 <Zakim> gk, you wanted to ask: what about rdf:Id on property elements (that generate reification triples for single stmt, IIRC)

15:53:39 <bwm> ack gk?

15:53:39 * Zakim sees em on the speaker queue

15:53:40 * Zakim sees em on the speaker queue

15:54:11 <jang_scribe> gk: what about rdf:id too, that reifies single statemnts, why aren't we killing this too?

15:54:16 <jang_scribe> bwm: we've had no comment on it

15:54:25 <jang_scribe> DaveB: tim asked specifically about bagid

15:54:40 <jang_scribe> gk: I took that , rdf:id too, to be part of timbl-01

15:55:12 <jang_scribe> bwm: nobody's raised that issue too, that I'm aware of

15:55:27 <jang_scribe> gk: agreed, but what about this? It seems to be a part of the same issue

15:55:46 <jang_scribe> frankm: I've used rdf:id examples for the primer. It seems a different kettle of fish

15:55:51 <bwm> q?

15:55:51 * Zakim sees em on the speaker queue

15:56:06 <jang_scribe> gk: danbri, you commented that reification vocab was a point of confusion

15:56:18 <jang_scribe> I thought you meant by that parsers shouldn't have to do things with bagID plus others...

15:56:27 * jjc Support of chair cutting discussion on rdf:ID

15:56:33 <jang_scribe> bwm, there's no comment on rdf:id reifying

15:57:18 <jang_scribe> bwm: hoping at least to get a discussion on bagId soon

15:57:26 <bwm> ack em

15:57:26 <Zakim> em, you wanted to ask implementation experience from mike, frank, et.al.

15:57:27 <jang_scribe> bwm: eric..?

15:57:28 * Zakim sees no one on the speaker queue

15:57:45 <jang_scribe> em: ^^^ what dave said - Mike, you and frank both use reification vocab in apps

15:57:48 <danbri> I'm concerned we're dismantling reification syntax support attribute by attribute...

15:57:50 <jang_scribe> do you not use bagid?

15:57:56 <jang_scribe> miked: no, we just use rdf:id on statements

15:58:41 <jang_scribe> bwm: proposer to remove bagId?

15:58:44 <jang_scribe> p[ats: propose

15:58:46 <jang_scribe> danbri: seconded

15:58:48 <jang_scribe> against?

15:58:51 <jang_scribe> abstain?

15:59:04 <jang_scribe> path abstains.

15:59:31 <Zakim> -steveP

15:59:35 <jang_scribe> carried, one abstention

15:59:50 <jang_scribe> ACTION daveb: respond on timbl-01, bagId issue

15:59:54 <jang_scribe> ACTIOn daveb: remove from syntax

16:00:06 <jang_scribe> ACTION jang: hunt down bagId test cases and remove them

16:00:36 <jang_scribe> bwm: should let Roland know too...

16:00:45 <jang_scribe> DaveB: yeah, we kill all the bits he uses :-/

16:00:57 <jang_scribe> ACTION daveb: let RolandS know about this

16:01:10 * DaveB finds comment in his parser /* the bagID mess */

16:01:19 <jang_scribe> #if 0

16:01:30 <bwm> q?

16:01:30 * Zakim sees no one on the speaker queue

16:01:37 <jang_scribe> frankm: maybe an approach is...

16:01:47 <jang_scribe> ... deprecating internally the use of the term, reification\

16:02:01 <jang_scribe> what we're doing is describing statements, we're using this vocab to do that

16:02:08 <jang_scribe> path: I don't think there's a need to do that

16:02:30 <jang_scribe> 'reification' is a sufficiently technical term that people won't pick up an expected meaning for it

16:02:41 <jjc> s/reification/deification/g ?

16:02:46 <jang_scribe> em: there's a big CON to that: if you introduce unexpected or unknown terms,

16:03:11 <jang_scribe> there's a cost for every word you introduce that you have to explain

16:03:20 <jang_scribe> it's another step of confusion for potential uptakers

16:03:52 <jjc> Zakim, who's talking?

16:04:03 <Zakim> jjc, listening for 10 seconds I heard sound from the following: FrankM (36%), bwm (20%), PatH (77%)

16:04:08 <jang_scribe> path: not using a single name for it but still using what the name used to name is pedagogically the worst of all worlds

16:04:13 * gk Brian, that might have been a train outside, not close

16:04:39 <jang_scribe> frankm: I just suggested stop talking about it as reification, cast it as a vocab for describing statements

16:04:50 <jang_scribe> path: think that's even more (potentially) confusing

16:04:57 * DaveB really has to go...

16:05:40 <jang_scribe> frankm: unsays what he'd suggested

16:05:56 <jang_scribe> moving on:

16:06:02 <jang_scribe> item 11 pfps 4 5 6 7 10

16:06:06 <jang_scribe> review from jang in

16:06:12 <jang_scribe> gk's review in, quite a long review

16:06:30 <jang_scribe> gk review: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0033.html

16:06:41 <jang_scribe> item 13 horrocks-01

16:06:45 <jang_scribe> path: doing that after the call

16:06:50 <jang_scribe> Item 14, tex-01

16:07:02 <jang_scribe>http://www.w3.org/2001/sw/RDFCore/20030123-issues/#tex-01

16:07:54 <jang_scribe> jjc: given that tex seemed happy with us rejecting the comment but having a short implementation note

16:08:02 <jang_scribe> that seemed the path of least resistance

16:08:07 <jang_scribe> two ways to demo this

16:08:10 <jang_scribe> one is parser test

16:08:16 <jang_scribe> other is entailment test

16:08:30 <jang_scribe> parser test opens questions: what's the ntriples rep of a lang tag?

16:08:44 <jang_scribe> feedback was that parser test should be testing the parser, not the graph compare

16:08:54 <jang_scribe> the proposal jjc wants to consider is:

16:09:29 <jang_scribe>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0077.html

16:10:38 <jang_scribe> jjc explains note\

16:11:19 <jang_scribe> DaveB: I want my implementation to tolower() lang tags

16:11:26 <jang_scribe> case of lang tags has 0 semantic import

16:11:31 <jang_scribe> I want to ensure I can still do that

16:12:41 <gk> q+ to ask do we have a format for graph equiality tests, based on N-triples? I think not. Maybe that's what we need here?

16:12:41 * Zakim sees gk on the speaker queue

16:12:46 <jang_scribe> DaveB: given that the abstract syntax has effective no case comparison

16:12:59 <jang_scribe> why do we have more than one representation of the lang tag in ntriples?

16:13:12 <bwm> ack gj

16:13:13 * Zakim sees gk on the speaker queue

16:13:18 <bwm> ack gk

16:13:18 <Zakim> gk, you wanted to ask do we have a format for graph equiality tests, based on N-triples? I think not. Maybe that's what we need here?

16:13:20 * Zakim sees no one on the speaker queue

16:13:45 <jang_scribe> jjc: we don't if we're happy with the entailment tests

16:13:47 <jang_scribe> q+

16:13:47 * Zakim sees jang_scribe on the speaker queue

16:14:15 <jang_scribe> bwm: issue on whether we wait for i18n to endorse this.

16:14:37 * danbri -- em, bwm, I have to drop off the call, real life interferes... sorry!

16:14:49 * danbri (will read logs)

16:14:57 * danbri zakim, drop danbri

16:14:57 * Zakim DanBri is being disconnected

16:14:57 <Zakim> -DanBri

16:15:57 <jang_scribe> jang_scribe: ntriples SHOULD use lower case (daveb agrees) and entailment tests use rdf/xml

16:18:03 <jang_scribe> jjc: daveb would like ntriples to LC lang tags

16:18:22 <jang_scribe> I'd prefer lang tag to be a silent operation in ntriples

16:18:35 <jang_scribe> proposed test cases are in message 0077

16:18:42 <jang_scribe> but written in PSEUDOntriples

16:19:20 <jang_scribe> bwm: don't make these rdfs:comment specific, make it arbitrary

16:19:31 <jang_scribe> file1 and file2 should be differnet (acked, jjc)

16:19:36 <jang_scribe> then they entail each other.

16:19:50 <jang_scribe> bwm: just use file1 and file2 (file3!)

16:20:21 <jang_scribe> bwm: also

16:20:35 <jang_scribe> <a> prop "a"@en_us

16:20:46 <jang_scribe> <b> prop "a"@en_US

16:20:48 <jang_scribe> entails

16:20:54 <jang_scribe> <a> and <b> prop _:x

16:21:02 <jang_scribe> (but in rdf/xml)

16:21:05 <jang_scribe> proposed jjc

16:21:08 <jang_scribe> second jang

16:21:10 <jang_scribe> against?

16:21:13 <jang_scribe> abstain?

16:21:36 <jang_scribe> ok, decided.

16:21:39 <jang_scribe> tex-01 resolved,

16:21:50 <jang_scribe> action jjc produce test case for tex-01 and reply to tex

16:21:59 <jjc> Testcase: file1 and file3 from msg 77 in RDF/XML with eg:prop instead of rdfs:comment

16:22:05 <jang_scribe> Item 15: williams-02

16:22:45 <jang_scribe> jjc's proposal: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0154.html

16:23:40 <jang_scribe> bwm: anyone have a concern about removing NFC constraint?

16:23:57 <jang_scribe> jjc: propose to remove NFC constraint on URIrefs

16:23:58 <jjc> PROPOSE: remove NFC on RDF URI references

16:24:04 <jang_scribe> second: gk

16:24:23 <jang_scribe> s/NFC/NFC constraint

16:24:46 <jang_scribe> against? no

16:24:48 <jang_scribe> abstain? no

16:24:55 <jang_scribe> approved.

16:25:10 <jang_scribe> ACTION jjc review test cases for NFC constraint

16:25:35 <jang_scribe> jjc: the second part of this, is to modify the text in concepts to point to

16:25:48 <jang_scribe> the def of an IRI in XML namespaces 1.1, which is exactly the same

16:25:50 <jang_scribe> that's now CR

16:26:28 <jjc>http://www.w3.org/TR/xml-names11/

16:26:29 <jang_scribe> pointer to that definition...

16:26:43 <jjc>http://www.w3.org/TR/xml-names11/#IRIs

16:26:43 <jang_scribe> section 9

16:26:52 <bwm> q?

16:26:52 * Zakim sees jang_scribe on the speaker queue

16:26:59 <jang_scribe> q-

16:26:59 * Zakim sees no one on the speaker queue

16:27:17 <jang_scribe> also, to change the term to IRI throughout the document\

16:27:23 <jang_scribe> IRIref, that is

16:27:36 <jang_scribe> frankm: I don't agree with that [last part]

16:27:50 <jang_scribe> I'd rather have our definitions depend on XML namespace documents

16:28:03 <jang_scribe> we should depend on basic parts of XML architecture

16:28:12 <jang_scribe> we can comment that we use the same thing as IRIs

16:28:19 <jang_scribe> but this dependency concerns me

16:28:24 <gk> q+ to say I have a concern with this... names-11 says "We expect to issue an erratum replacing this...", and the IRI work to which it refers has raised some questions that I think will need some answers (e.g. spaces in IRIs?)

16:28:24 * Zakim sees gk on the speaker queue

16:29:11 <jang_scribe> we're talking about URI references, conceptually this muddies things I say [scribe transcribes worries improperly here]

16:29:17 <jang_scribe> also, pragmatically, there's a huge edit here

16:29:32 <bwm> ack gk

16:29:32 <Zakim> gk, you wanted to say I have a concern with this... names-11 says "We expect to issue an erratum replacing this...", and the IRI work to which it refers has raised some questions

16:29:35 <Zakim> ... that I think will need some answers (e.g. spaces in IRIs?)

16:29:36 * Zakim sees no one on the speaker queue

16:29:42 <jang_scribe> gk: my concern with this, ^^ what was in the queue

16:30:43 <jang_scribe> path: that was my concern too, this is too unbaked at this stage to rely on

16:31:10 <jang_scribe> jjc: the next section of the IRI doc says, users are expected to restrict themselves to URIs until IRIs are in common use

16:31:52 <jang_scribe> bwm: I'm hearing concerns here

16:31:58 <jang_scribe> jjc: I'm happy to back off this then

16:32:06 <jang_scribe> bwm: then can we resolve williams-02?

16:32:23 <jang_scribe> jjc: I'm happpy, don't have a proposal to reject this

16:33:05 <jang_scribe> jjc: basically propose: accept the change relaxing NFC, we accept the comment, the def of RDF URIref aligns with current IRI spec

16:33:28 <jang_scribe> but we're unwilling to change to use the term IRI until the term is sufficiently specified

16:34:17 <jang_scribe> there's also the confusion that RDF URIref might be interpreted to mean, uriref starting @rdf:@

16:35:07 <jang_scribe> bwm: don't think this is that big a deal

16:35:22 <jang_scribe> frankm: is it not the case that syntactically an RDF URIref is a URIref?

16:35:31 <jang_scribe> jjc: have to argue what rdf 2396 means

16:35:36 <jang_scribe> rfc 2396 even

16:35:53 <jang_scribe> gk: rfc 2396 allows a URIref to be a relative reference

16:36:07 <jang_scribe> frankm: but an RDF URIref is or is not a URIreference?

16:36:25 <jjc> q+

16:36:25 * Zakim sees jjc on the speaker queue

16:36:29 <jang_scribe> frankm: concepts already makes the caveat that RDF URIrefs are absolute

16:36:56 <jang_scribe> jjc: one difference is that &eacute; can appear

16:37:18 <jang_scribe> frankm: my point is: that I don't see there is a problem with continuing to use "uriref"

16:37:35 <jang_scribe> if there's a problem about MEANING not SYNTAX then the same complaint can be levelled at IRIref

16:37:50 <jang_scribe> jjc: I can come back with a different proposal?

16:38:46 <jang_scribe> frankm: I can go along with bwm';s suggestion

16:39:18 <jang_scribe> bwm: I prefer to leave it alone, anyone against that?

16:39:30 <jang_scribe> jjc: take it as a proposal then

16:40:25 <bwm> Propose: Continue to use term RDF URI Reference

16:40:33 <jang_scribe> gk seconds

16:40:36 <jang_scribe> against? nope

16:40:42 <jang_scribe> abstain? jjc

16:40:43 <jang_scribe> done

16:41:21 <jang_scribe> jjc: the note referring to IRI will have editorial polish; that'll go into the email to williams,

16:41:24 <jang_scribe> but that's just editorial

16:42:09 <jang_scribe> ACTION jjc email responding to williams-02

16:42:16 <jang_scribe> (figure out accept / reject offline)

16:42:18 <jang_scribe> moving on...

16:42:33 <jang_scribe> item 17: pfps-16

16:42:58 <jang_scribe>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0008.html

16:43:25 <gk>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0045.html

16:43:33 <gk> Is revised proposal

16:44:49 <jang_scribe> gk describes that proposal to telecon

16:46:24 <jang_scribe> jjc: very little about expressive power there

16:46:48 <jang_scribe> gk: the proposal is that if we use this text then we address the issue.\

16:47:00 <jang_scribe> bwm: anyone have any comments on this text?

16:47:49 <jang_scribe> jjc: there's quite a lot of change for what is one simple paragraph

16:48:01 <jang_scribe> I think deleting the paragraph is the obvious required change

16:48:10 <jang_scribe> why the extra text?

16:48:51 <jang_scribe> gk: we had a discussion at the time that we were NOT going into last call under the constraint

16:48:59 <jang_scribe> that changes would be purely minimalistic

16:49:14 <jang_scribe> bwm: jjc's comment is that these changes are not purely in response to pfps-16

16:51:32 <jang_scribe> bwm: sounds like there's more discussion on this before we can more it forward

16:51:42 <jang_scribe> item 20:

16:51:45 <jang_scribe> ..?

16:52:01 <jang_scribe> jsr-118-01

16:52:24 <jang_scribe>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0021.html

16:52:55 <gk>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0037.html

16:53:01 <gk> Brian's counter-proposal

16:55:12 <jang_scribe> path: this was the hardest agreement on this issue

16:55:20 <jang_scribe> jjc: we could add that comment, perhaps?

16:55:38 <jang_scribe> I don't see any harm in reiterating the dissent

16:55:57 <jang_scribe> bwm: so what do you propose gk?

16:57:24 <jang_scribe> [discussion on tone of response: reject with humility?]

16:57:43 <jang_scribe> jjc: I don't think there will be a future long-range typing solution in rdf

16:57:56 <jang_scribe> so it's disingenuous to say postpone

16:58:06 <gk> Proposed to reject JSR-118-01 comment for the reasons given in Brian's message http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0037.html

16:58:21 <jang_scribe> .

16:58:35 <jang_scribe> seconded? jjc

16:58:41 <jang_scribe> against? no

16:58:46 <jang_scribe> abstain? no

16:58:47 <jang_scribe> done.

16:59:22 <jang_scribe> ACTION gk to send response to jsr118-01 in rejection

16:59:38 <jang_scribe> bwm: got through quite a few, I feel much better about this

16:59:50 <jang_scribe> we've got to get the rest of them out of the way by the end of the month

16:59:59 <jang_scribe> at today's pace, that's completely doable.

17:00:10 <jang_scribe> gk: I've got a batch of proposals after the agenda

17:00:21 <jang_scribe> bwm: yes, would like discussion through the week

17:01:19 <jang_scribe> out of time, thanks folks

17:01:24 <jang_scribe> meeting ends

17:01:24 <Zakim> -bwm

17:01:25 <Zakim> -jjc

17:01:25 <Zakim> -patS

17:01:26 <Zakim> -EMiller

17:01:26 <Zakim> -FrankM

17:01:27 <Zakim> -PatH

17:01:29 <Zakim> -ilrt

17:01:34 <Zakim> -GrahamKlyne

17:01:43 <jang_scribe> logger, help

17:01:57 <Zakim> -Mike_Dean

17:01:58 <Zakim> SW_RDFCore()10:00AM has ended