W3C RDF Core Working Group IRC Chat Logs for 2002-02-22

10:07:06 Users on #rdfcore: logger_4 @dajobe

10:07:56 <dajobe> dajobe has changed the topic to: RDF Core WG meeting, Cannes, France 25-26 Feb - http://www.w3.org/2001/sw/RDFCore/20020225-f2f/

10:08:44 Topic now RDF Core WG meeting, Cannes, France 25-26 Feb - http://www.w3.org/2001/sw/RDFCore/20020225-f2f/

10:08:44 Users on #rdfcore: logger_3 @dajobe

10:13:08 <dajobe> dajobe has changed the topic to: RDF Core WG meeting, Cannes, France 25-26 Feb - Agenda http://www.w3.org/2001/sw/RDFCore/20020225-f2f/

14:23:30 <AaronSw> hey, france already?

14:28:17 <dajobe> I'm ahead of myself

14:28:27 <dajobe> I turned logger on here permanently for the F2F period

14:29:49 <dajobe> dajobe has changed the topic to: RDF Core WG telecon 15:00-16:00 UTC Friday Agenda http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0604.html | RDF Core WG meeting, Cannes, France 25-26 Feb - Agenda http://www.w3.org/2001/sw/RDFCore/20020225-f2f/

14:31:33 <AaronSw> Which datatyping draft are we dealing with today?

14:31:40 <dajobe> no idea

14:31:54 <AaronSw> the link in the agenda is borked

14:31:55 <dajobe> I'd go for pat's last simple one

14:32:21 <AaronSw>http://www.coginst.uwf.edu/users/phayes/simpledatatype2.html

14:39:22 <dajobe> for my notes: jjc's xml base test 12 needs more explanation; test14 needs rewording (no req on rdf:ID anymore?)

14:39:34 <dajobe> off attachment to http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0516.html

14:40:17 <dajobe> lol at tim's cwm in machine code quip

14:40:26 <AaronSw> where?

14:40:41 <dajobe> rdf-ig message

14:41:06 <AaronSw> Heh.

14:41:37 <AaronSw> wow, norm gave up after 28 minutes

14:42:09 <dajobe> didn't jos/sean run some multi-day cwm stuff?

14:42:21 <AaronSw> i wouldn't be surprised

14:42:27 <AaronSw> dan usually leaves it overnight

14:42:41 <AaronSw> we need to introduce timbl to the profiler

14:51:06 * dajobe redefines DPH as Dynamic Perl/Python/... Hacker

14:52:04 <AaronSw> PowerBuilder, PHP

14:54:41 * dajobe -> laptop

14:56:07 * em sighs... still not able to get to http://www.coginst.uwf.edu/ more than 25% of the time...

14:56:11 * gk Apologies... I'll be a few minutes late joining the telecon

14:56:25 <bwm> G'day

14:56:35 <jjc> Hi there brian

14:56:51 <bwm> hey jeremy glad you could make it

14:57:22 <AaronSw> <Zakim> ok, AaronSw, I see SW_RDF Cor()10:00AM already started

14:57:36 <AaronSw> <Zakim> +EricM

14:57:37 <AaronSw> darn

14:57:47 <AaronSw> <Zakim> +AaronSw

14:59:15 <AaronSw> +Martin

14:59:16 <AaronSw> +SteveP

14:59:54 <AaronSw> <Zakim> +Manola

15:00:16 * dajobe-lap dials

15:00:18 <AaronSw> <Zakim> +??P4

15:00:25 <AaronSw> is that you, dajobe?

15:00:28 <dajobe-lap> dajobe-lap is now known as dajobe-jang

15:00:33 <dajobe-jang> no idea

15:00:39 <AaronSw> are you on?

15:01:04 * gk dialing

15:01:14 <bwm> having trouble dialing

15:01:39 <AaronSw> +ILRT (DaveB, JanG)

15:01:42 <AaronSw> +GrahamK

15:02:52 <AaronSw> +HP (Jeremy, Brian)

15:02:57 <AaronSw> +PatrickS

15:03:13 * DanC tries to decide which telcon to attend...

15:03:41 <bwm> this one

15:04:19 <gk> em - I just reloaded Pat's doc OK

15:04:30 <AaronSw> <Zakim> +??P9

15:04:30 <AaronSw> <Zakim> +Guest P10 7332 - is perhaps PatH?

15:04:42 <DanC> em, lemme know if you want me t join, OK?

15:04:56 <dajobe-jang> pathayes's most recent doc? http://www.coginst.uwf.edu/users/phayes/simpledatatype2.html

