Semantic Web Interest Group IRC Chat Logs for 2001-05-08

00:13:06 <wmf> wmf is now known as primus_illuminatus_wmf

00:56:01 <primus_illuminatus_wmf> hey bijan

00:56:13 <bijan> Wow, wes, that's quit a nick.

00:56:19 <bijan> I didn't know they came in that size.

00:56:54 <primus_illuminatus_wmf> the power of openprojects

00:58:07 <spetschu> hi folks

01:00:08 <primus_illuminatus_wmf> primus_illuminatus_wmf is now known as wmf

01:55:20 <AaronSw> re the discussion the other day about distributed storage systems for rdf:

01:55:28 <AaronSw> it seems that Uprizer might fill the bill

01:55:48 <AaronSw> in http://openp2p.com/pub/a/p2p/2001/05/05/uprizer.html Ian Clarke describes it as Freenet - anonymity

01:56:12 <AaronSw> err freenet minus anonymity, which should make it much faster

01:56:26 <wmf> indeed

01:57:00 <AaronSw> wmf, do you know about a timeframe for uprizer?

01:57:09 <wmf> no

01:57:28 <AaronSw> anonymity is "like building a system with one hand tied behind your back."

01:57:33 <wmf> it seems like mojo nation and opencola have a head start

01:58:20 <bijan> Heh. If you reverse that it's pretty funny.

01:58:42 <bijan> "Tying one hand behind your back is like not giving your name or other identifying information."

01:59:33 * AaronSw looks puzzled

01:59:45 <wmf> it's just bijan, ignore him

01:59:54 <AaronSw> ok ;-)

02:00:00 <AaronSw> is opencola anonymous?

02:00:06 <wmf> no

02:01:30 <wmf> freenet is pretty much the only anonymous system

02:01:59 <AaronSw> so why is mojonation so slow?

02:02:18 <wmf> because it's so smart?

02:02:22 <wmf> I don't really know

02:02:31 <wmf> it's faster than Napster and Freenet, though

02:03:01 <AaronSw> faster than napster?

02:03:15 <wmf> theoretically, swarming should be really fast, and sometimes it is, but sometimes it's really slow

02:04:24 <wmf> sure, most of my Napster downloads are about 500 bytes/sec

02:10:55 <wmf> anyway, I don't know if these new P2P "content distribution" systems are going to be all that useful for storing personal data, since they seem designed for unidirectional data transfer

02:11:36 <wmf> e.g. you can download files really fast from the owner of a "super-node", but you can't publish or serve any of your own data

02:12:49 <wmf> but then I might be wrong; opencola and uprizer are pretty secretive

02:15:48 <wmf> gotta get some groceries, back later

03:42:06 <wmf> hey tav

03:42:10 <tav> eeeeeeeek

03:42:23 <tav> i swear you follow me everywhere!

03:42:33 <AaronSw> tav, do we know you?

03:42:35 <AaronSw> ;-)

03:42:36 <wmf> no, you follow ME everywhere :-)

03:43:00 <tav> AaronSw: not a regular, GabeW introduced me to this place a few weeks back ;p

03:43:14 <wmf> tav is an espra/freenet guy

03:43:23 <AaronSw> cool -- welcome

03:44:02 <tav> hi ;p

03:45:35 <tav> wmf, recall my rant on xt_objects some time back?

03:45:48 <wmf> yeah, a little

03:48:43 <tav> well, it ties in heavily with the semantic web

03:49:24 <wmf> yep

03:50:09 <tav> lol!

03:50:10 <tav> http://rdfig.xmlhack.com/index.html

03:50:11 <dc_rdfig> A: http://rdfig.xmlhack.com/index.html from tav

03:50:29 <tav> WWW10: Push or pull? How about both?

03:51:33 <tav> lol

03:51:45 <tav> well, not quite xt_objects, but close enough

03:51:54 <AaronSw> A:|Main Page

03:51:55 <dc_rdfig> titled item A

03:51:58 <AaronSw> A:*recursive*

03:51:58 <dc_rdfig> commented item A

03:52:09 <AaronSw> A:( I think this was an accident)

03:52:09 <dc_rdfig> commented item A

03:52:26 <AaronSw> tav, be careful about posting uris -- they get picked up by the chump automatically

03:53:30 <tav> A:|Main Page

03:53:31 <dc_rdfig> titled item A

03:53:41 <tav> ehm

03:53:46 <tav> what does it do?

03:53:54 <AaronSw> it changes the rdfig.xmlhack..com site

03:54:22 <AaronSw> take a look

03:54:56 <wmf> wow, the logs are real-time

03:55:11 <AaronSw> of course -- what else?

03:55:17 <AaronSw> I'm logging. I don't understand 'hi', AaronSw. Try /msg logger help

03:55:17 <AaronSw> logger, hi

03:56:43 <tav> wow

03:56:48 <tav> thats a neat feature

03:57:01 <tav> whose idea was that?

03:57:23 <AaronSw> the logs were set up by Dave Beckett (dajobe; he should be releasing the Perl code soon)