15:05:06 <em> ok DanC

15:05:23 <DanC> simpledatatyp2.html seems to fail the B4 test.

15:06:10 * em still can't load http://www.coginst.uwf.edu/users/phayes/simpledatatype2.html ... arrgg...

15:06:12 <jjc> reg DanB

15:06:25 <jjc> +Brian

15:06:26 <jjc> +Eric

15:06:31 <dajobe-jang> DanC: b4 test?

15:06:36 <jjc> +DaveB

15:06:40 <AaronSw> <Zakim> I see EricM, AaronSw, Martin, SteveP, Manola, ILRT, GrahamK, HP, PatrickS, ??P9, PatH, MDean

15:06:40 <AaronSw> <Zakim> ILRT has DaveB, JanG

15:06:40 <AaronSw> <Zakim> HP has Jeremey, Brian

15:06:57 <jjc> -FrankB

15:06:59 <jjc> +Jeremy

15:07:06 <jjc> reg DanC

15:07:09 <jjc> - RonD

15:07:13 <jjc> +Jos

15:07:16 <jjc> abs Rael

15:07:18 <jjc> +JanG

15:07:21 <jjc> +Maryn

15:07:26 <jjc> -Yoshi

15:07:28 <jjc> +gk

15:07:31 <jjc> -Michael

15:07:33 <jjc> -Kwon

15:07:36 <jjc> -Ora

15:07:40 <jjc> +frankM

15:07:45 <jjc> -Sataoshji

15:07:48 <jjc> +SteveP

15:07:51 <DanC> EricM, did you talk to AaronSw about redistributing stuff from Zakim? Aaron, do you have license to do that?

15:08:01 <jjc> -Pieree

15:08:04 <jjc> +PatrickS

15:08:08 <jjc> +Aaron

15:08:23 <AaronSw> thanks, jjc

15:08:32 <AaronSw> MDean?

15:08:52 <AaronSw> -MDean

15:08:54 <AaronSw> +PatH

15:09:12 <jjc> reg sergey

15:09:19 <AaronSw> DanC, i entered the info

15:09:21 <AaronSw> +MDean

15:09:41 <AaronSw> Next telecon is sorta at F2F, but really March

15:09:44 <AaronSw> review minutes

15:10:00 <AaronSw> ACTIONS are done

15:10:05 <AaronSw> Eric, telecon arrangements?

15:10:33 <AaronSw> Eric, arranging phone systems but don't have numbers

15:10:34 <AaronSw> will be distributed by email when i get them (sunday)

15:10:54 <AaronSw> 4PM French, 10AM Boston

15:11:09 <AaronSw> same time as our normal telecon

15:11:23 <AaronSw> Eric: bridge has been taken care of

15:11:29 <AaronSw> Monday and Tuesday

15:11:33 <dajobe-jang> 2 hours?

15:11:41 <AaronSw> bwm: we'll use as much as we need

15:11:51 <AaronSw> eric: I've booked a bridge at that time with Zakim

15:11:59 <AaronSw> ... I hope it'll be the same number (RDFCORE)

15:12:17 <AaronSw> bwm: mon and tues only

15:12:40 <AaronSw> ?? and Dave will go discuss charmod with i18n

15:12:45 <dajobe-jang> jeremy

15:12:52 <AaronSw> tx

15:13:12 <AaronSw> jer: It's xml:lang, unicode normalization, IRIs, and [something else]

15:13:17 <AaronSw> Martin would like to join as well.

15:13:44 <AaronSw> Jer: I'd like Graham to come

15:13:56 <AaronSw> Graham: Oh! No problem...

15:13:58 <dajobe-jang> something was character normalisation I think

15:14:12 <AaronSw> Ah, perhaps.

15:14:23 <AaronSw> bwm: can sort out details when we're there

15:14:42 <AaronSw> TEST CASES WD

15:14:50 <AaronSw> Jan: I've got CVS working... trawling thru minutes

15:14:55 <AaronSw> ... sorting things out, hacking away

15:15:08 <AaronSw> ACTION get jan cvs is CLOSED

15:15:18 <jjc> The [something else] above is empty

15:15:42 <AaronSw> Jan: these tests are trivial for machines, mostly for human consumption

15:15:56 <AaronSw> ... entailments not exhaustive

15:16:03 <AaronSw> ... is that alright?

15:16:11 <AaronSw> PatH: Yeah, seems alright. I should check them.

15:16:26 <AaronSw> Jan: canonical example is statements vs. statings

15:16:53 <AaronSw> the negative entailment isn't very strong

15:17:23 <AaronSw> 9: Preparing for the F2F

15:17:52 <AaronSw> Jer: I'd like to get a slot for the i18n

15:17:58 <gk> Non-entailment test: surely, a counter-example shows non-entailment? If the test case graphs are assumed to be complete, where's the prob?

15:17:59 <AaronSw> bwm: pick late on the first day or early on the 2nd

15:18:14 <AaronSw> 10: Model theory for containers

15:18:24 <AaronSw> Pat made proposal, DanC said Hmm.

15:18:35 <AaronSw> Pat: I think DanC agreed we could put this off.

15:18:45 <AaronSw> bwm: is this proposal clear?

15:18:46 <AaronSw> approved

15:18:56 <AaronSw> ACTION PatH to update the model theory to state a semantics for

15:18:57 <AaronSw> rdf:Bag and rdf:Alt which is the same as that for rdf:Seq.

15:19:04 <AaronSw> 11: Datatypes

15:19:11 <AaronSw> bwm: things have been moving on

15:19:12 <AaronSw> [laughs]

15:19:26 <AaronSw> bwm: want to leave stable and get wider comments

15:20:26 <AaronSw> [finding a uri for the MT draft]

15:20:36 <AaronSw> datatypes number 3...

15:21:33 <AaronSw> dajobe: I was looking at simpledatatypes2 and that was good

15:21:36 <AaronSw> "I like it."

15:21:44 <JosD>http://vam969.roam.agfa.be/rdfcore/DatatypeSummary3.htm

15:21:50 <AaronSw> bwm, http://www.coginst.uwf.edu/users/phayes/DatatypeSummary3.html?

15:22:02 <AaronSw> dajobe and I were looking at http://www.coginst.uwf.edu/users/phayes/simpledatatype2.html

15:22:17 <AaronSw> Patrick: Start with 1 and 2 and agree

15:22:20 <JosD> oops, this was my cache...

15:22:22 <dajobe-jang> nah, I was looking at simple DT #2

15:22:30 <pathayes> Brian is talking about www.coginst.uwf.edu/users/phayes/DatatypeSummary3.html

15:22:37 <AaronSw> Oh. Hm.

15:23:08 <em> DanC, do you have any feedback on http://www.coginst.uwf.edu/users/phayes/simpledatatype2.html ?

15:23:31 <DanC> yes; seems to fail the B4 test.

15:23:32 <AaronSw> Brian: we've had a proposal, and we've had input

15:23:37 <AaronSw> ... screws up process if it changes under our feet

15:24:10 <AaronSw> Frank: I understand what simpledatatypes2 is saying and I like it.

15:24:12 <dajobe-jang> +1 to frankm

15:24:12 <gk> Which proposal are we reviewing now?? DatatypeSummary3 or SimpleDatatype2 ??

15:24:19 <AaronSw> Can we translate that into answers on the questions?

15:24:30 <AaronSw> Brian: we'll discuss the issues instead

15:24:48 <DanC> i.e. simpledatatypes2 doesn't guarantee { [ :age "10"]. [:title "10"] } log:implies { :B4 a :Success }.

15:25:00 <AaronSw> --

15:25:02 <AaronSw> 1. The proposal should include support for the following idiom:

15:25:02 <AaronSw> <mary> <age> "10" .

15:25:02 <AaronSw> <age> <range> <integer> . # for some appropriate <integer>

15:25:04 <AaronSw> # for some appropriate <range>

15:25:04 <AaronSw> --

15:25:14 <AaronSw> Brian: heard strong support for this, anyone disagree?

15:25:26 <AaronSw> DanC, is B4 entailment or S-B?

15:25:48 <DanC> B4 is an entailment test (which S-B happens to support)

15:25:54 <AaronSw> Pat: can be ordinary range with untidy literals

15:26:08 <AaronSw> Patrick: no... can be tidy...

15:26:16 <dajobe-jang> jang has his hand up

15:26:33 * Zakim sees JanG on the speaker queue

15:26:50 <AaronSw> [some technical discussion on datatypes]

15:27:13 <DanC> to my mind, the proposal write-ups are getting too far from the use cases. I'd like to see PRISM, CC/PP, and dublin core examples in any datatypes proposal that I'd be really happy with. And some entailment tests.

15:27:23 <AaronSw> Frank: I want to value 10 and a schema declaration saying it's an integer

15:27:40 <AaronSw> Patrick: the app needs to know, the graph won't have the integer

15:28:05 <AaronSw> Pat: need to figure out the datatypes automatically