03:57:41 <AaronSw> the Chump is from Edd Dumbill and his gang (see http://usefulinc.com/chump/

03:58:08 <tav> how comes that didnt get picked up?

03:58:21 <AaronSw> it only happens if there's nothing in front of the url

03:58:25 <tav> ah

03:58:52 * tav adds the feature to his zopebot

03:59:05 <AaronSw> zopebot?

03:59:44 <tav> irc bot in zope

04:00:08 <tav> well, python, but controlled from within zope, and can access and manipulate objects in zope

04:01:02 <AaronSw> the chump's in python... is the code for zopebot available?

04:01:48 <tav> aye

04:02:07 <tav> http://www.zope.org/Members/TheJester/IrcBot

04:02:07 <dc_rdfig> B: http://www.zope.org/Members/TheJester/IrcBot from tav

04:02:11 <tav> eeek

04:02:13 <tav> soz

04:02:39 <AaronSw> B:|IRCBot for Zope

04:02:39 <dc_rdfig> titled item B

04:03:02 <AaronSw> is he on here?

04:03:40 <AaronSw> i mean, is he connected to this network?

04:04:42 <tav> not atm, but she's coming ;p

04:05:01 <tav> you use zope?

04:05:16 <AaronSw> no, but i'm thinking about it

04:05:28 <AaronSw> and DanC is interested in Zope and Python IRC bots

04:05:56 <tav> ah

04:06:02 <tav> zope rocks ;p

04:06:07 <wmf> hiroko, google for AaronSW

04:06:32 * AaronSw googles for aaronsw

04:06:44 <wmf> tav, it's not working

04:06:55 <tav> hmz

04:07:02 <tav> hiroko, hi

04:07:33 <tav> d'oh!

04:07:46 <tav> i had forgotten to add the dtml plugin for this one

04:09:04 <tav> hiroko, hi

04:09:04 <hiroko> hi there!

04:09:09 <tav> there ya go

04:09:13 <AaronSw> hiroko, are you a human?

04:09:28 <AaronSw> hiroko, fortune

04:09:36 <AaronSw> hiroko, hi

04:09:43 <AaronSw> hmm...

04:09:52 <tav> hiroko, google for AaronSw

04:10:06 <tav> soz, i killed her

04:10:39 <tav> she's only been in dev for about a week ;p

04:12:02 <AaronSw> hiroko, hi

04:12:12 <tav> ok, she's working

04:12:14 <AaronSw> hiroko, hi

04:12:18 <tav> the first request lags ;p

04:12:26 <hiroko> hi there!

04:12:28 <hiroko> hi there!

04:12:33 <hiroko> hi there!

04:12:34 <hiroko> hi there!

04:12:34 <AaronSw> hiroko, fortune

04:12:46 <tav> hiroko, google for the semantic web

04:12:46 <hiroko> http://www.w3.org/DesignIssues/Semantic.html - http://www.w3.org/2001/sw/Activity - http://www.purl.org/swag/ - http://www.google.com/search?q=the+semantic+web

04:12:47 <dc_rdfig> C: http://www.w3.org/DesignIssues/Semantic.html from hiroko

04:12:57 <tav> heh

04:13:06 <tav> dc_rdfig is gonna have some fun time

04:13:13 <AaronSw> man, we can really scrap today's chump...

04:13:25 <AaronSw> C:|Top Google Hit for "semantic web"

04:13:25 <dc_rdfig> titled item C

04:13:31 <AaronSw> C:Another thing to delete

04:13:31 <dc_rdfig> commented item C

04:13:42 * AaronSw beams that SWAG is second

04:17:34 <tav> and you are related to swag...?

04:17:48 <AaronSw> yes, i'm a founder

04:17:57 <tav> ah ;p

04:19:05 * DanC_ pores over the swap regression tests...

04:20:24 * AaronSw notes they don't seem to be well-used

04:20:45 <DanC_> indeed... I just learned how they're supposed to be used today.

04:21:00 <AaronSw> please enlighten us

04:21:09 <DanC_> you run retest.sh

04:21:17 <DanC_> well, first you mkdir temp

04:21:21 <DanC_> then you run retest.sh

04:21:41 <DanC_> (I added mkdir -p temp... but I'm not sure I checked that in yet)

04:22:18 <AaronSw> where's retest.sh

04:22:50 <DanC_> in 2000/10/swap/test

04:23:00 <DanC_> er... but I guess you don't have CVS access to that.

04:23:16 <DanC_> hmm... we gotta mirror that part of CVS in the public space...

04:23:20 <AaronSw> i don't even have web access to retest.sh

04:23:40 * DanC_ visits http://www.w3.org/2000/10/swap/test/*,access*

04:23:56 <AaronSw> a lot if the stuff there is misACLed

04:24:24 <DanC_> right... stuff has to be ACLed separately, after it's checked in; that's a pain so it often doesn't happen.

04:25:12 * AaronSw wonders about sticky ACLs

04:25:21 <DanC_> I've put "cvs/chacl integration" on the wish-list. Along with 704233 or so other items. :-{

04:26:41 <DanC_> crap; I just chacled everything in test/*,access* , but chacl didn't find retest.sh cuz it was looking in AFS, and we don't keep AFS current any more. Sigh...

04:27:36 * DanC_ logs into AFS, which he hates to do...

04:27:40 * AaronSw wonders what AFS is

04:27:48 <DanC_> you don't want to know.

04:29:34 <wmf> ah, the kids today

04:29:57 * AaronSw smacks wmf with his powerbook

04:30:27 <AaronSw> andrew file system, hmm

04:35:28 <DanC_> ok... the expected results for the first test were out of date. sigh.

04:36:31 * DanC_ tries to remember how to write shell functions...

04:39:55 <tav> hey hi

04:40:02 <tav> pretty good thanks

04:40:06 <tav> whats the [off] ?

04:40:25 <tav> nah, i know you as GabeW

04:40:33 <DanC_> logger doesn't log stuff starting with [off]

04:40:38 <tav> oh

04:42:13 * GabeW would like to encourage people to check out zope

04:44:34 <tav> ehm, why are you preceding all of your statements with [off] ?

04:44:51 <DanC_> er... what's the shell test for an empty file? I thought it was -z, but that's for an empty string.

04:45:32 <tav> [off

04:45:45 <GabeW> DanC -- in bash, perhaps -s

04:45:50 <DanC_> hmm... -s test for non-empty

04:45:56 <DanC_> so... [ ! -s file] ?

04:46:13 <GabeW> looks good to me

04:46:34 <GabeW> but I am sitting here looking at the bash oreilly book, not an expert!

04:46:56 <DanC_> I used [-s] and switched the then/else clauses. Works.

04:46:58 <DanC_> thanks.

04:50:47 <AaronSw> danc, swap/test/ref/* is still 403ing

04:52:28 <DanC_> I haven't chacl'd swap/test/ref

04:56:02 <DanC_> ok, AaronSw, see http://www.w3.org/2000/10/swap/test/ref/ (and the (brief!) explanation at the bottom of http://www.w3.org/2000/10/swap/test/)

04:58:20 * GabeW likes the XP reference

04:59:32 <AaronSw> hmm, cwm is not faring well on these tests

04:59:51 <AaronSw> or the tests aren't faring well against cwm

05:01:45 <DanC_> all the ref/* things are bad, as far as I can tell.

05:01:58 <DanC_> cwm does run, though, no?

05:02:03 <AaronSw> yeah

05:02:40 <AaronSw> some of them are simply saying the same thing in different ways

05:02:45 <AaronSw> <#Animal> vs :Animal

05:06:05 <DanC_> but even in those cases, the test input data was checked in after the ref/* output data.

05:06:09 <DanC_> so it's clearly out of date.

05:11:33 <DanC_> hmm... some of the ref/* data seems to predate some of the sorting cwm does on output.

05:15:26 <DanC_> wierd! cwm doesn't reset prefixes when it switches files. I thought that was a bug. But TimBL seems to have used it in several of the tests... see daml-pref.n3

05:31:41 <DanC_> I don't see how TimBL ever thought these tests worked.

05:41:35 <DanC_> hmm... I'd like to do some machine-processing of the daml axiomatic semantics...

05:41:42 <DanC_> sigh... the dang thing is full of windows-isms.

05:41:54 <DanC_> what's character 147 in the windows world?

05:43:05 <AaronSw> left double quotation mark

05:43:23 <AaronSw> according to http://www.indwes.edu/Faculty/bcupp/things/Characters/www/windows-chars.html

05:43:23 <DanC_> now... teach me to fish... where did you find that?

05:43:35 <DanC_> thx

05:43:44 <AaronSw> asked google "windows character 147"

05:44:11 <AaronSw> where are the axiomatic semantics?

05:52:27 <DanC_> . http://www.daml.org/2001/03/axiomatic-semantics.html

05:53:03 <AaronSw> thx

06:02:15 * dajobe wakes up, waves

06:02:21 * AaronSw waves

06:02:30 <AaronSw> what was that rss thing you wanted to show me?

06:03:09 * dajobe wonders if #rdfig needs a FAQ introducing chump and logger

06:03:26 * AaronSw thinks it needs some sort of introduction

06:03:50 <dajobe> well logger used to msg new users, I decided to get rid of that

06:03:56 <dajobe> maybe you can change the intro text?

06:04:05 <dajobe> I mean the chanserv-thing

06:04:09 <AaronSw> sure, although i think it went too

06:16:14 <AaronSw> what do you folks think of http://logicerror.com/rdfIRCWelcome

06:19:23 <tav> why not require something be said in front of the url for it to be blogged?

06:19:38 <tav> e.g. # http://foo.com

06:20:07 <AaronSw> mail chump@heddley.com

06:20:14 <AaronSw> with your suggestion

06:20:21 <tav> hmz, dont you have the sourcecode?

06:20:36 <dajobe> herm, "discussion ranges quite a bit" - something we should put a stop to, I've had comments that it is being less useful

06:20:46 <tav> dajobe?

06:21:06 <AaronSw> tav, edd runs the chump for us

06:21:17 <tav> edd is?

06:21:35 <AaronSw> edd dumbill, of XML.com and xmlhack fame

06:21:38 <dajobe> edd is away, probably catching up on real work :-)

06:22:30 <AaronSw> how about: "It's really part of the RDF Interest Group but general Semantic Web discussions are considered acceptable." ?

06:22:52 <dajobe> that's OK. We don't really need more than that.

06:23:17 * dajobe has been guilty of some topic drift

06:23:35 <AaronSw> we all have, i think

06:23:37 <dajobe> BLURB:IRC Chat Logger

06:23:37 <dc_rdfig> D: IRC Chat Logger from dajobe

06:27:48 <dajobe> D:The logger bot listens to the chat channel and records it in public logs

06:27:49 <dc_rdfig> commented item D

06:27:49 <dajobe> D:These are available at http://ilrt.org/discovery/chatlogs/rdfig/ and are written live

06:27:49 <dc_rdfig> commented item D

06:27:49 <dajobe> D:in three formats - RDF, plain text and HTML (created from RDF via XSLT)

06:27:49 <dc_rdfig> commented item D

06:27:49 <tav> ok, email sent

06:27:49 <tav> hmz, off-topic discussions are what make community ;p

06:27:49 <dajobe> D:Logger accepts a few commands that can be done publically with "logger, COMMAND" or privately with "/msg logger COMMAND"

06:27:49 <dc_rdfig> commented item D

06:27:49 <dajobe> D:The full list of commands can be found by the help command e.g. /msg logger help

06:27:49 <dc_rdfig> commented item D

06:27:49 Disconnected from irc.openprojects.net (ERROR :Closing Link: logger[tatooine.ilrt.bris.ac.uk] by forward.openprojects.net (Ping timeout for logger[tatooine.ilrt.bris.ac.uk]))

06:27:49 Attempting to reconnect

06:28:02 Topic now RDF and Semantic Web chat (blog: http://rdfig.xmlhack.com/ home: http://www.w3.org/RDF/Interest )

06:28:02 Users on #rdfig: logger hiroko tav DanC_ DanC @dajobe lasDesk jonb @AaronSw timbl dc_rdfig eikeon baud Nabil

06:28:02 <ChanServ> This channel is logged and blogged. See: http://logicerror.com/rdfIRCWelcome

06:28:32 <dajobe> D:Logger can be told to stop listening/recording to the chat, if for some reason this is required.

06:28:32 <dc_rdfig> commented item D

06:29:01 <dajobe> D:For individual messages this can be done by putting the phrase '[off]' at the start of a line of text

06:29:01 <dc_rdfig> commented item D

06:33:23 <dajobe> D:and for longer conversations, tell logger to stop listening with: 'logger, off' and recording again with 'logger, on' (there are other words)

06:33:23 <dc_rdfig> commented item D

06:33:23 <dajobe> D:The on/off messages are logger, as well as all public commands to logger.

06:33:23 <dc_rdfig> commented item D

06:33:23 Disconnected from irc.openprojects.net (ERROR :Closing Link: logger[tatooine.ilrt.bris.ac.uk] by forward.openprojects.net (Ping timeout for logger[tatooine.ilrt.bris.ac.uk]))

06:33:23 Attempting to reconnect

06:34:12 Topic now RDF and Semantic Web chat (blog: http://rdfig.xmlhack.com/ home: http://www.w3.org/RDF/Interest )

06:34:12 Users on #rdfig: logger hiroko tav DanC_ DanC @dajobe lasDesk jonb @AaronSw timbl Nabil dc_rdfig eikeon baud

06:34:13 <ChanServ> This channel is logged and blogged. See: http://logicerror.com/rdfIRCWelcome

06:34:23 <dajobe> AaronSw: is that enough?

06:34:35 <AaronSw> where is it going?

06:35:19 <dajobe> well, I'll move it somewhere if it seems complete - see if others want to add lines

06:35:37 <AaronSw> it should probably go into logger, morehelp

06:35:49 <AaronSw> but it seems pretty complete

06:36:04 * dajobe wonders if logger should listen on an HTTP port

06:36:18 <AaronSw> for what?

06:36:20 <AaronSw> greps over http would be nice

06:36:32 <dajobe> yup, I think DanC requested that earlier

06:36:41 * AaronSw updates http://logicerror.com/rdfIRCWelcome with quick intros to logger and chump

06:36:47 <DanC_> for GET requests, of course. dajobe, can you listen on two ports? does your codebase grok that sort of thing?

06:37:07 <dajobe> the perl irc modules I think can handle that

06:37:19 <DanC_> hmm... I doubt it.

06:37:30 * dajobe will probably *ship the code* before starting that

06:37:41 <DanC_> yes, ship first.

06:47:04 <dajobe> http://ilrt.org/discovery/chatlogs/rdfig/help.html

06:47:05 <dc_rdfig> E: http://ilrt.org/discovery/chatlogs/rdfig/help.html from dajobe

06:47:11 <dajobe> E:|RDF IRC Chat Logger documentation

06:47:11 <dc_rdfig> titled item E

06:48:56 * AaronSw links to it from http://logicerror.com/rdfIRCWelcome

07:08:19 <AaronSw> ahh, hi edd!

07:08:26 <edd> hello.

07:08:29 * dajobe waves

07:08:40 <edd> morning. early into work, dajobe!

07:08:59 <dajobe> not in work yet, but I'm still on HK time I guess

07:09:28 <edd> I see. I'm in sync now. Spent y'day gardening :)

07:10:48 <dajobe> edd: did you get a new intro message on connect? Did you notice?

07:11:31 <edd> yes, and yes.

07:49:12 <dajobe> I see xml-dev has got that www-rdf-logic feel today - see topic "NPR, Godel, Semantic Web" thread

07:50:16 <dajobe> http://lists.xml.org/archives/xml-dev/200105/msg00176.html

07:50:17 <dc_rdfig> F: http://lists.xml.org/archives/xml-dev/200105/msg00176.html from dajobe

07:50:30 <dajobe> F:|NPR, Godel, Semantic Web thread on xml-dev

07:50:31 <dc_rdfig> titled item F

07:51:52 <dajobe> F:where NPR=US National Public Radio

07:51:53 <dc_rdfig> commented item F

09:49:10 <dajobe> dajobe has changed the topic to: RDF and Semantic Web Chat - http://logicerror.com/rdfIRCWelcome

11:37:52 <jonb> yes a riot

13:17:25 <libby> hey bijan

13:26:10 * edd reports that the chump got a live demo at the SW devday at WWW10

13:26:19 <edd> as did dajobe's RDF-ized logs.

13:26:35 <dajobe> what fun that was!

13:27:45 <edd> for anyone interested, pics are at http://heddley.com/edd/2001/04/30/ , http://heddley.com/edd/2001/05/05/ and http://heddley.com/edd/2001/05/06/

13:28:55 <libby> cool. edd, do you have any other minutes/notes etc from the conference?

13:29:15 <edd> i'll be writing some up for XML.com tomorrow.

13:29:31 <edd> dajobe has a CD with the proceedings on, I believe.

13:29:44 <libby> I want to do some demos which show event-based info linked with other outputs and inputs and pics etc connected with events

13:29:45 <libby> cool

13:30:30 * dajobe has just mounted the cd proceedings, amused by embedded MediaPlayer video about HK IT

13:52:22 <jhendler> who gets suggestions about the rdfig.xmlhacks.com web page? Would be nice to have an easy hotlink to the days Irc log instead of having to go looking (that way one easily catches up on context before joining in)

13:55:35 <dajobe> jhendler: I think you mail chump@heddley.com

13:57:29 * edd confirms that is indeed the right place to bug him at

15:58:13 <danbri> hi, rdfists!

15:58:44 <dajobe> hi

15:59:46 * danbri wonders why http://www.w3.org/RDF/Interest/#irc needed duplicating

16:00:12 <danbri> (I prefer to point off into IRC bot howtos, makes for cheaper page maintainance...)

16:00:21 <dajobe> well, once you copy the facts there, we can go back to it

16:00:36 * danbri is sounding ungrateful; http://logicerror.com/rdfIRCWelcome has some useful additions

16:00:52 <danbri> "copy the facts" you mean bot howtos?

16:01:10 <dajobe> yes, the links added earlier

16:01:42 <danbri> I'd much rather point to http://usefulinc.com/chump/ etc., since bots evolve over time

16:02:28 * danbri wonders when we'll see the rumoured N3 version of Chump

16:03:21 <dajobe> danbri: I note Jason Diamond has discovered the issue we were chatting about in Kowloon - what to do with un-prefixed non-rdf attr. on elements

16:03:23 <edd> best ask bijan

16:03:30 <danbri> I spent some time today trying to attach stylised Perl fragments to class hierarchies. Didn't quick work...

16:03:34 <danbri> bijan?

16:03:47 <danbri> hi Edd!

16:04:13 <edd> hey danbri, still enjoying HK?

16:05:55 * danbri noticed the photo (if that's fetching, I'm worried!)

16:06:39 <DanC_> I suggest unprefixed <foo> becomes #foo; local elements have the same feel as IDs, to me.

16:07:22 <libby> why can't I access http://www.w3.org/2001/02/rdfig-f2f?

16:07:24 <danbri> ...which reduces one headache to another (I guess that's a good thing).

16:07:31 <libby> - internal server error :-(

16:08:09 <DanC_> headache: was that in re #foo?

16:08:10 <danbri> WorksForMe(tm), and that's without any authentication or fancy business. I suspect the W3C mirror site you're hitting is out of sync.

16:08:42 <danbri> headache: yes, confusion around semantics of #blah names without some HTTP context to give them meaning...

16:09:32 <dajobe> DanC_: attributes, not elements so what does <foo:bar blah="something"/> interpret to in RDF: 1) blah, 2) foo:blah or 3) ignored. I was going for 3.

16:10:31 <danbri> http://citeseer.nj.nec.com/artale98temporal.html

16:10:33 <dc_rdfig> G: http://citeseer.nj.nec.com/artale98temporal.html from danbri

16:10:38 <danbri> A Temporal Description Logic for Reasoning about Actions

16:10:39 <danbri> and Plans (1998)

16:10:43 * DanC_ gets frustrated when danbri takes any form of confusion and instantly decides it's a problem.

16:11:01 <danbri> G:|A Temporal Description Logic for Reasoning about Actions and Plans(1998)

16:11:01 <dc_rdfig> titled item G

16:11:42 <libby> got it, thanks

16:11:54 <DanC_> danbri, what's the actual problem with a property named http://xxx#foo? you think the name of, for example, http://www.w3.org/1999/02/22-rdf-syntax-ns#type is a problem?

16:11:59 <danbri> DanC, that's unfair. It's a known problem with the URI spec that the meaning of #foo URI refs is defined in terms of HTTP transactions.

16:12:25 <DanC_> no, it's not a known problem. It's a known solution that works quite well in practice.

16:13:51 <danbri> So, if we're told that the string 'http://www.w3.org/Icons/WWW/w3c_home#foobar' is a URI Reference, what factors are relevant in determining what the resource is that it is the name of?

16:14:30 <DanC_> whatever factors you like. I don't think I understand the question.

16:15:34 <DanC_> it's a name. An identifier. What it denotes is constrained by whatever formulas you've seen it in (and other formulas that constrain those terms).

16:15:41 <danbri> If you do an HTTP GET or HEAD on http://www.w3.org/Icons/WWW/w3c_home you find (say) GIF, JPEG, SVG, PNG flavours available. The URI spec says that http://www.w3.org/Icons/WWW/w3c_home#foobar names different things depending on which of those flavours we're concerned with.

16:16:16 <DanC_> no, it doesn't say that it names different things. It names something that is represented differently in different responses.

16:16:16 <danbri> That's too alice-in-wonderland for my taste. That URI should denote what it denotes regardless of where I've personally encountered it.

16:17:49 <danbri> If that's true, there's hope. I understand that we can get different representations of a resource back in different responses, and that those (varying) responses have name-able parts. I took the URI spec to say #foobar named different parts/views of the different responses.

16:21:33 <DanC_> in fact, with negotiated resources, the response actually means "I can't tell you exactly what w3c_home's state is, but I can give you the state of w3c_home.png , which is a specific variant of it."

16:24:26 <danbri> This is an interesting thing to try to model. With time-varying resources (weather etc, documents that change) we also have variants, but they don't get their own URIs.

16:25:42 <danbri> [[The semantics of a fragment identifier is a property of the data

16:25:43 <danbri> resulting from a retrieval action, regardless of the type of URI used

16:25:43 <danbri> in the reference

16:25:47 <danbri> ]]http://www.ietf.org/rfc/rfc2396.txt

16:26:27 <danbri> ...I'd taken this to as "semantics" in the sense of reference, ie. what the frag identifier refers to. I'm re-reading again trying to see it differently.

16:27:39 <danbri> Sigh. I revert to my previous position, that this is broken: [[A fragment identifier is only meaningful when a URI reference is

16:27:40 <danbri> intended for retrieval and the result of that retrieval is a document

16:27:40 <danbri> for which the identified fragment is consistently defined.

16:27:48 <danbri> ]]

16:28:22 <DanC_> read that as: "This specification only specifies the meaning of a fragment identifier in the context of a retrieval ...".

16:28:24 <danbri> Section 4.1, Fragment Identifier.

16:29:24 <danbri> s/read that/wish that read/, sure. If the URI spec (hmm, guess it's only the URI Syntax spec) tells me URI frags are only meaningful during retrieval, I consider that a bug.

16:29:32 <DanC_> no, don't wish. Do.

16:29:39 <danbri> Which isn't the end of the world. How do we fix it?

16:30:39 <DanC_> The URI doesn't completely define URIs, any more than the IP spec defines all uses of IP packets.

16:30:57 <danbri> The 'read that' approach suggests that every time a W3C spec normatively cites RFC 2396, they should also normatively cite Dan'n'Dan's guide to plausible-reinterpretation of 2396.

16:31:37 <DanC_> no, they don't need my guide; they just need to give any interpretation of URIs in that spec beyond what's in the URI spec. Just like specs layered on top of IP.

16:32:20 <danbri> When RFC 2396 says defines the syntax for frag IDs, and tells me when they *lack meaning* (fail to refer, are meaningless, etc...), I can reasonably expect other specs to provide further info about URIs. But not to contradict RFC 2396.

16:33:01 <danbri> If RFC 2396 says a decontextualised URI-ref is meaningless, other specs aren't merely adding more facts if they say it's meaningful. They're in direct contradiction.

16:33:05 <DanC_> the 'read that' approach isn't special to me. It's common sense that specs have scope, and there is information in the world outside that scope.

16:33:29 <danbri> Agreed. But this is pushing the limits of polite reinterpretation. However well motivated.

16:33:52 <DanC_> STOP. realize that "meaningless" in RFC2396 means "no meaning assigned by RFC2396". Meaning assigned by other specs doesn't contradict that.

16:34:42 <DanC_> I think this isn't pushing any limits; it's just common sense. I suggest you broaden your view.

16:36:34 <danbri> I understand the notion of successive specs layering on richness (XML 1.0, namespace, ...). But RFC 2396 doesn't scope itself as modestly as you wish. It claims to be a protocol for the 'internet community'.

16:36:47 <DanC_> so does the IP spec.

16:37:21 <DanC_> I'm not wishing, danbri; I'm observing.

16:37:40 <danbri> A related line I'm warmer too: RFC2396 is *out of scope* whenever it addresses questions of meaning, reference, interpretation. It defines a syntax for URIs and URI References; text that makes claims about meaning is speculative/informational.

16:38:46 <danbri> Do we agree that RFC2396 claims certain URI refs are meaningless? (and doesn't explicitly scope that, ie we don't see: "according to this spec, there is no known meaning") ?

16:39:24 <DanC_> hmm...

16:39:36 <danbri> If that's the case, two approaches: (i) DanC approach: define additional rules for assigning meaning to URI refs (ii) DanBri approach: declare the meaning-related parts of RFC2396 to be of no interest to applications using URI *syntax*

16:40:37 <DanC_> no, RFC2396 doesn't specify a set of URI refs that are meaningless. it doesn't say "if it's spelled this way, it's meaningless." It just says "unless you do this, there's no [implicit: standardized] meaning."

16:42:39 <danbri> it says (rightly or wrongly) "unless encountered in retrieval context, it is not meaningful"

16:43:02 <danbri> I don't understand what you mean by [standardized] here. "Assigned by this spec", I guess.

16:43:30 <DanC_> that says that the meaning of a URI reference depends on context; not that there exists some URI references that have no meaning in any context whatsoever.

16:44:45 <danbri> Are we reading the same paragraph? "A fragment identifier is only meaningful when..."...

16:45:39 <DanC_> i.e. you said "Do we agree that RFC2396 claims certain URI refs are meaningless?"; i.e do we agree that there is some set of URIrefs (i.e. some set of strings) specified by RFC2396 to have no meaning. I don't agree that there is such a set. If there is, please give an example of a URIref from that set.

16:46:05 <danbri> Sorry, but "only meaningful when..." clinched it for me.

16:49:31 <DanC_> clinched what? if there's such a set of URIrefs, just give me one item from that set.

16:50:11 <DanC_> RFC2396 says that there are some *contexts* in which some URIrefs have no meaning.

16:51:28 <danbri> Good question! We're told the fragids in URIrefs lack meaning unless (a) the URIref is "intended for retrieval" and (b) results (when...?) in a doc of some suitable kind. So an example might be http://topsecret.example.com/blah#foo if that site never allowed access to any resources.

16:53:28 <danbri> RFC2396 appears to list the contexts in which URIrefs are meaningful.

16:54:32 <danbri> Where do you get "some" from? It says *only*. Maybe I'm not steeped enough in the logic literature, but to me *only* sets me up to be suprised if some other context is subsequently proclaimed meaningful.

16:55:54 <danbri> I'm willing to be suprised. Willing to do whatever it takes to patch up RFC2396. But your reading still seems Alice in Wonderland to me. Would you consider taking an "RFC2396 is out of scope addressing semantics" line instead?

16:58:32 * DanC_ finishes a telcon...

16:58:35 <danbri> http://ilrt.org/discovery/chatlogs/rdfig/2001-05-08.html#T16-10-43

16:58:35 <dc_rdfig> H: http://ilrt.org/discovery/chatlogs/rdfig/2001-05-08.html#T16-10-43 from danbri

16:59:22 <danbri> H:|DanC and DanBri rehash the "semantics of URI refs" discussion (neither seems to persuade the other)

16:59:22 <dc_rdfig> titled item H

17:00:33 <DanC_> if you've got a few more minutes, let's try to go slowly. Please try to write down, in logical terms, the "only" bit from the RFC.

17:00:52 <danbri> H:See also [RDF issue rdfms-fragments|http://www.w3.org/2000/03/rdf-tracking/#rdfms-fragments] and [RFC2396|http://www.ietf.org/rfc/rfc2396.txt].

17:00:54 <dc_rdfig> commented item H

17:01:11 <DanC_> I read it as: There exists some contexts ?C in which there exists some URI references ?R so that ?R has no meaning in ?C.

17:01:52 <DanC_> equivalently: (exists (?C ?R) (no-meaning-in ?R ?C))

17:02:29 <danbri> hmm..

17:02:37 <DanC_> equivalently: (not (forall (?C ?R) (meaning-in ?R ?C))

17:06:43 * danbri blames netlag

17:07:15 <DanC_> I'm pretty sure you'll end up agreeing that RFC2396 doesn't define a one-place predicate (meaningful ?R).

17:08:10 <danbri> It's two place; it relates ?R to the world of the 'internet community' called out in the Status section.

17:08:49 <DanC_> no, it's not even that broad.

17:09:03 <danbri> ?R is meaningful in the Internet world solely by virtue of meeting the context defined in sc4.1. That's how I read 'only'.

17:09:12 <DanC_> i.e. RFC2396 doesn't define (meaningful-in ?R InternetCommunity)

17:09:56 <danbri> It defines syntactically-valid in a wide context, why should the reference oriented part of the spec differ?

17:10:10 <DanC_> if you take 'the Internet world' to be a constant, you're back to a one-place predicate (meaningful ?R), defined as (meaningful-in ?R InternetCommunity).

17:10:44 <DanC_> why should it differ: because that's the nature of identifiers; they take on meaning by use.

17:11:33 <danbri> If we had s/is only meaningful/is only assigned meaning by this spec/ I'd be happy.

17:12:14 <DanC_> I consider that an editorial difference. But it's still not a well-defined one-place predicate on URI references. It's still got an implicit context argument.

17:13:03 <DanC_> i.e. it's not a function of the URI reference itself; i.e. how it's spelled. It's a function of the URI reference *in a context*.

17:13:50 <danbri> I'm happy with the "meaning by use" slogan if we're talking about natural language, cognitive science or what have you. When talking about strings used as identifiers in computer systems, the spec that defines the datatype of the identifier string gets to have a big say. I can use ISBNs in all sorts of unexpected ways, but I don't get to change what they mean. That's dictated by some spec.

17:15:10 <DanC_> yes, you do get to change what they mean if you're a publisher. (and I'm not talking about nasty re-use). You get to buy an ISBN prefix; i.e. to give it meaning that it did not have in chronologically-previous contexts. Then you get to assign specific ISBNs to specific (publications of) books.

17:15:17 <danbri> So, I'm happy with what you say as a story about how things should be. I just don't see that story in the current RFC. Sorry Dan.

17:16:08 <DanC_> Do you agree that this story need not be in the URI RFC? i.e. that there's knowledge about how URIs work to be found outside the URI spec, just as there's knowledge about how IP packets work to be found outside the IP spec?

17:17:40 <danbri> I *was* talking about nasty re-use. I hereby assign isbn:059600110x to refer to you. If I do that 20,000,000 times, does the fact that 'most' uses of that ID use it for you change it's meaning?

17:18:08 <danbri> agree: Yes, ideally the RFC for URI syntax would allow the semantics/reference story to be layered on gracefully by other specs.

17:18:24 <danbri> Sadly, it doesn't.

17:19:10 <DanC_> re hereby: yes, that does change its meaning, in practice. This is risk/failure-mode of URIs, but that's more or less life as we know it.

17:19:26 <DanC_> actually, gladly, it does.

17:19:46 <danbri> On my (it seems controversial) reading, anyway. Folk who believe the 2396 doc and then encounter subsequent layers will be suprised. 2396 says URIrefs only have meaning in certain contexts. Other specs may contradict that.

17:20:19 <DanC_> no, they don't constadict it. Please open your mind.

17:20:48 <danbri> It doesn't re-assign the URI-spec-assigned meaning, since that devolves to the (hmm, I'm assuming there is one) ISBN URI spec, which (I assume) doesn't allow people to be named.

17:20:54 <DanC_> If spec X assigns meaning to R1, that does not contradict the fact that spec Y assigns no meaning to R1.

17:21:52 <danbri> What's with the hippy talk? My mind's plenty open.

17:22:22 <DanC_> No, you refuse to allow that other folks can layer on the URI spec, when it's plainly allowed.

17:22:35 <danbri> It's not that the spec assigns no meaning to R1, it says meaning is not-assignable to R1.

17:23:00 <DanC_> not-assignable: no. read it again. Write it down logically. It doesn't say that.

17:23:50 <DanC_> if it does say that, please prove, by example, that there is such an R1.

17:24:56 <danbri> OK, http://intranet.ilrt.bris.ac.uk/private/temp/dan/topsecret#foobar is my candiate URIref that has no semantics.

17:25:04 <danbri> [[The semantics of a fragment identifier is a property of the data

17:25:07 <danbri> resulting from a retrieval action, regardless of the type of URI used

17:25:07 <danbri> in the reference

17:25:07 <danbri> ]]

17:25:22 <danbri> *The* (not *a* or *some*...).

17:26:07 <DanC_> now all I have to do is get you to serve a document at that address, and your claim is falsified. i.e. that R1 is *not* meaningful in all contexts. There is a context (the one in which you're convinced to service that address) in which it has meaning.

17:26:24 <DanC_> s/meaningful in all contexts/meaningless in all contexts/.

17:28:40 <DanC_> RFC2396 does *not* specify (not (meaningful "http://intranet...")).

17:28:41 <danbri> Gee, I better not put any document there then. Or we'll get into interpreting the second half of the last sentence of RFC2396 / 4.1. Which apeals to the notion of 'consistently defined'

17:29:24 <DanC_> it only specifies (forall (?C) (if (some-constriaints-on ?C) (not (meaningful-in "http://intranet..." ?C)))

17:30:02 <danbri> You've not been citing any actual text from the RFC2396 spec in this discussion. Maybe I've excepted all the relevant bits? I'd expect there to be some other parts though that more clearly support your pov.

17:30:16 <DanC_> but do you see that whether "http://..." is meaningful or not is *not* well-defined by RFC2396? it's meaningful-ness is contingent, not well-defined.

17:31:36 <DanC_> I'm not citing any text because I'm not making any claims about RFC2396; you claimed that it constrains RDF in some way; I'm trying to talk you out of reading too much into the RFC.

17:32:04 <danbri> Ugh. We're going round in circles. I think we both agree RFC2396 should stick to a context when talking about meaningfulness (reference, semantics) of URIrefs. You believe it does (though this left implicit, an editorial issue from your pov). I believe it doesn't.

17:32:20 <DanC_> Look, your position is testable.

17:32:43 <danbri> Maybe I should change my mind. Based on context supplied by IETF/standards etc process...? ie. that the RFC can't constraint other specs in the way I fear it tries to.

17:32:56 <danbri> "a document

17:32:57 <danbri> for which the identified fragment is consistently defined

17:32:57 <danbri> "

17:33:10 <danbri> ...would need sharpening up if we wanted to make this testable.

17:33:23 <DanC_> If RFC2396 defines certain URIrefs as meaningless, regardless of context, then (exists (?R) (not (meaningful (?R)). Just give me such an ?R. "http://intranet..." clearly isn't such an ?R, cuz we both know there are contexts in which it has meaning.

17:34:09 <danbri> My reading (and this is pretty guessy) is that it means we get back something via something like an HTTP transaction and that something is a content-typed bag'o'bits, and that content type has a specification that assigns meanings to URI refs, and in particular to this particular URI ref.

17:35:17 <danbri> I did. If you like I'll take the time to rig up something that sends you a bag'o'bits with a content-type of my choice where that content type doesn't assign meaning to certain frag IDs

17:36:20 <DanC_> you did? I thought we agreed there were contexts in which "http://intranet..." does have meaning. no?

17:37:11 <DanC_> yes, you can cook up contexts in which "http://intranet..." isn't meaningful; i.e. where no meaning is given. You can't stop me from cooking up contexts in which the meaning *is* given.

17:37:18 <danbri> http://intranet.../blah/foo might have meaning (ie. refer) even if http://intranet.../blah/foo#bar lacked meaning according to 2396

17:37:18 <dc_rdfig> I: http://intranet.../blah/foo from danbri

17:38:12 <DanC_> The point is: you have NOT exhibited a URIreference that, REGARDLESS OF CONTEXT, has no meaning. i.e. you have not supported the position that RFC2396 defines a set of URIrefs that have no meaning.

17:38:56 <danbri> can't I? Assume I control it's ability to expose itself via HTTP transactions. I just need to make sure doesn't expose representations in formats whose specs assign meaning to the frag-id I used.

17:39:27 <DanC_> assuming that you "control its ability..." is assuming a context.

17:40:38 <danbri> How about URI refs from a scheme that doesn't support retrieval? isbn:059600110x#elbow for example.

17:40:45 <DanC_> my point is: (meaningful ?R) is *not* a well-defined property of URIrefs, the way (succsor ?N) is defined for natural numbers. There's more to (meaningful ...) than just the spelling of the URIref.

17:41:52 <danbri> I agree with that.

17:41:57 <DanC_> WHEW!

17:42:08 <danbri> But the URI spec still sucks.

17:42:25 <DanC_> show me a spec that doesn't suck. ;-)

17:42:29 <danbri> c'mon, agree with me. Nobody's looking.

17:42:32 <danbri> WHEW!

17:43:09 <danbri> I suppose the less foundational the spec, the less I care. URI is pretty foundational...

17:44:23 <danbri> What you said just now, that there's more to (meaningful) than the spelling of a URIref..., suggests that the URI spec could usefully lose it's portions on meaning/reference. And just provide a grammar for URI syntax parsers.

17:44:40 <DanC_> perhaps.

17:45:14 <danbri> oops. 1:45 am. I'm nearly back on UK time :)

17:45:30 <DanC_> But there is an internet-wide agreement for assigning meaning to identifiers, and the URI syntax is of little use if completely separate from that social process.

17:46:18 <danbri> There's an internet-wide agreement for assigning meaning to identifiers? Cool! Where...?

17:46:54 <danbri> There are internet wide conventions for doing things with strings of a certain format. Which works all the while we avoid talking about 'meaning'...

17:47:10 <DanC_> sure... (1) you write an RFC for a URI scheme; i.e. you get consensus in the worldwide community about that much...

17:47:47 <DanC_> (2) that scheme generally tells you how you can assign a name in such a way that the rest of the world agrees (by not objecting to the RFC) that you "own" that name.

17:48:58 <DanC_> no, we need not avoid talking about meaning. Identifiers take on meaning by use. There's a world-wide convention that if I (a) rent a DNS name, and (b) run an HTTP server at port 80 on that host, I get to say what those names mean.

17:49:13 <DanC_> The rest of the world isn't *logically* compelled to accept my defintions, but they are *socially* bound.

17:50:18 <DanC_> and, in fact, there are social consequences if somebody, say, hijacks my domain name, or spreads misinformation about what my pages say, etc.

17:50:26 <danbri> I can use http: names by following (1) and (2) which remaining agnostic (or there being no fact of the matter) about what I've *really* named with those names. My webserver behaves pretty predictably, even while we argue about what I've really bound my URI names to...

17:51:26 * DanC_ curses his IRC client, which throws away the current buffer when I hit the up arrow.

17:51:44 <DanC_> argue: yes, it's true that we never reach logical certainty about what meaning you've given to your identifiers.

17:52:29 <DanC_> any computing I do based on stuff I get from your web site is predicated on an assumption that the stuff I get from your web server is true/reliable.

17:55:17 <DanC_> There are some logical certainties that can be communicated: e.g. that if I get a 200 OK r1.title="xyz" at 4pm, and at 5pm you tell me 304 not modified, then I'm licensed to conclude that r1.title="xyz" at 5pm as well, even though I don't know the exact identity of r1.

17:55:43 <danbri> Do have any view on what the social/technical _act_ is whereby I bind a URI name to something? Presumably there are points in time prior to which a URI is unbound, after which it is bound. I'd like to know more about what happens to make that change...

17:56:15 <danbri> r1.title: agreed

17:58:07 <DanC_> re social act: some bits of U.S. law say that something is "published" (in the sense that the publisher becomes liable etc.) when 6 copies are distributed.

17:58:39 <DanC_> so when your HTTP server serves the 6th copy (or thereabouts; I doubt the law is picky about exact numbers) you've committed the act of publication.

17:58:48 <timbl> There is nothing in HTTP to describe the time-variance of the binding

17:58:48 * DanC_ takes a break...

17:58:55 <danbri> That's interesting; hadn't heard of that before.

17:59:19 <danbri> http://members.aol.com/lshauser/mts.html

17:59:20 <dc_rdfig> J: http://members.aol.com/lshauser/mts.html from danbri

17:59:31 <danbri> J:|Realism, model theory, and linguistic semantics

17:59:32 <dc_rdfig> titled item J

17:59:47 <danbri> J:On my pile of things to read later...

17:59:47 <dc_rdfig> commented item J

18:01:40 * danbri heads off, amused as ever to find a philosophy paper that's relevant to his day job

18:04:09 * lasDesk wonders whether there's a meeting going on that she's supposed to be at....

19:14:06 Topic now RDF and Semantic Web Chat - http://logicerror.com/rdfIRCWelcome

19:14:06 Users on #rdfig: logger_1 danja hiroko jonb-gk bijan jhendler timbl benny tav DanC_ DanC lasDesk jonb dc_rdfig eikeon baud Nabil

19:14:06 <ChanServ> This channel is logged and blogged. See: http://logicerror.com/rdfIRCWelcome

19:14:53 <dajobe> Logger told to quit

19:15:02 Disconnected from irc.openprojects.net (ERROR :Closing Link: logger[137.222.34.230] by forward.openprojects.net (Overridden by other sign on))

19:15:02 Attempting to reconnect

19:15:53 Topic now RDF and Semantic Web Chat - http://logicerror.com/rdfIRCWelcome

19:15:53 Users on #rdfig: logger @dajobe timbl danja hiroko jonb-gk bijan jhendler benny tav DanC_ DanC lasDesk jonb Nabil dc_rdfig eikeon baud

19:15:53 <ChanServ> This channel is logged and blogged. See: http://logicerror.com/rdfIRCWelcome

20:06:19 <dajobe> dajobe has changed the topic to: RDF and Semantic Web chat (blog: http://rdfig,xmlhack.com/ home: http://www.w3.org/RDF/Interest/ )

20:33:52 <SethR> H: an interesting debate indeed !

20:33:52 <dc_rdfig> commented item H

19:59:37 <SethR> I: isA Class

19:59:38 <dc_rdfig> commented item I

20:00:15 <SethR> I: semName "Identity"

20:00:15 <dc_rdfig> commented item I

20:02:28 <SethR> I: uriName "http://intranet.../blah/foo"

20:02:29 <dc_rdfig> commented item I

20:05:12 <SethR> I: seeAlso [Identity|http://robustai.net/ai/identity.htm]

20:05:13 <dc_rdfig> commented item I

20:07:38 <SethR> I: comment "I have defined 'http://intranet.../blah/foo' to mean something in the context of this document - like it or not!"

20:07:39 <dc_rdfig> commented item I

21:02:00 <wmf> hey aaron

21:02:08 <AaronSw> hi there

21:07:29 <DanC_> http://www.daml.org/validator/

21:07:29 <dc_rdfig> K: http://www.daml.org/validator/ from DanC_

21:07:34 <DanC_> K:|DAML Validator

21:07:34 <dc_rdfig> titled item K

21:07:38 <DanC_> K:doesn't seem to work

21:07:38 <dc_rdfig> commented item K

21:14:28 <AaronSw> AaronSw has changed the topic to: Semantic Web Chat (logged: http://rdfig.xmlhack.com/ home: http://www.w3.org/RDF/Interest/#irc )

22:02:54 <AaronSw> AaronSw has changed the topic to: Semantic Web Chat - http://logicerror.com/rdfIRCWelcome

22:03:19 * AaronSw -- with apologies to danbri

22:03:25 <dajobe> dajobe has changed the topic to: RDF and Semantic Web chat (blog: http://rdfig,xmlhack.com/ home: http://www.w3.org/RDF/Interest/ )

22:03:28 <dajobe> :-)

22:03:37 <dajobe> better pick one to keep

22:03:39 <sbp> Erm... rdfig,xmlhack?

22:03:50 <sbp> Maybe it should be a dot

22:03:57 <dajobe> dajobe has changed the topic to: RDF and Semantic Web chat (blog: http://rdfig.xmlhack.com/ home: http://www.w3.org/RDF/Interest/ )

22:04:14 <sbp> That's better. Now I vote for Aaron's

22:04:16 <sbp> :-)

22:04:46 <DanC_> pls keep rdfig.xmlhack.com in the topic, since that page is collaboratively maintained.

22:04:46 <dajobe> I feel we should point directly to the chump and the interest group home page

22:04:59 * sbp was kidding, and points that out

22:05:15 * AaronSw is happy to give folks access to the irc intro page

22:05:42 <AaronSw> AaronSw has changed the topic to: RDF and Semantic Web chat (blog: http://rdfig.xmlhack.com/ home: http://www.w3.org/RDF/Interest/#irc )

22:05:57 <AaronSw> if we're going to point to the interest group page we might as well point to the good part

22:06:00 <AaronSw> ;-)

22:06:02 <dajobe> AaronSw, it is the interest group page, not the irc page

22:06:17 <dajobe> you can always follow the link

22:06:28 <AaronSw> what do you mean?

22:06:30 <DanC_> btw... TimBL checked in a v. broken version of cwm.py. look out!

22:07:05 <AaronSw> w/o getting into the argument of whether that identifier has semantics... that does point to the IRC page for this channel

22:07:13 <DanC_> we're working toward the "make sure all the regression tests pass before you check in" rule, but we're quite a ways off just yet.

22:07:16 <AaronSw> err the web page for this irc channel

22:11:33 <AaronSw> does a DTD reference hold semantics?

22:12:22 <AaronSw> i.e. if I say <!DOCTYPE xxx PUBLIC "-//blah//xxx//EN"...> am i claiming that this is a document of type xxx?

22:12:26 <DanC_> H:I think we did come to agreement: danbri agreed that RFC2396 doesn't/needn't constrain higher-level specs quite so much, and DanC agreed that RFC2396 still sucks ;-)

22:12:26 <dc_rdfig> commented item H

22:21:40 <sbp> Aaaaaah, 1.37...

22:23:56 <sbp> The caveat is well noted, by the way

22:24:59 <sbp> Still, I feel as if money is falling on my head

22:26:22 <sbp> Hmm, there's some new terms in the logic namespace to hack about with, although I won't guess at how much implmeentation there is in the engine yet

22:26:42 <sbp> Includes, greater than, uri etc.

22:31:05 <AaronSw> H:Hmm, it does not seem clear to me that the RFC binds resources to fragment identifiers at all

22:31:05 <dc_rdfig> commented item H

22:31:56 <AaronSw> H:IOW, it seems that http://.../foo#bar is bound to the same resource as http://.../foo#spam

22:31:56 <dc_rdfig> commented item H

22:36:33 <sbp> It's the confusion between URI-References and URIs...

22:36:57 <AaronSw> do uri-refs bind to resources?

22:37:16 <AaronSw> the spec doesn't seem to be clear (i may just be not reading clearly)

22:38:25 <sbp> URI-Refs do... not sure about Fragments... I don't think so

22:38:34 <AaronSw> urirefs include fragments

22:38:40 <AaronSw> uris don't

22:38:44 * sbp tries to recall what Sandro wrote

22:38:50 <sbp> Oh, vice versa then

22:39:09 <sbp> sorry, I'm doing many things here at once... megamultitasking

23:00:13 <lilo> [GlobalNotice] Good evening, all. The news is up on http://openprojects.net/news.shtml along with lots of other information on OPN project status and philosophy. Happy Tuesday. :)

23:05:10 <jhendler> DanC: you are right - validator worked for me yesterday, same file crashes today - email sent to drager@bbn.com