15:28:32 <AaronSw> Brian: deliberately ambigous about range or or drange

15:28:36 <AaronSw> (perhaps datatypes rage)

15:28:46 <gk> I agree that something like 1 is required

15:28:50 <AaronSw> Brian: Anyone disagree?

15:28:52 <AaronSw> no response

15:29:01 <AaronSw> --

15:29:02 <AaronSw> 2. That in case 1, the value of the age property is a 'string' which is

15:29:02 <AaronSw> constrained to conform to lexical space of a datatype indicated by

15:29:02 <AaronSw> <integer>, i.e. the node labelled "10" denotes the string "10".

15:29:03 <AaronSw> --

15:29:44 <AaronSw> Patrick: What the Model theory says it is an what an app uses it for is different

15:29:54 <AaronSw> PatH: no, strong disagree

15:30:04 <AaronSw> ... aligning MT with datatyping cleanly

15:30:11 <AaronSw> if we don't do that we could have finished long ago

15:30:22 <gk> I agree with PatH... trying to say what something means *to an application* is a rathole

15:31:51 <AaronSw> Pat: two 10s are not the same

15:31:58 <AaronSw> [brian and pat talking at once]

15:32:16 <AaronSw> Brian: tidy literals?

15:33:31 <gk> [Pat: there's no syntax to use the same node]

15:33:53 <AaronSw> pat: if there are two literals with the same node...

15:34:46 <AaronSw> WG: do you feel clearly enough to answer this question?

15:36:24 <AaronSw> Frank: if you say ... age 10 don't need to make 10 a thing and just do string comparison

15:36:31 <AaronSw> ... that's what everyone is doing now

15:37:06 <AaronSw> Sergey and Dan say their code will be broken.

15:38:02 <AaronSw> Brian: does 10 denote a string or an integer

15:38:21 <AaronSw> ... in the model theory

15:38:28 <AaronSw> Eric: String

15:38:30 <AaronSw> Jeremy: Integer

15:38:37 <AaronSw> DanC: String [in absentia]

15:38:43 <AaronSw> RonD: [absent]

15:38:48 <AaronSw> Jos: String

15:39:02 <AaronSw> JanG: String if you want tidy literals

15:39:04 <AaronSw> Martin: String

15:39:20 <AaronSw> Graham: can live with either, slight preference for Integer

15:39:28 <AaronSw> ^very slight

15:39:33 <AaronSw> DaveB: string

15:39:40 <AaronSw> Frank: integer

15:39:46 <AaronSw> SteveP: string

15:39:52 <AaronSw> PatS: String

15:39:57 <AaronSw> Aaron: String

15:40:05 <AaronSw> MikeD: String

15:40:18 <AaronSw> PatH: no opinion

15:40:23 <AaronSw> Sergey: String

15:41:04 <AaronSw> Brian-as-user-advocate: string

15:41:46 <AaronSw> Brian: consensus, the answer is string

15:41:51 <AaronSw> moving on...

15:41:57 <AaronSw> --

15:41:58 <AaronSw> 3. That the doublet be dropped from the proposal (the rdf:value idiom).

15:41:59 <AaronSw> --

15:42:21 <AaronSw> Any support?

15:42:40 <AaronSw> Dave: What's doublet mean?

15:42:52 <AaronSw> Pat: two triples joined by subject, one with value, one with datatype

15:43:07 <AaronSw> general agreement it should be DROPPED

15:43:32 <AaronSw> Pat: we're dropping only on grounds of implementation

15:43:47 <AaronSw> ... reducing number of choices offered to designers and developers

15:44:19 <AaronSw> GONE!

15:44:23 <AaronSw> DaveB: abstain

15:44:30 <AaronSw> PatrickS: stab! stab! stab!

15:44:39 <AaronSw> GONE!

15:44:47 <dajobe-jang> that is #3 in http://www.coginst.uwf.edu/users/phayes/DatatypeSummary3.html?

15:44:48 <AaronSw> 4. That the datatype triple idiom be dropped from the proposal.

15:45:49 <AaronSw> Brian: hearing support for keeping this idiom

15:46:03 <AaronSw> any dissent to leaving it in?

15:46:04 <dajobe-jang> is this #3 in http://www.coginst.uwf.edu/users/phayes/simpledatatype2.html ?

15:46:18 <dajobe-jang> dajobe seens confusion in discussion given no urls in doc

15:46:23 <AaronSw> any dissent to leaving it in?

15:46:27 <AaronSw> oops

15:46:34 <AaronSw> Graham: only way now that literals are strings

15:46:44 <AaronSw> dajobe, i believe so

15:46:57 <AaronSw> [vehement agreement]

15:47:58 <AaronSw> Pat: I'm not sure if 1 and 4 can co-exist in the model theory

15:48:46 <AaronSw> ... not sure how to do it in my MT, maybe we should go back to sergey's

15:49:18 <AaronSw> Pat: can do it with two triples

15:49:25 <AaronSw> Jeremey is unhappy as is [Jos?]

15:49:35 <AaronSw> Jeremy: strongest possible dissent

15:49:47 <JosD> I am happy!

15:49:52 <AaronSw> oops, sorry

15:49:52 <AaronSw> ... this puts us in the S-A and S-B situation

15:49:55 <AaronSw> - Jeremy

15:50:15 <AaronSw> It is unacceptable.

15:50:25 <AaronSw> ... but i'd be ok with just S-B

15:50:59 <AaronSw> Brian: Pat can you try to create a model theory?

15:51:03 <AaronSw> Pat: I can't

15:51:08 <AaronSw> Brian: but can Sergey's do it?

15:51:13 <AaronSw> Pat: I've forgotten the details...

15:51:36 <AaronSw> Brian: look at the implications and tell us what we can do

15:52:07 * DanC bemoans all the complexity

15:52:20 <AaronSw> [infighting about this...]

15:52:31 <AaronSw> 12: Issue rdfms-fragments

15:52:53 <dajobe-jang> aaron outlines his problems...

15:53:00 <dajobe-jang> with this, re rfc2396

15:53:33 <dajobe-jang> fragments only make sense with a "retrieval action"

15:53:49 <dajobe-jang> so rdf's use of uri#frag causes problems

15:53:58 <dajobe-jang> bwm: what problems?

15:54:04 <dajobe-jang> AaronSw: coneg on a fragment

15:54:35 <dajobe-jang> AaronSw: http and rest model says fragments represent document chunks, and talkin about them means talkin about the docs

15:54:47 <dajobe-jang> bu ttying to a resource (which can change) raises issues

15:54:58 <dajobe-jang> pathayes: not make sense ot me

15:55:01 <DanC> no, it says fragments represent document chunks no more than it says URIs denote entities.

15:55:04 <gk> [thinks... For datatyping, of the various requirements expressed, is there any sense that some are more important than others.]

15:55:14 <dajobe-jang> ... ok for rdf to use them itself

15:55:49 <dajobe-jang> AaronSw: as an xml standard, rdf might use xpoiner for e..g and get back a chunk of xml

15:55:59 <dajobe-jang> ... incompat with rdf

15:56:06 <dajobe-jang> (losing thread)

15:56:26 <dajobe-jang> phayes: if we use xpointer, and get back a bunch-a-stuff, could we get back to rdf ontology?

15:56:39 <dajobe-jang> AaronSw: parsing might return triples

15:57:32 <dajobe-jang> ... do we want rdf to be usabale with apache? [scribe losing aaron's point]

15:57:53 <dajobe-jang> jjc: agree not compat with uri 2396 but that is an arch problem

15:58:13 <dajobe-jang> ... and would expect/hope this would change in due course

15:58:30 <DanC> er.. we can't (knowingly) put arch problems in our specs.

15:58:38 <dajobe-jang> ... with a new version. rdf not compat. but not too much a problem

15:59:30 <dajobe-jang> AaronSw: roy fielding was designning http that way; they really didn't want it the other way [not catching this?]

15:59:49 <dajobe-jang> frankm: describing stuff buried in doc s...

16:00:00 <dajobe-jang> ... mehcanism we are using tied into impl

16:00:04 <dajobe-jang> ... i.e. retrieval

16:00:18 <dajobe-jang> jjc: agrees; path too

16:00:26 <dajobe-jang> pathayes: not a problem for us (rdf)

16:00:35 <dajobe-jang> jang: diff between denotation and retrieval

16:00:56 <dajobe-jang> ... so when have uri+frag - clear answers when retrieved, not what it denotes

16:01:00 <dajobe-jang> pathayes: +1

16:01:20 <dajobe-jang> bwm: CLOSES MEETING

16:01:22 <AaronSw> jang, the spec says "semantics of a fragment are defined by retrieval"

16:01:49 <AaronSw> Eric: same phone number, same bridge number, same time, just on Monday and Tuesday

16:02:02 <dajobe-jang> that is, an http uri plus frag id _denotes_ what you get when you retrieve it?

16:02:13 <AaronSw> According to the spec, yes

16:02:18 <AaronSw> at least that's my reading

16:02:30 <AaronSw> I encourage you to read it for yourself

16:02:40 <dajobe-jang> i did, I missed that

16:02:47 <dajobe-jang> I'll have another look

16:03:05 <AaronSw> --

16:03:06 <AaronSw> The semantics of a fragment identifier is a property of the data

16:03:06 <AaronSw> resulting from a retrieval action, regardless of the type of URI used

16:03:06 <AaronSw> in the reference.

16:03:07 <AaronSw> --

16:03:38 <dajobe-jang> how does that mesh with content negotiation?

16:04:32 <pathayes> who speaks?

16:04:37 <dajobe-jang> jeremy

16:04:39 <bwm> jeremy

16:04:48 <dajobe-jang> dajobe-jang is now known as jang-dajobe

16:04:53 <pathayes> jereemy:AAron, raise good points

16:05:08 <pathayes> Aaron:real issues here

16:05:24 <jang-dajobe> bwm: tag hasn't accepted the issues we gave them

16:05:55 <jang-dajobe> jjc: my xml:base writeup identified some of these problems, I think

16:06:10 <jang-dajobe> the xpointer eg is another good example of this problem

16:06:30 <jang-dajobe> bwm: so you're saying: the denotation in the xpointer spec is a lump of xml?

16:06:51 <jang-dajobe> bwm: I'm still thinking there's another layer of indirection here

16:07:39 <jang-dajobe> aaron thos goes -> media types -> xml -> xpointer

16:07:53 <jang-dajobe> ph: the issue is then, that because of the specs, our frag ids belong to xml?

16:07:59 <jang-dajobe> bwm: no, don't think sop

16:08:13 <jang-dajobe> bwm: the quote says "the semantics of"

16:08:23 <jang-dajobe> do you think they meant the same as we mean by "semantics"

16:08:30 <jang-dajobe> general groans about the irony here

16:08:51 <jang-dajobe> AaronSw: that's what I thought for a long while, that they were talking about web browsers

16:09:01 <jang-dajobe> but roy fielding's dissertation talks about the same stuff as us

16:09:10 <jang-dajobe> [aaron: can you post a pointer to that for completeness?]

16:09:25 <jang-dajobe> ph: sounds like a genuine difference of opinion between them and us

16:09:35 <jang-dajobe> AaronSw: yeah, but they wrote the spec :-/

16:10:54 <jang-dajobe> jjc: from a charter point of view, this isn't our job to fix, but we _can_ clarify that there's a problem

16:11:06 <gk1> People I've spoken to in IETF have said that consensus on RFC 2396 was hard to come by. I think that there is a body of resistance in IETF to the idea that URIs are not just protocol addresses.

16:11:26 <jang-dajobe> AaronSw: we should warn people not to make things worse by avoiding fragments in future work

16:11:32 <jang-dajobe> jjc: I think that's going too far,

16:11:38 <jang-dajobe> since frags are so ingrained in RDF

16:12:02 <jang-dajobe> AaronSw: I'd not go that far either, but warn about "there are current unresolved issues with these, avoid until they're sorted out"

16:12:10 <jang-dajobe> gk1: can't believe we're going to end up prohibiting frags

16:12:13 <jang-dajobe> ph: yeah

16:12:38 <jang-dajobe> gk1: the web-retrieval side goes off in one direction, the RDF goes off in another, and we're getting inconsistencies

16:12:47 <jang-dajobe> I'm trying to envisage where a problem might occur

16:12:57 <jang-dajobe> eg: an icon graphic with embedded emtadata

16:13:17 <jang-dajobe> then the icon might have a number of data formats (png, svg, etc)

16:13:35 <jang-dajobe> for the purpose of retrieval, the frag ID might have a number of different meanings depending on that type

16:13:52 <jang-dajobe> however, RDF wants icon#frag to have a single meaning regardless of data type of icon

16:14:28 <jang-dajobe> ph: why do we have to say that in RDF the meaning of #fragid is independent of the mimetype used for retrieval?

16:14:54 <jang-dajobe> in an operational sense it can utilise the media tpype of retrieved stuff to burrow inside to find the relevant stuff

16:15:07 <jang-dajobe> gk1: then you can't interpret icon#frag until you've done the retrieval

16:15:46 <jang-dajobe> ph: I can make _assertions_ about it without seeing what it is

16:16:12 <jang-dajobe> gk1: you're making assertions about possible worlds which aren't bound to web retrieval

16:16:26 <jang-dajobe> ph: right, but the only thing we need to worry about in rdf is coocurrance

16:16:40 <jang-dajobe> AaronSw: I don't think you can make that assumption

16:17:00 <jang-dajobe> ph: all we need is a mech for unambiguously determining identity of names

16:17:03 <jang-dajobe> not referents

16:17:38 <jang-dajobe> even if they were mime-type sensitive, two rdf processors could get the same document

16:17:44 <jang-dajobe> gk1: not quite true...

16:18:07 <jang-dajobe> gk1: because different documents can be given by retrieving the same uri

16:18:25 <jang-dajobe> gk1: eg, wap browser / web browser: the server can tailor the doc returned

16:18:43 <jang-dajobe> bwm: terminology: you get the same _document_ you just get different _representations_ of it

16:18:49 <jang-dajobe> ph: epiphany, need to think about it more

16:19:04 <jang-dajobe> bwm: ... and those representations may have different meanings for the same fragid

16:19:55 <jang-dajobe> frankm: one side of the world is using these fragids as part of an extended uri creation scheme, independent of retrieval actions that web-browsers might follow

16:20:12 <jang-dajobe> it's been convenient, suddenly we're not going to be able to do this any more

16:20:26 <jang-dajobe> AaronSw: eg, cwm loks up a schema by retrieving the URI

16:20:51 <jang-dajobe> bwm: rdf's view of resources: things identified by urirefs

16:21:12 <jang-dajobe> bwm: http: only a subset of those are retrievable, in that they're clubbed together to be the target of a retrieval operation

16:21:41 <jang-dajobe> if you have an http-centric view of the world, then you can't independently retrieve individual components

16:21:56 <jang-dajobe> bwm: http-centric isn't intended as a perjorative term :-)

16:22:12 <jang-dajobe> gk; this reminds me of the uri/url discussions of much earlier

16:22:25 <jang-dajobe> gk1: looking at what frankm said: uris are used in two ways...

16:22:34 <jang-dajobe> gk1: 1. give you a structure for naming

16:22:45 <jang-dajobe> or for naming authorities

16:22:52 <jang-dajobe> 2. going out and getting things

16:23:00 <jang-dajobe> ie, there is a naming and a retrieval use

16:23:43 <jang-dajobe> what we're coming up to was that the frag is part of the naming structure, but in the web, the frag is part of the addressing structure

16:24:20 <jang-dajobe> jang-dajobe: so we're talking about URNs, which make explicit the name/retrieval distinction?

16:24:31 <jang-dajobe> gk1: danc claims that you can use a URL just like a URN

16:24:44 <jang-dajobe> (ps excuse "gkl", ketbroad bounce)

16:25:13 <jang-dajobe> you can use any uri with an identifiable hierarchical structure and get an addressing scheme out of it

16:25:38 <jang-dajobe> ...so I don't think there's a hard-and fast distinction that you can hang this on

16:25:59 <jang-dajobe> jjc: I was surprised that you are allowed a fragid on the end of an opaque uri

16:26:12 <jang-dajobe> bwm: that's one to try on the w3c validator :-)

16:26:28 <jang-dajobe> gk1: mailto:blah@foo.com#xxx ?

16:26:34 <jang-dajobe> jjc: apparently legal

16:26:55 <jang-dajobe> jjc: I find I understand aaron's position better now

16:27:04 <jang-dajobe> he wants warning stickers on frag ids

16:27:24 <jang-dajobe> ph: I understand too, but I don't think we can manage by banning fragids

16:27:35 <jang-dajobe> we need something akin to frag ids anyway, for schema stuff, etc

16:28:07 <jang-dajobe> gk1: I've brought up the "rdf uris aren't web uris" before, and I thought I got agreement there

16:28:40 <jang-dajobe> the "design issues" have tried to put words around this, but I'm not finding them very convinced

16:28:54 <jang-dajobe> ph: is there an rdf-coloured equivalent of "#" that RDF can use?

16:29:07 <jang-dajobe> would that force it to be invalid URIS?

16:29:21 <jang-dajobe> jjc: that's for rdf2

16:29:47 <jang-dajobe> gk1: that won't fly in practice. there's too much legacy data, even if it's a good idea, which I'm not sure it is.

16:30:17 <jang-dajobe> ph: the discussion seems to be that rdf is going one way, and everyone else (webont) seems to be going another way

16:30:33 <jang-dajobe> rather, webont is dealing with this issue in the same way

16:31:04 <jang-dajobe> gk1: j. borden's made a proposal for standard syntax for frags that could be common across all schemes

16:31:24 <jang-dajobe> ph: he just joined webont, and he's got his solution to this which he's presented

16:31:50 <jang-dajobe> -> jjcbwm: we need to ask ron or eric, but rdf wants to be able to say things like http://foo#chapter1 ->author

16:31:55 <jang-dajobe> -> jjc

16:32:02 <jang-dajobe> ie, fragids aren't just for rdf's convenience

16:32:11 <jang-dajobe> frankm: I've been wondering aobut this for some time

16:32:51 <jang-dajobe> gk1: so two different docs with two different mimetypes with incompatble fragis syntaxes...

16:32:58 <jang-dajobe> is that the example you're looking for, aaron?

16:33:13 <jang-dajobe> AaronSw: yes, but in the audiobook you use timestamps to identify frags

16:33:28 <jang-dajobe> ph: but who needs to know this?

16:33:47 <jang-dajobe> if I've got an engine with a uriref and i retrieve that and get an audiobook

16:33:56 <jang-dajobe> i need a helper to get me the piece of that

16:34:30 <jang-dajobe> gk1: if you don't want to access the content but you want to, say, go to a syndication service and get _permission_ to republish chapter one?

16:34:46 <jang-dajobe> ph: if something can check the identity of names, then I don't _care_ what they retrieve

16:34:54 <jang-dajobe> unless I need to look inside what they retrieve for more names

16:35:25 <jang-dajobe> frankm: the trouble is that if a retrieval is implementation/mime -dependent, we need a mechanism to do that identity

16:35:33 <jang-dajobe> which is also mime-type dependent

16:35:52 <jang-dajobe> ph: you have one thing, a "chapter", which is _represented_ by different things

16:36:04 <jang-dajobe> AaronSw: who defines what names you can use?

16:36:09 <gk1> Time to remind folks of my proposal to the mailing list:

16:36:10 <gk1>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0559.html

16:36:41 <jang-dajobe> that's what the w3c is for, to set up those standards

16:37:17 <jang-dajobe> AaronSw: it seems like determining what is a valid uriref for a particular media type is different from just picking uris

16:37:24 <jang-dajobe> (correct me if I've misinterpreted that aaron)

16:38:24 <pathayes> test

16:38:28 <pathayes> test

16:38:38 <AaronSw>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0559.html

16:38:55 <jang-dajobe> can someone else take over the scribing? laptop keyboard is aggravating my rsi

16:40:06 <pathayes> ill try

16:40:15 <jang-dajobe> cheers pat :-)

16:40:33 <pathayes> gk:[missedit] Twist their arms..

16:40:47 <pathayes> Aaron: strong felings are on TAG

16:41:03 <pathayes> gk: to get standard, make proposal

16:41:13 <pathayes> Frank: where proposal goes?

16:41:27 <pathayes> gk: pwords of mine can be part of our response

16:41:47 <pathayes> brian: 2 things goiing on, write up TAG and our document.

16:42:25 <pathayes> gk:if were happy inside charter, do it; say to tag, take notice please.

16:42:35 <pathayes> gk: gets more leverage

16:43:14 <pathayes> brian: need to make something cohesive for tag

16:43:47 <pathayes> gk: 1st 2 pras of my message in line with what pat says, improve wording, but starting point...

16:43:59 <pathayes> brian...yes for our document.

16:44:48 <pathayes> frank:suspiciously like nonnormative appendix/tutorial...need to limit debate on normative wording

16:44:56 <pathayes> beina: right, so send to tag

16:45:04 <pathayes> that waas brian

16:45:15 <pathayes> frank:customer base??

16:45:56 <pathayes> gk: what they don't know wont hurt them.

16:46:11 <pathayes> all go...bye....

16:46:43 <jang-dajobe> heh, add "yours sinc." etc, hayes, and send that, will you? :-)

16:47:12 * jang-dajobe leaves for #rdfig

17:03:04 Topic now RDF Core WG telecon 15:00-16:00 UTC Friday Agenda http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0604.html | RDF Core WG meeting, Cannes, France 25-26 Feb - Agenda http://www.w3.org/2001/sw/RDFCore/20020225-f2f/

17:03:04 Users on #rdfcore: logger_3 mdean_ bwm @dajobe AaronSw em

17:04:23 <dajobe> dajobe has changed the topic to: RDF Core WG meeting, Cannes, France 25-26 Feb (telcon 16:00-18:00 UTC each day) - Agenda http://www.w3.org/2001/sw/RDFCore/20020225-f2f/