Semantic Web Interest Group IRC Chat Logs for 2003-08-20

This is an automatically generated IRC chat log made by the logger bot from the Semantic Web Interest Group IRC chat at irc://irc.freenode.net/rdfig (also known as server irc.freenode.net channel #rdfig if that URI does not work for you).

NOTICE: #rdfig logs are being turned off 2004-12-03. Please switch to the new and shiny #swig channel for Semantic Web Interest Group chat. Change your client to #swig and enjoy the new experience. Or read the latest #swig logs to see what you've been missing :)


Semantic Web Interest Group Logs > 2003 > 2003-08 > 2003-08-20 (Latest) (Search)

01:01:38 <jimH> J: http://www.computerworld.com.au/index.php?id=1392110823&fp=16&fpid=0

01:01:38 <dc_rdfig> Added comment J7.

01:01:54 <jimH> J7: [http://www.computerworld.com.au/index.php?id=1392110823&fp=16&fpid=0| ComputerWorld]

01:01:54 <dc_rdfig> Replaced comment J7.

02:02:07 <JimJibber> JimJibber is now known as JibberJim

04:40:20 <jimH>http://www.geocities.com/EnchantedForest/Dell/4500/quo_wol.gif

04:40:20 <dc_rdfig> A: http://www.geocities.com/EnchantedForest/Dell/4500/quo_wol.gif from jimH

04:40:54 <jimH> A:| OWL acronym explained

04:40:54 <dc_rdfig> Titled item A.

05:15:07 <Mutiny-> Mutiny- is now known as Mutiny

05:58:16 <burtonator_> burtonator_ is now known as burtonator

07:37:35 <GNUWookie>http://gcc.gnu.org/ml/gcc/2003-08/msg01117.html

07:37:35 <dc_rdfig> B: http://gcc.gnu.org/ml/gcc/2003-08/msg01117.html from GNUWookie

07:38:05 <GNUWookie> B:|Post/Thread from mdupont about OWL/RDF and the possible usages for the GCC

07:38:06 <dc_rdfig> Titled item B.

07:59:28 <CaptSolo> yo gnuwookie :)

08:18:00 <arnarl> hi

08:36:30 <Da5iD> Anyone know what lovesan or blaster worm traffic looks like through ettercap? I'm seeing some really strange stuff, but the system in question is up to date and doesn't have any traces of either

08:37:53 <Da5iD> I'm seeing the computer hit port 135 like crazy, counting up in a subnet. Another is doing it on port 80

09:10:43 <danbri>http://www.f-secure.com/v-descs/sobig_f.shtml

09:10:43 <dc_rdfig> C: http://www.f-secure.com/v-descs/sobig_f.shtml from danbri

09:10:50 <danbri> C:|Sobig.F virus

09:10:51 <dc_rdfig> Titled item C.

09:11:48 <danbri> C:W3C's mailing lists are currently bogged down thanks to this pest.

09:11:48 <dc_rdfig> Added comment C1.

09:36:19 <Da5iD> actually.. it was Nachi - turns out my definitions were behind after all.. I don't understand the one hitting port 80 though..

11:14:34 <swh> ?

11:14:50 <mortenf> ?!?

11:18:36 <Wack> ...

11:29:32 <swh> sorry - hit kb by mistake :)

11:43:44 <DanC> hmm... Borden's message about science applications was underappreciated, I think. http://lists.w3.org/Archives/Public/www-webont-wg/2002Mar/0148.html

11:59:12 * DanC considers adding an issue for each dependency

12:12:09 <ndw_> ndw_ is now known as ndw

12:27:20 <danbri_dna> foafbot, nori's name?

12:27:33 <danbri_dna> wrong window!

12:27:36 * danbri_dna testing i18n...

12:40:29 <tav> tav is now known as tav|offline

12:55:23 <Arnia> Quick question: Is there a theoretical reason for cwm's built-ins only working in the antecedent of a rule?

13:04:41 <DanC> er... theoretical?

13:05:03 <DanC> no, it's entirely a software design choice.

13:05:31 <DanC> but it's pretty much definitional... i.e. if something worked other than in the antecedent of a rule, it wouldn't be a cwm built-in

13:21:14 <ndw> ndw is now known as ndw^afk

13:41:09 <ndw^afk> ndw^afk is now known as ndw

13:44:36 <DanC> norm, dm93.org is pretty much back. http://dm93.org/z2001/WearableGizmo

13:47:07 <ndw> Thanks, DanC. I found it on the tmobile site; it's unclear from the coverage map if I can get tmobile where I live though.

13:47:24 <DanC> ah

13:47:47 <hendry> What is the correct terminology here; Make use of elements/properties in Dublin Core's RDFS?

13:50:26 <libby> BLURB: RDF calendar meet today

13:50:26 <dc_rdfig> D: RDF calendar meet today from libby

13:50:51 <libby> D:[http://www.timeanddate.com/worldclock/fixedtime.html?day=20&month=8&year=2003&hour=16&min=0&sec=0&p1=0| Wednesday, 2003-08-20, 1600UTC]

13:50:51 <dc_rdfig> Added comment D1.

13:51:27 <libby> D:[http://rdfig.xmlhack.com/2003/07/30/2003-07-30.html|last meeting's weblog], [http://ilrt.org/discovery/chatlogs/rdfig/2003-07-30.html#T16-02-04|logs]

13:51:28 <dc_rdfig> Added comment D2.

13:52:22 <libby> BLURB:calendar meet agenda item E: prodid schemas

13:52:22 <dc_rdfig> E: calendar meet agenda item E: prodid schemas from libby

13:52:39 <libby> E:see [action libby|http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056556072.203619

13:52:39 <dc_rdfig> Added comment E1.

13:53:17 <libby> BLURB: calendar meet agenda item F: regression tests for .ics->.rdf and vice-versa

13:53:17 <dc_rdfig> F: calendar meet agenda item F: regression tests for .ics->.rdf and vice-versa from libby

13:53:26 <JimJibber> JimJibber is now known as JibberJim

13:53:39 <libby> F:see[morten's action|http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056557026.871899

13:53:39 <libby> ]

13:53:39 <dc_rdfig> Added comment F1.

13:53:53 <libby> F1:see[morten's action|http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056557026.87189]

13:53:54 <dc_rdfig> Replaced comment F1.

13:54:34 <DanC> .time

13:54:34 <datum> Wed, 20 Aug 2003 13:54:33 GMT

13:54:41 <libby> BLURB:calendar agenda item G: Interpretation properties and timezones

13:54:42 <dc_rdfig> G: calendar agenda item G: Interpretation properties and timezones from libby

13:55:46 <libby> GabeW: see [action libby|http://rdfig.xmlhack.com/2003/05/14/2003-05-14.html#1052921345.552964], and [email to RDFcalendar|http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Aug/0002.html] and [wiki page|http://esw.w3.org/topic/InterpretationProperties]

13:55:52 <libby> G:see [action libby|http://rdfig.xmlhack.com/2003/05/14/2003-05-14.html#1052921345.552964], and [email to RDFcalendar|http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Aug/0002.html] and [wiki page|http://esw.w3.org/topic/InterpretationProperties]

13:55:53 <dc_rdfig> Added comment G1.

13:56:20 <libby> BLURB:calendar meet agenda item H:IDs for events

13:56:20 <dc_rdfig> H: calendar meet agenda item H:IDs for events from libby

13:56:36 <libby> H:see[summary email|http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Aug/0001.html]

13:56:36 <dc_rdfig> Added comment H1.

13:57:07 <JibberJim> I'd be interested in looking if we could have dates with optional years in the format to - good for repeating events, you could just say --12-26 Boxing Day for example, but that's not on the Agenda.

13:57:50 * DanC doesn't consider the agend written in stone

13:58:26 <DanC> you can express "every year on 12 December" in icalendar, and hence in our RDF calendar schema

13:59:06 <mortenf> G:see also [reply from mortenf|http://www.wasab.dk/morten/2003/08/cal/ip.txt] that has yet to make it to the list

13:59:06 <dc_rdfig> Added comment G2.

13:59:29 <JibberJim> yes, but it's rather verbose iso8601 lets me specify that just in the date, without needing anything more.

14:00:05 <DanC> why does it help to be able to express it in fewer characters?

14:00:32 <DanC> you can certainly make up a property that has those semantics, but if there isn't widely deployed software that groks, it's not too interesting.

14:01:04 <JibberJim> because dates would be useful in RDF formats used primarily by people scared of RDF, (FOAF/RSS etc.)

14:01:53 <DanC> dc:date works just fine if you don't want any machines to grok.

14:02:37 <JibberJim> And as iso8601 does support it, I'm not sure why machines shouldn't - I'm not thinking specifically of iCalendar integration, but using rdfCalendar elsewhere.

14:03:09 <libby> wanna add it to agenda jibberjim?

14:03:15 <DanC> I'm not saying machines shouldn't. In fact, it's straightforward to write cwm rules to convert from jibberjim:fancyDate to rdfcal:uglyDate.

14:03:39 <DanC> but what's not straightforward is to get those cwm rules (or the equivalent) widely deployed in usable software.

14:04:56 <JibberJim> The use case that motivated this, was dates of events in the FOAF world, people want to give different info (some people don't want to give the year they were born, others don't want to give the actual date but want to give year)

14:05:24 * DanC likes the cyc vocab for such things

14:05:26 <JibberJim> those irregularities can be resolved if we simply say use an iso8601 calendar date, but currently that would mean a new vocab, that's all.

14:06:20 <DanC> I don't much care for compressing lots of complex semantics like that into a character-level syntax.

14:06:30 <_joshua> Hey DanC

14:06:42 <JibberJim> I was wondering if it could be integrated, you're probably right though that it would be too expensive in the icalendar world.

14:06:47 <DanC> I prefer to say it more directly: "I was born in 1967" => { :me cyc:startDate [ xsdt:year "1967"]}.

14:07:57 <DanC> or "I was born on December 9" = { :me cyc:startingDate ... hmm.. I forget how to say it's on the 9th day of december in some year

14:08:07 <_joshua> DanC, I had an idea I wanted to share with you. also some code for something unrelated.

14:08:19 <DanC> hi _joshua

14:08:21 <JibberJim> significant overhead then though for tools to compare mine and your ages, if I used :me foo:birthEvent year:1973-12-10 etc.

14:09:21 <DanC> significant overhead compared to what? are you claiming that calculations on iso8601 dates don't have a lot of overhead?

14:10:16 <JibberJim> They have an overhead handed off to an iso8601 lib, and not in understanding RDF vocabs.

14:12:12 <JibberJim> I want it to be possible to say it in RDF too, with the constrained date, just wondered if it was possible to integrate in this less constrained form too.

14:14:16 <DanC> Are you saying interoperable, complete iso8601 libs are easy to come by? I don't believe so.

14:15:41 <JibberJim> No, but I don't believe that the existence of fully working libs now should limit how we write our RDF vocabs.

14:20:34 <_joshua> are there any equivalents to CWM in java-land?

14:23:16 <DanC> yes, Euler is written in java

14:23:35 <DanC> and Andy Seaborn is working on some stuff... I think he has an N3 parser

14:24:15 <CaptSolo> hi all

14:26:21 <DanC> anybody know how to enter datetimes in gnumeric? (or excel?)

14:33:19 <DanC> found it. http://www.gnome.org/projects/gnumeric/doc/sect-data-format.html#number-format-date-examples

14:33:28 <DanC> 9/30/1998 18:07

14:33:33 <DanC> hmm... what about timezones?

15:23:26 <DanC> what timezone is Paxton, IL in?

15:23:48 <DanC> ah... Chicago time.

15:29:52 <Wack> ugh, http://www.w3.org/2001/XMLSchema#byte is -128 to 127 in lexical form, and #unsignedInt is 0 to 255

15:29:56 <Wack> err

15:30:01 <Wack> #unsignedByte

15:30:23 <DanC> what did you expect?

15:30:27 <Wack> really, why call it a byte

15:30:40 <DanC> because lots of other people call it byte

15:30:43 <Wack> well, I'm trying to map xmlschema types to corba typecodes

15:30:53 <wkearney> wkearney is now known as wkearney_away

15:31:07 <Wack> yes, but a byte in the typical sense is always unsigned

15:31:26 <ndw> I used to think that too, but I've encountered "signed bytes" in lots of places

15:31:30 <Wack> byte being an octal etc

15:31:50 <Wack> or erm an octet :]

15:41:30 <DanC> hmm... gnumeric doesn't do scatter charts?

15:43:10 <mortenf> how would i do sha1 in toIcal.py?

15:43:56 <DanC> ?

15:44:01 <DanC> why would you want to?

15:44:15 <mortenf> to get the x- properties converted into ics

15:44:18 <DanC> oh... for x-properties.

15:44:35 <DanC> er.. hang on... sha1 is for going the other way, no?

15:44:48 <mortenf> hmm, no, i need the namespace

15:44:54 <DanC> ?

15:45:01 <mortenf> to find the properties in that namespace

15:45:07 <mortenf> (if any)

15:45:11 <DanC> if you're going *from* RDF, you *have* the namespaces.

15:45:35 <mortenf> eh, well, i want to find only the properties in that namespace

15:45:45 <DanC> in what namespace?

15:45:53 <mortenf> the prodid derived one

15:45:57 <DanC> why?

15:46:26 <mortenf> how else would i export them?

15:46:37 <DanC> I don't expect you would.

15:46:59 <mortenf> well, that's what's keeping our tests from passing now...

15:47:01 <DanC> toIcal.py is its own "product".

15:47:23 <mortenf> hm...

15:47:24 <DanC> so take the x- properties out of the .rdf that you're starting with.

15:47:58 <mortenf> ok, but why did we "invent" a prodid namespace then?

15:48:09 <DanC> hmm... good point.

15:48:54 <DanC> are you in touch with George Huo, by the way? I gather he's made a bunch of progress on these tests.

15:49:07 * DanC should encourage him to report his progress to www-rdf-calendar

15:49:13 <mortenf> no, i haven't heard from him, and haven't tried contacting him either

15:49:38 <DanC> hmm... the docs that say gnumeric does scatter plots speak of v1.2, but I'm running 1.1.x

15:52:46 <DanC> but the download page says "gnumeric-1.1.19 is the latest development release"

15:59:37 <_joshua> DanC: what are you trying to do? Just dataset ->graph-> image file?

15:59:40 <_joshua> Try Ploticus instead

16:00:06 <DanC> well, it's nice to have direct-manipulation

16:00:38 <DanC> i.e. enter some data, look at the graph, edit the data, ...

16:00:49 <libby> .time

16:00:49 <datum> Wed, 20 Aug 2003 16:00:48 GMT

16:00:55 <libby> uhoh

16:01:04 * libby right back for calendar meet

16:01:04 <_joshua> Yes. Believe me. I spend my entire day dealing with datasets.

16:01:22 * DanC finds ploticus is supported by debian; looks cool

16:01:27 <_joshua> DanC: Keep it in a text file, ploticus to an output file, and xv the output. You're less likely to go insane.

16:02:08 <_joshua> gnuplot also but I have troubles.

16:02:23 <_joshua> there are better visualization packages for unix though.

16:02:33 <_joshua> Xgobi, scigraphica

16:02:59 <libby> everyone ready to talk about calendaring?

16:03:04 <mortenf> sure

16:03:13 <DanC> DanC has changed the topic to: Rdf Calendar ScheduledTopicChat http://rdfig.xmlhack.com/

16:03:19 <libby> -------calendar meet------

16:03:22 <libby> thanks danc

16:03:42 <DanC> D:[Dan Connolly|http://www.w3.org/People/Connolly/] attending

16:03:43 <dc_rdfig> Added comment D3.

16:03:48 <libby> for those not here for the calendar meet, we're scheduled to go for about 90 mins

16:04:07 * ndw plans to lurk again

16:04:10 <libby> D:[libby miller|http://ilrt.org/people/libby] attending

16:04:11 <dc_rdfig> Added comment D4.

16:04:11 <mortenf> D:[Morten|http://purl.org/net/morten/] attending

16:04:11 <dc_rdfig> Added comment D5.

16:04:46 <libby> the schedule is in http://dfig.xmlhack.com, as www-rdf-calendar isn;t working

16:05:08 <libby> E1:see [action libby|http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056556072.203619]

16:05:08 <dc_rdfig> Replaced comment E1.

16:05:24 <libby> ok...

16:05:31 <libby> calendar meet agenda item E: prodid schemas

16:05:39 <DanC> DanC has changed the topic to: Rdf Calendar ScheduledTopicChat 1600Z for 90min http://rdfig.xmlhack.com/

16:05:55 <libby> I havn;t done anything about my action here, sorry

16:06:03 <libby> did I see something about it in the logs?

16:06:26 <mortenf> well, remotely related...

16:06:48 <mortenf> as in, what should toIcal and ical2rdf do...

16:06:58 <libby> that wseems related...

16:07:11 <DanC> we know (er... well, we decided, anyway) what ical2rdf should do...

16:07:29 <mortenf> convert everything?

16:07:36 <libby> right, should it just chuck away x-props...

16:07:48 <libby> tricky

16:07:52 <libby> we culd do soem common ones

16:08:08 <DanC> are there any x- properties that we think are good ideas? I can't think of any

16:08:09 <mortenf> but then we wouldn't need the prodid specific namespaces

16:08:29 <libby> I guess this relates to mixing names[aces in ical which I was thinking about in relation to J: ids for events

16:08:44 <mortenf> i don't have a strong preference...

16:08:48 <libby> but only uin the other dirsction

16:09:08 <libby> sorry, not having looked at it properly yet, I don;t know

16:09:22 <libby> maybe continue the action, see what we get

16:09:40 <mortenf> the reason i brought it up, is that out test-cases won't match (atm)

16:09:46 <mortenf> s/out/our/

16:09:59 <libby> i.e. roundtripping

16:10:01 <libby> ?

16:10:03 <mortenf> yep

16:10:22 <DanC> D:see also [rdf-calendar list archive|http://lists.w3.org/Archives/Public/www-rdf-calendar/], [RdfCalendar wiki topic|http://esw.w3.org/topic/RdfCalendar] and [RDF Calendar Workspace|http://www.w3.org/2002/12/cal/]

16:10:23 <dc_rdfig> Added comment D6.

16:10:34 <DanC> for example, which test case, mortenf?

16:10:37 <libby> it'd be simple to write a utility for stripping out the x-props right?

16:10:43 <mortenf> e.g. mtg

16:11:03 <DanC> E:hmm... we agreed on a design for taking X- properties *into* RDF... but what about the other direction?

16:11:03 <dc_rdfig> Added comment E2.

16:11:10 <mortenf> or perhaps a switch/option for ical2rdf to make it drop them?

16:11:27 <mortenf> that'd be the easy for-now solution

16:11:51 <libby> whateever you think mortenf

16:11:53 <DanC> x:wrTimezone is hooey

16:12:28 <mortenf> i'd be fine with that, i've already hacked toIcal to preserver the prodid

16:12:29 <DanC> i.e. I'm fine with taking the x:wrTimezone hooey out of the mtg.rdf test data file.

16:12:44 <DanC> preserving the prodid seems questionable.

16:12:48 <mortenf> it was just an e.g. i suspect there are others...

16:12:54 <mortenf> yeah, perhaps

16:12:56 <DanC> i.e. toIcal should probably write out a prodid referring to itself

16:13:15 <DanC> I'm happy to look at others. I don't feel prepared to generalize.

16:13:21 <mortenf> sure, but what about the x- properties then

16:13:39 <mortenf> they'd have to be dropped

16:13:41 <DanC> I haven't seen any x-properties that I'm interested to support in toIcal.py yet

16:13:54 <mortenf> i was thinking a blind conversion

16:14:06 <DanC> but I'm not prepared to generalize and say "let's not support any x- properties in toIcal.py" until we've looked at more of them.

16:14:10 <mortenf> but that only makes sense if the prodid is preserved

16:14:26 <DanC> please *don't* think blind conversion. There lies madness.

16:14:48 <mortenf> quite possible, but what's the purpose of toIcal again :)

16:15:11 <DanC> toIcal knows the semantics of all the properties it deals with.

16:15:30 <DanC> its purpose is to syntactically export calendar data from RDF KBs to .ics format

16:15:50 <mortenf> ok, how about if i add that --drop-x option to ical2rdf and you look at x-props in general?

16:16:00 <DanC> the mtg.rdf file, as it is, is bogus. We shouldn't endorse it by keeping it in our test data.

16:16:17 <libby> th one in cal/test?

16:16:30 <DanC> yes, http://www.w3.org/2002/12/cal/test/mtg.rdf

16:16:45 <libby> because of the xprops

16:17:05 <DanC> oh! it used to lack a timezone declaration. I see it has one now. so it's not bogus any longer.

16:17:05 <libby> ok well those need egenerating then

16:17:20 <libby> <mortenf> ok, how about if i add that --drop-x option to ical2rdf and you look at x-props in general?

16:17:31 <libby> - "you" = me? danc?

16:17:38 <mortenf> anyone but me:)

16:17:42 <libby> heh

16:17:45 <DanC> why a --drop-x option?

16:17:55 <DanC> i.e. what's wrong with the way it works now?

16:17:55 <libby> at one stage I went through ading tz stuff to the tests

16:17:58 <mortenf> to make round-tripping testable

16:18:12 <DanC> round-tripping *is* testable if you start with no x-properties in your .rdf data.

16:18:29 <mortenf> ok, but quite a few of the tests do have x-props

16:18:39 <DanC> so let's fix those, one by one.

16:18:40 <libby> it might be more consistent to remove x-props from the ics files

16:18:50 <libby> shoudl be simple to fix w a perl script right?

16:19:00 <DanC> i.e. let's look at each one and see if there's any good reason for the x- property

16:19:01 <mortenf> ok, but then again: what's the point of prodid ns

16:19:23 <DanC> it's not clear that the prodid namespaces have any real value, that's true. But it's sorta sunk cost now.

16:19:29 <libby> well it might be useful for other reasons - for seeing what things app[s need not included in ics

16:19:47 <mortenf> so why remove them from the test data, if we might want to keep them later on?

16:20:03 <DanC> let's *look at each one*

16:20:18 <libby> ok

16:20:20 <libby> now?

16:20:23 <DanC> I *know for a fact* that the x:wrTimezone in mtg.rdf is bogus cuz I looked at it.

16:20:37 <DanC> now is OK by me. someday is too.

16:20:38 <mortenf> it's also in e.g. Chiefs

16:21:31 <libby> I think that might be a hangover from when we didn;t add tz to files manually if they were missing

16:22:05 <mortenf> ok, i'll just strip them pseudo-manually when testing for now

16:22:22 <DanC> anybody know if apple:iCal is willing to eat calendars that don't have x:wrTimezone in them? i.e. do we lose interoperability with apple:iCal if we delete X-Wr-Timezone from the .ics files?

16:22:59 <libby> I would think we do but not sure

16:23:17 <DanC> hmm... wrCalname could have some value... we could say it's a subproperty of dc:title

16:23:27 <libby> they are aware that the tz handling is an error, and promised to fix it, but that was a while ago and no new releases since

16:24:07 <libby> makes sense

16:24:47 <libby_> X-WR-ITIPSTATUSML - something to do with ITIP

16:25:24 <libby_> so that's something to do with scheduling

16:26:25 <libby> I'm seeing a lack of enthusiasm here

16:27:12 <mortenf> seems there are 6 diff:

16:27:32 <mortenf> X-EVOLUTION-ALARM-UID X-LIC-LOCATION X-WR-CALNAME;VALUE=TEXT X-WR-ITIPSTATUSML;VALUE=TEXT X-WR-RELCALID;VALUE=TEXT X-WR-TIMEZONE;VALUE=TEXT

16:27:40 <mortenf> in all .ics files

16:29:08 <libby> I think location is potentially interesting

16:29:52 <libby> tmezone is bogus

16:30:00 <libby> name might be reuseable

16:31:59 <mortenf> i don't know what the alarm is for (in cal01)

16:32:02 <libby> ok, I proposethat we leave this for now and return to it another time. any objections, comments?

16:32:16 <mortenf> np

16:32:56 <libby> morten, can you continue with what you wree doing ok?

16:33:15 <mortenf> yep, i'll strip on first conv from ics

16:33:29 <libby> ok cool

16:33:45 <libby> E:continued

16:33:46 <dc_rdfig> Added comment E3.

16:33:56 <libby> is it ok if I action you mortenf?

16:34:20 <mortenf> erh, i've already got the action on test, i don't know what to think of x-props

16:35:01 <mortenf> i still think we need a strategy though

16:35:22 <libby> I just meant the stripping out part

16:35:35 <mortenf> oh, sure, but i guess that's on the next item

16:35:44 * libby wonders if we should postpone the rest of this meeting....

16:35:57 <wkearney_away> wkearney_away is now known as wkearney99

16:36:02 <mortenf> did we lose danc?

16:36:20 <libby> maybe...issue as wellthat lack of mail at w3c

16:36:28 <libby> or possibly lack of interest... :)

16:36:41 * DanC wonders what I was expected to do that I didn't do

16:37:08 <libby> nothing, just say stuff

16:37:16 <DanC> er... stuff.

16:37:18 * bwm stuff

16:37:19 <mortenf> heh

16:37:23 <libby> :)

16:37:36 <mortenf> ok, let's move on then

16:37:38 <libby> moretn, do you want to say a bit about the regression tests?

16:37:42 <libby> cool

16:37:45 <libby> calendar meet agenda item F: regression tests for .ics->.rdf and vice-versa

16:37:52 <mortenf> sure.

16:37:54 * DanC tried phoning George about his testing progress; lost

16:38:16 <fsparv> can anyone explain this exception to me: Exception in thread "main" com.hp.hpl.jena.datatypes.DatatypeFormatException: 1 is not a Number

16:38:24 <fsparv> I sure thought 1 was a number :)

16:38:28 <mortenf> i've tried converting back and forth, got stuck on x-props and "wrong" prodid from toIcal, will be able to do more now

16:39:02 <mortenf> i plan to run through all tests, check for mismatches

16:39:24 <libby> so the aim is to be able to rondtrip between a certain set of tests or all the tests we have...?

16:39:24 <mortenf> one thing: the sequence from mtg.ics is not converted

16:39:28 <libby> ok, all tests

16:39:30 <mortenf> all?

16:39:40 <mortenf> yep

16:39:41 <libby> well the schema is generated from 3 I think

16:39:43 <libby> ok

16:39:51 <mortenf> at least that's what i'll try

16:40:00 <libby> we should be tryting to expand number of tests we use to generate that

16:40:02 <libby> cool

16:40:02 <MikeM> hehe.... Roy would be proud... all of our web services interfaces also have equivalent GET interfaces....

16:40:46 <mortenf> unless there are already comments on the sequence issue, i'll just continue

16:41:13 <mortenf> eor

16:41:17 <libby> I'm not sure we ever addressed it

16:41:25 <libby> go for it

16:41:44 <mortenf> F:continues...

16:41:44 <dc_rdfig> Added comment F2.

16:41:52 <libby> just as an asside, I noticed that the rdF ical schema doesn;t seem to use domain and range: http://sw1.ilrt.org/discovery/2003/08/validation/validate.jsp?schema=http%3A%2F%2Fwww.w3.org%2F2002%2F12%2Fcal%2Fical%23

16:42:03 <mortenf> heh

16:42:40 <DanC> doesn't it?

16:43:08 <DanC> i.e. where would you expect to see a domain or range that you don't see one?

16:43:18 <libby> hm

16:43:34 <libby> now I look, uses rangeIntersects

16:43:44 <libby> so maybe just showing a limitation of the tool

16:43:56 <DanC> no, rangeIntersects is different from range

16:44:09 <libby> yes, but it says something about range

16:44:22 <libby> I thought it said nothing

16:44:44 <DanC> i.e. if you see { :fido :eats [ a :Chicken] } you don't know that :eats only takes :Chickens as objects

16:45:19 <DanC> but you do know that :eats :rangeIntersects :Chicken

16:45:42 <DanC> as a human, you might be able to promote that to :eats :range :Food.

16:46:13 <libby> so can only ahve one domain in RDFS but multiple ranges?

16:46:33 <libby> .e. could someone extend the schema at any timew to include another range anyway? or a domain?

16:46:35 <DanC> you can have multiple ranges in RDF. but that means the object is in *all* those classes.

16:46:56 <libby> not any. ok

16:47:39 <libby> anyway, just something I noticed. thansk for clarification

16:47:43 <libby> move on?

16:47:45 * DanC lost my rdfig window...

16:48:47 <libby> calendar agenda item G: Interpretation properties and timezones

16:49:16 * DanC supposes he closed it after looking up George's phone number, not realizing other tabs in that window were still relevant to an ongoing task

16:49:20 <libby> this has been on the agenda a good while...I finally got around to writing a message to rdf-calendar (not rdf-interest)

16:49:36 <mortenf> and i tried to reply...

16:49:51 <libby> oh yep, not read that yet, hang on....

16:50:26 <DanC> hmm... reviewing that validator output, a few things do seem to be missing; e.g. { ical:prodid rdfs:domain ical:Vcalendar }

16:50:41 <DanC> I was gonna generate some stuff like that from the icalendar RFC

16:50:48 <libby> that'd be cool

16:51:20 <DanC> does rosco have a home?

16:51:49 <libby> yep here: http://sw1.ilrt.org/discovery/2003/08/validation/

16:51:55 <DanC>http://sw1.ilrt.org/discovery/2003/08/validation/

16:51:55 <dc_rdfig> I: http://sw1.ilrt.org/discovery/2003/08/validation/ from DanC

16:51:56 <libby> shoudl link to that somewhere.

16:52:09 <DanC> I:|Rosco - a non-judgemental RDF schema and document checker

16:52:09 <dc_rdfig> Titled item I.

16:52:14 <DanC> I:nifty!

16:52:15 <dc_rdfig> Added comment I1.

16:52:22 <libby> it's not particularly clever, but was something taht came up in foaf

16:52:27 <libby> ta :)

16:52:42 <DanC> I:e.g. [schema checker results|http://sw1.ilrt.org/discovery/2003/08/validation/validate.jsp?schema=http%3A%2F%2Fwww.w3.org%2F2002%2F12%2Fcal%2Fical%23] for the RDF calendar schema

16:52:43 <dc_rdfig> Added comment I2.

16:52:55 <JimJibber> JimJibber is now known as JibberJim

16:53:17 <DanC> back to interpretation properties and timezones...

16:53:21 <libby> I:there are a few bugs - it fails stupdly if the xml/RDF is invalid

16:53:22 <dc_rdfig> Added comment I3.

16:53:53 <libby> yep, I would tend to agree with morten's mail I think: http://www.wasab.dk/morten/2003/08/cal/ip.txt

16:54:22 <libby> I'm not that keen on datatypes, but we certainly could do

16:54:43 <DanC> I dont' see how what ip.txt proposes is interestingly different from what we have.

16:54:44 <mortenf> but as stated, i'm not sure about the implications, and subdatatyping isn't really possible...

16:54:55 <libby> I'd like to have tz as a uri too

16:55:19 <mortenf> just a thought, i'd like it as well, if it was possible to say something about the tz

16:55:35 <libby> well DanC it stops the merging nastiness right? http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Aug/0002.html

16:55:55 <libby> (I'm not sure I've interpretted it right as XML/RDF from http://esw.w3.org/topic/InterpretationProperties

16:55:57 <libby> )

16:56:09 <DanC> no, it doesn't stop the nastiness.

16:56:14 <libby> no?

16:56:16 <DanC> no

16:57:06 <mortenf> ideally, we'd have to have a prpoerty for each timezone...

16:57:12 <libby> because if we say the datetime objects are the same we have the same issue?

16:57:17 <DanC> right.

16:57:54 <DanC> i.e. there's nothing wrong with the existing ical schema as long as people realize that 2pm central != 3pm Eastern. But that's *very* fragile.

16:57:58 <libby> but this way at least we could have 2 dtstarts from different timeszones

16:58:29 <DanC> we *want* to say that the meeting is at time X, where X is 2pm in Chicago and 3pm in New York.

16:58:38 <DanC> that is: that's the way people normally talk.

16:59:04 <mortenf> but is this expressable in owl?

16:59:09 <libby> right I guess the other way sort implies that they could be different times, i.e. not syncronised

16:59:28 <DanC> owl doesn't have multi-column keys, no.

17:00:02 <DanC> yes, you can think of them as not synchonized. But that seems... I dunno, silly and counterproductive.

17:00:26 <DanC> I'm conflicted...

17:00:59 <DanC> I know what my preferred model of timezones is, but it's not at all clear that iCalendar agrees with me. And the semantics of our namespace are the semantics of iCal, not some semantics we may prefer.

17:01:12 <libby> hm

17:01:25 <libby> what would your prefered model look like?

17:02:02 <DanC> :event :dtStart [ chicago:tz "14:00"; newYork:tz "15:00"].

17:02:43 <mortenf> how the other way around; tz:newYork?

17:03:08 <DanC> where @prefix chicago: <http://www.w3.org/2002/12/cal/tzd/America/Chicago#>.

17:03:44 <mortenf> with tz:*, it'd be possible to have a controlled vocabulary

17:03:44 <DanC> that's another issue, mortenf. You end up with all the timezone definitions in one file, which is sort of a pain.

17:03:54 <mortenf> true

17:04:07 <libby> but your way around would be difficult to query danc....

17:04:17 <DanC> with chicago:tz, it's not only possible to have a controlled vocabulary, that vocabulary exists today: http://www.w3.org/2002/12/cal/#tzd

17:04:56 <DanC> difficult how so, libby? gimme an example query that's easy with the existing schema and hard with mine?

17:05:31 <DanC> you don't really want to query for "2pm in some timezone" do you?

17:06:34 * libby will have to think, but I've comonly grabbled all the dtstarts/dateTimes and also their timezones

17:07:26 <libby> you could still ake queries of that sort but would have to do a partial match on the property which (in implementation experience) slows things down

17:07:29 <libby> I think

17:07:41 <libby> butthere's stuff you culd do, e.g. normalize it all

17:07:41 <DanC> "partial match on the property"? what do you mean by that?

17:07:56 <DanC> can you give me an example query?

17:08:16 <libby> well you could query with the property as a varaibal, or in some languages do a substring match on the property name

17:08:38 <mortenf> on ns only?

17:08:47 <libby> yeah maybe

17:09:02 <libby> it's perhaps not so important

17:09:39 <mortenf> so we're stuck with the ical model?

17:09:57 <DanC> stuck?

17:10:05 <libby> (?event ical:dtstart ?dt) (?dt ical:dateTime ?value) would work currently

17:10:41 <DanC> isn't querying with the property as a variable supported in all the RDF query systems?

17:11:21 <DanC> change that to (?event ical:dtstart ?when) (?when ?tz ?value) (?tz rdf:type tz:TimeZone).

17:11:49 <libby> yep I would guess suppported in many; just an imlementation observation that probbaly slower

17:11:58 <libby> I'm not sure thatthat shoudl stop us

17:12:44 <mortenf> <DanC> I know what my preferred model of timezones is, but it's not at all clear that iCalendar agrees with me. And the semantics of our namespace are the semantics of iCal, not some semantics we may prefer.

17:13:40 <libby> I'm not sre that that really matters moortenf, as we've been working out the semnatics of whats really a syntactic format ourselves

17:13:54 <libby> as long as we get the essesnce of what icalendar seems to mean....

17:14:18 <libby> where it's possible to tell what that is

17:14:28 <mortenf> so it would be possible for us to model the data/time as danc showed?

17:14:35 <DanC> that's the question.

17:14:41 <DanC> some issues:

17:14:59 <libby> I'd say, not impossible :)

17:15:14 <DanC> (1) icalendar files don't use global names for timezones. so picking a URI from our controlled vocabularly would be tedious, typically, and implossible in some cases

17:15:54 <DanC> (you can always make up a local property name, and add a :genProp rdf:type :Timezone triple, but I wonder about round-tripping that...

17:15:55 <DanC> )

17:16:57 <DanC> (2) icalendar uses the same syntax for recurring times and non-recurring times. 2pm in Chicago every tuesday doesn't correlate to *any* particular recurring time in Paris.

17:17:18 <DanC> (maybe that's a non-issue)

17:18:54 <mortenf> i think 2 is ok

17:19:13 <mortenf> and re 1, it seems tz's in ical are identified by the olson ones?

17:19:36 <mortenf> hmm, except for when it's ...Z

17:19:49 <DanC> here's where I am: (a) I'm uncomfortable with the way our RDF timezone properties work, and I suspect applying the InterpretationProperties pattern would help, but (b) I'm able to get work done with the status quo, and (c) I haven't found sufficient motivation to design and implement something better

17:20:45 <mortenf> one reason for changing to ips would be that others look at this case re this exact issue

17:20:46 <DanC> typical ical practice uses the olson names. but the ical spec allows totally arbitrary timezone definitions, like "it's -0500 on tuesdays, and +300 from 2004 to 2005, then back to -0600 except on Thursdays"

17:20:57 <mortenf> ouch

17:21:12 <libby> right cos it's supposed to be defined in the file right

17:23:29 <libby> hm

17:23:38 * mortenf is reading rdf2445

17:24:09 <libby> given limited effort available to do this work, I wonder if the status quo might be the best thing to do

17:26:29 <libby> it seems to me that if we can work with it, it might be better declaring the vocab 'finished' and moving on to more interesting things, rather than starting another big job

17:26:35 <libby> that's just my feeling

17:27:57 <libby> any other thoughts?

17:28:12 <mortenf> wouldn't it be possible to use Z or Olson when present, otherwise define a "local" type, by the VTIMEZONE info?

17:28:38 <libby> sounds lausible

17:28:43 <libby> plausible even

17:29:01 <libby> .time

17:29:01 <datum> Wed, 20 Aug 2003 17:29:01 GMT

17:29:15 <libby> ok, actually my clock's wrong, and it's later than I thought

17:29:25 <libby> we should be wonding up at this stage

17:29:38 <mortenf> not that it'd be easy converting, but...

17:30:08 <libby> mortenf, you seem to care....do you have an apps which won't work with the current system?

17:30:18 <mortenf> no, just gut feelings...

17:30:27 <libby> that we'll regret it later?

17:30:35 <mortenf> perhaps

17:31:07 <mortenf> i'm actually quite in aggreement with danc, except that i think now's the time for a change

17:31:25 <libby> well, given that we're out of time, I'm happy to action myself to try and start a conversation about this on the mailing list (whan it's up). think that would help?

17:31:36 <libby> it's unclear how to resolve this to me.

17:31:37 <mortenf> sure

17:31:40 <mortenf> yep

17:32:10 <libby> given that there are only really three of us active here....but I get a fair few requests for help and advice with using the vocab, i'd prefer to get it finished...

17:32:16 <libby> ok, I'll do that

17:32:31 <mortenf> fair enough

17:33:00 <libby> G:ACTION libby summarise this discussion and send to www-rdf-interest

17:33:00 <dc_rdfig> Added comment G3.

17:33:24 <libby> I just mean, I think it's probably not enough energy to make the change!

17:33:34 <libby> s/it's/there's/

17:33:48 <libby> might be better to note the issue and write it all up.

17:34:00 <libby> so...anyone want to meet again?

17:34:03 <mortenf> got it, but if it's mainly a question of the converter programs...

17:34:22 <mortenf> hmmm...

17:34:54 <mortenf> we still go item H as well

17:35:02 <libby> well, if you fancy writing it up as a followup, then that'd be cool, i.e. flesh it all out, maybe show how converter would work....

17:35:12 <mortenf> ok

17:35:32 <libby> don't feel you ahvto :)

17:35:40 <mortenf> np :)

17:35:46 <libby> re H - what do you think?

17:36:20 <mortenf> i think a uuid based on seems the way to go, whether it be a uri or an ifp

17:36:39 <libby> what makes you say that?

17:36:50 <mortenf> they are already there in some cases

17:36:51 <libby> consistency with RFC 2445?

17:36:55 <libby> ok

17:37:05 <swh> swh is now known as swh_away

17:37:05 <mortenf> yep

17:37:19 <DanC> I don't really understand the motivation for H. Yes, it's nice when things have established URIs, but it's hard to establish them when their owners aren't interested.

17:37:36 <mortenf> which is why a uuid based ifp may be better

17:37:55 <DanC> icalendar requires that events have uids; do you need something other than that, libby? what for?

17:38:19 <libby> uuid would be fine I think

17:38:22 * MikeM hopes to have the UUID uri document updated by the end of the month... (co-author is on vacation)

17:38:28 <libby> better if an inverseFunctionalProperty

17:38:40 <libby> cool MikeM

17:39:02 <MikeM> the code in the appendix is wrong and _lots_ of folks were cutting and pasting it directly into their code (ick!)

17:39:08 <DanC> I'm not sure whether ical:uid is an owl:InverseFunctionalProperty or not...

17:39:09 <libby> ouch

17:39:26 <libby> well, I guess that's what I'm asking

17:39:38 <mortenf> in rfc 2445 it says: This property defines the persistent, globallyunique identifier for the calendar componen

17:39:51 <libby> right

17:39:52 <DanC> consider: in my calendar, { :e1 ical:uid "...73"; ical:summary "I hate this meeting; it's so dull." }

17:40:17 <libby> what I'm inetersted in is the case where 2 people define the same event in their own calendars, and want to say, this is the same event

17:40:24 <DanC> in Fred's calendar: { :e2 ical:uid "...73"; ical:summary "best meeting of the week" }

17:40:45 <mortenf> but you're talking about the same meeting, so it's still right

17:41:14 <DanC> if ical:uid is an owl:InverseFunctionalProperty, then we conclude :e1 = :e2 and :e1 ical:summary "best meeting of the week", "I hat this meeting; it's so dull".

17:41:23 <DanC> (if we merge the calendars)

17:41:32 <mortenf> so you don't want events to have ids at all?

17:42:03 * DanC doesn't grok the question

17:42:11 <libby> so it loses the provenance of each statement?

17:42:17 <mortenf> it seems it the basic issue of provenance etc.

17:42:24 <DanC> no, provenance is orthogonal.

17:42:46 <DanC> The question is: do we mean for the subjects of those two ical:summary statements to be the same thing?

17:42:59 <mortenf> hence my question...

17:43:06 <DanC> i.e. is it one event, described in two calendars, or are they separate event-things?

17:43:11 <libby> perhas you mean: event identify conditions are very tricky indeed, better not touch them with a bargepole?

17:43:25 <DanC> no

17:43:29 <danbri> subjects in the rdf:subject sense, ie. things not terms...

17:43:44 <libby> I think it's very useful to say, x and I went to the same event. but maybe better to say it outside of icalendar itself

17:43:56 <DanC> why better?

17:44:19 <libby> because then we could use foaf:homepage, as danbri suggested

17:44:37 <libby> though not sure that makes a great eal of difference, cos that's an inversefunctionalrpoperty too

17:44:53 * danbri would prefer see identity rules inside the cal vocab, but hasn't given it enough thought yet

17:45:34 <libby> I'm not sure ho mcuh it matters....but people do what to do this, say that events are the same thing, e1=e2

17:45:39 * mortenf still hasn't grasped danc's position

17:45:43 <DanC> summary is sorta fuzzy... but consider alarm properties.

17:46:55 <DanC> when, in my calendar, it says { :e1 ical:uid "...81"; ical:alarm [ :hoursBefore "2"] } and in your calendar it says { :e2 ical:uid "...81"; ical:alarm [:minutesBefore "5"]}...

17:47:09 <DanC> ... does it make sense to say that we were both setting alarms on the same event?

17:47:38 <DanC> I go back and forth. Maybe it does.

17:47:47 <mortenf> ok, good point, i wouldn't want an alarm for every participant...

17:48:15 <libby> would it make any diference to you DanC if the events were merged using a non-ical ns...? guess not...

17:48:26 <mortenf> so, it seems that an owl/rdf identifier of sorts is not desired

17:49:03 <libby> kind of annoying, but I can see the logic

17:49:23 * libby has to go home shortly, and we're out of time

17:49:43 <libby> wanna try meeting up again guys?

17:49:53 <mortenf> sure

17:50:23 <libby> ok

17:50:56 <libby> my september's a bit iffy at the moment

17:50:58 <DanC> "not desired"? by whom?

17:51:06 <mortenf> you?

17:51:10 <mortenf> me?

17:51:14 <libby> heh

17:51:29 <libby> well, sometimes bad stuf will happen if they are merged

17:51:54 * DanC has not rendered an opinion, has carefully avoided "good", "bad" and such terms

17:51:56 <mortenf> perhaps a super-event could be modelled

17:52:05 * mortenf had noticed that...

17:52:11 <libby> I guess this is how say apple ical models different calendars

17:52:23 <libby> I wonder if they use uuid

17:52:39 <libby> I'd say 10 alarms going off was pretty bad

17:53:21 <libby> mortenf, I can probably do 3rd, 10th...17th...

17:53:24 <libby> sept

17:53:43 <mortenf> 3, 10 fine, 17 not

17:54:31 <libby> 10th?

17:54:47 <mortenf> ok with me

17:54:59 <libby> cool

17:56:11 <libby> anyone object?

17:56:12 * DanC abstains

17:56:12 <libby> well, ok, we'll do that mortenf

17:56:19 <mortenf> ok

17:56:54 <libby> I'll contact you beforehand, make sure we have something to chat about :)

17:58:27 <libby> D:next meeting [http://www.timeanddate.com/worldclock/fixedtime.html?day=10&month=9&year=2003&hour=16&min=0&sec=0&p1=0|2003-09-10, 16-00UTC (provisional)]

17:58:27 <dc_rdfig> Added comment D7.

17:58:43 <libby> thanks everyone, interesting stuff

17:58:59 <DanC> depressing incoming mail stats for this year: [[

17:59:02 <DanC> 23104 connolly/Mail-IMAP/0spam-filtered

17:59:02 <DanC> 11812 /var/spool/mail/connolly

17:59:02 <DanC> 9590 connolly/Mail-IMAP/0inbox-procmail

17:59:02 <DanC> 8017 connolly/Mail/mbox/spamchars

17:59:02 <DanC> 7972 connolly/Mail-IMAP/0unknown-sender

17:59:02 <DanC> 3532 formail

17:59:04 <DanC> 2581 connolly/Mail/mbox/spamcjk

17:59:06 <DanC> 1379 connolly/Mail-IMAP/0unk-tome

17:59:08 <DanC> ]]

17:59:20 <libby> would someone mind canging back the topic?

17:59:31 <DanC> (var/spool and 0inbox-procmail both mean the same thing, pretty much)

17:59:44 <DanC> DanC has changed the topic to: Semantic Web hack-n-chat http://rdfig.xmlhack.com/

17:59:52 <libby> ta

18:03:05 Topic now Semantic Web hack-n-chat http://rdfig.xmlhack.com/

18:03:05 Users on #rdfig: logger_2 ndw bijan Morbus niq dajobe arnarl_ aharth JibberJim shellac golbeck darobin_ Cardinal chrisc karlcow mhgrove AaronSw grove_ burtonator gromgull wkearney99 das deusx mortenf libby iwaim swh_away arnarl nmg WIKON GNUWookie hendry bitsko MikeM Oblomov Mutiny fsparv xover chrisc_work dc_rdfig ericP tansaku_ collord Wack danbri hooch kham CaptSolo apluc_aem DanC-AIM tav|offline xower deltab grove GabeW eikeon dje eikco MarkB sbp DanC

18:03:05 Users on #rdfig: dngor grault zool lasse _joshua sandro merriam skimpIzu datum

18:03:06 <ChanServ> [#rdfig] This channel is logged and blogged: http://logicerror.com/rdfIRCWelcome

18:04:22 <DanC> if these were credit card fraud rates, Visa would be in trouble.

18:04:28 <MikeM> The thing that scares me is that some companies are so willing to stop spam that they're willing to break the ubiquity of SMTP...

18:04:56 <Cardinal> Which isn't a solution.. It's not like spammers can't adapt to new protocols.

18:05:08 <DanC> er... the ubiquity of SMTP *is* broken. My email inbox is no longer a reliable way to reach me.

18:05:51 <sandro> ready for secure whitelisting + special exception mechanism? :-?

18:06:05 <MikeM> cardinal, but would you like the alternative to be that you can't send mail to anyone at microsoft without running microsoft's proprietary mail application?

18:06:14 <DanC> I was talking with Boyer, a c.s. prof at U.T. ... he wanted to email a snipped of code to a colleague. Couldn't do it. incoming mail filters blocked it.

18:06:23 <DanC> (incoming at the colleague's org)

18:06:48 <ndw> sigh.

18:07:09 <MikeM> that's currently what's being proposed in certain circles: Microsoft and a few others will go off and develop their own version of SMTP that you can't get documentation for unless you sign their EULA....

18:07:26 <ndw> This particular round of the .pif virus is the worst I've seen. I'm getting hundreds a day, and at 100k each they're too big even with broadband access.

18:07:54 <ndw> No mail to or from MS clients. That'd be...bad, right?

18:08:05 <libby> yeah...maybe 1 out of 20 mails 'real' for me

18:08:37 <libby> today

18:08:42 <MikeM> ndw, that would be fine if they didn't take my my entire family with them.

18:09:23 <ndw> Yeah. I guess it would be bad. But it'd be bad in so many ways.

18:09:44 <DanC> an idea occurred to me the other day: backbone guys stop sending packets on port 25 except from registered IP addresses. To register your IP address, you send a self-addressed, stamped envelope to the gods.

18:10:01 <Cardinal> Eureka!

18:10:13 <apluc_aem> apluc_aem is now known as edtivrsky

18:10:26 <ndw> Who sends the letter, Charter.net for all the addresses the DHCP, or me for the one I get randomly assigned?

18:10:29 <edtivrsky> edtivrsky is now known as EdTivrsky

18:10:36 <ndw> (Although it's been very nearly static in practice)

18:10:43 <DanC> (well, 1st you get a random number from mail-gods.org, send it to them by post; they send another one back to you, and you enter that via http again)

18:10:49 <MikeM> Dan, that's essentially one of hte idea: you only do mail acceptance when you can setup an SSL session between you and the sendeing MTA. That way you can verify who it is from....

18:10:59 <_joshua> DanC: What about callbacks? You recieve mail from x@y.com; you callback y.com and say "did x@y.com really send mail to me@my.com?" and they can say "Yes, I don't know, No" or whatever

18:11:30 * ndw runs off to test something that requires bringing X all the way down...

18:11:45 <_joshua> if y.com is a faked, y.com will say no. if y.com is a spammer, you make up a domain name and ask about it. "Did you send email to foo@bar.com?" and if they say YES you know they are lying and are a spammer.

18:12:27 <DanC> I'd prefer a p2p system, but I have a *large* number of email peers, and I'm not sure I wanna wait for all of them to get with some new system.

18:12:34 <MikeM> anyone seen eric miller lately

18:12:40 <_joshua> Gotta start somewhere

18:12:45 * DanC was in contact with miller yesterday

18:12:47 * Morbus comes in late.

18:12:58 <Morbus> i can't stand "email me back 'yes' to confirm you want me to read your mail' systems.

18:13:07 <_joshua> callbacks could be implemented without smtp support, which is also ap lus

18:13:07 <Morbus> don't make your spam problems MY problems too.

18:13:23 <_joshua> Morbus: I am not talking about making humans do things

18:13:33 <MikeM> thanks, dan...

18:14:49 <DanC> I find it pretty ironic that the Internet Mail Consortium is sorta fading into obscurity as spam is becoming the net's biggest problem.

18:15:22 <MikeM> Its fading simply because Paul didn't want to do it anymore... IMC was always just Paul

18:15:38 <DanC> so I gather.

18:16:09 <DanC> the IRTF spam group seems to be doing some interesting stuff

18:16:52 <DanC> we gotta get that low-tech anti-forgery stuff DNS stuff deployed right quick.

18:17:01 <MikeM> now all his time is taken up by internationalization issues...

18:18:11 <MikeM> you mean DNSSEC?

18:18:17 <_joshua> Hmm!

18:18:24 <DanC> no, DNSSEC is not low-tech...

18:18:37 <DanC> I mean http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt

18:18:39 <_joshua> Why not stash a public key in a TXT record for a domain, and then everyone who wants to send mail from that domain signs with the private key?

18:19:02 <_joshua> taht's the MF header, right?

18:19:10 <DanC> a shared private key? heh.

18:20:02 <_joshua> Well, I could have my smtp server sign things on the way otu with the right key.

18:20:07 <_joshua> Why is a shared private key so terrible?

18:21:07 <_joshua> oh damnit i forgot to buy that from amazon

18:21:39 <_joshua> oops

18:21:56 <DanC> C:[RMX records|http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt] please!

18:21:57 <dc_rdfig> Added comment C2.

18:22:08 <_joshua> yes, RMX. Sorry. I think of it as "mail from"

18:22:31 * DanC gets a call back from George H., encourages him to commit/announce his work on tests

18:22:53 <DanC> didja win, ndw?

18:26:08 <DanC> shared private keys are terrible because the odds of keeping a secret go down with the square of the number of parties to the secret

18:26:37 Topic now Semantic Web hack-n-chat http://rdfig.xmlhack.com/

18:26:37 Users on #rdfig: logger ndw bijan niq dajobe arnarl_ aharth JibberJim shellac golbeck darobin_ Cardinal chrisc karlcow mhgrove AaronSw grove_ burtonator gromgull wkearney99 das deusx mortenf iwaim swh_away arnarl nmg WIKON GNUWookie hendry bitsko MikeM Oblomov Mutiny fsparv xover chrisc_work dc_rdfig ericP tansaku_ collord Wack danbri hooch kham CaptSolo EdTivrsky datum skimpIzu merriam sandro _joshua lasse zool DanC-AIM tav|offline xower deltab grove GabeW

18:26:37 Users on #rdfig: eikeon dje eikco MarkB sbp DanC dngor grault

18:26:38 <NickServ> This nickname is owned by someone else

18:26:38 <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>

18:26:38 <NickServ> Password accepted - you are now recognized

18:26:38 <MemoServ> You have no new memos

18:26:38 <ChanServ> [#rdfig] This channel is logged and blogged: http://logicerror.com/rdfIRCWelcome

18:38:12 * ndw loses

18:38:52 * ndw is trying to run AcceleratedX with old libc while upgrading the rest of his machine to new libc.

18:39:10 <DanC> ew

18:39:47 <ndw> I'm open to suggestions. I want to upgrade so I can get newer gnome libs and stuff

18:40:29 <DanC> I don't have any. as I recall, you're a prisoner of the hardware you acquired.

18:40:45 <ndw> Yes. And the new PowerBooks are rumored to come out this week.

18:41:19 <GNUWookie> hi all

19:04:37 <dajobe> danbri: the librdf-ruby debian package is there now

19:06:05 <danbri> excellent, thanks :):)

19:06:22 <danbri> are you Debianizing both Redland and Raptor?

19:06:35 <dajobe> raptor's done and in debian sid/unstable already

19:06:46 <dajobe> now redland's getting there

19:07:19 <dajobe> I mean, the packaging is coming together for redland. It's not in Debian itself.

19:07:53 <danbri> apt-get install libraptor0 libraptor0-dev

19:07:53 <danbri> Reading Package Lists... Done

19:07:53 <danbri> Building Dependency Tree... Done

19:07:53 <danbri> The following extra packages will be installed:

19:07:53 <danbri> libc6 libc6-dev libcurl2 libcurl2-dev locales

19:08:01 <danbri> hmm :)

19:08:02 <dajobe> something must have changed for ruby 1.8, the example doesn't work

19:08:14 <danbri> what's the error msg?

19:08:22 <dajobe> in `librdf_new_parser': cannot convert nil into String (TypeError)

19:08:38 <dajobe> line: parser=Redland::librdf_new_parser world, parser_name, "", nil

19:08:39 <danbri> is unstable doing a libc upgrade, or is there some special dependency you have?

19:08:46 <dajobe> libc: yes there is

19:08:51 <dajobe> and I'm on the latest, likely

19:10:00 * danbri ponders risks of allowing libc6 upgrade

19:10:27 <dajobe> edd's had some trouble with NIS services on ppc, but I've found it ok

19:11:15 * DanC confirms debian libc upgrade ok

19:14:39 * danbri apt-gets a few hundred meg of other people's hard work

19:14:47 <danbri> amazing really...

19:19:06 * ndw is feeling amazing pain after libc6 upgrade because of...unfortunate hardware choices

19:34:38 <GNUWookie> CaptSolo: Hey!

19:35:08 * ndw chuckles at Capt Solo and a Wookie.

19:36:18 * GNUWookie gives ndw a big wookie hug

19:36:29 <GNUWookie> it is all CaptSolos fault

19:36:48 <fsparv> Is there a channel dedicated to Jena, or jena 2?

19:36:53 <ndw> Don't break anything there, GNUWookie, please

19:37:07 <GNUWookie> heheh

19:37:25 <GNUWookie> hey ndw, you work at sun?

19:37:40 <danbri> roll on irc-videoconferencing...

19:38:02 <ndw> That's what it says on my paystub :-)

19:38:17 * ndw works from home most of the time :-)

19:38:24 * danbri too

19:39:13 <ndw> Why do you as, GNUWookie?

19:40:13 <GNUWookie> cause your name. I wrote to sun on getting the source code for ipcs

19:40:22 <GNUWookie> i wanted to know what syscalls are used

19:40:29 <GNUWookie> but truss did the trick as well

19:40:58 <ndw> Glad you found a solution

19:41:28 <GNUWookie> yeah, it is pretty cool, sun has an api call.

19:41:37 <GNUWookie> truss is soo much fun to play with

19:43:28 <GNUWookie> http://www.microsystems.com/Shares_Well.htm

19:43:28 <dc_rdfig> J: http://www.microsystems.com/Shares_Well.htm from GNUWookie

19:43:46 <GNUWookie> J:|Nice article that defines metadata in terms of MSWord

19:43:47 <dc_rdfig> Titled item J.

19:44:07 <GNUWookie>http://advogato.org/person/mdupont/diary.html?start=11

19:44:07 <dc_rdfig> K: http://advogato.org/person/mdupont/diary.html?start=11 from GNUWookie

19:44:35 <GNUWookie> K:|Advogato Hack to allow you to customize your relationship to a project

19:44:36 <dc_rdfig> Titled item K.

20:45:16 <karlcow>http://www.w3.org/QA/2003/08/rdf-reloaded

20:45:16 <dc_rdfig> L: http://www.w3.org/QA/2003/08/rdf-reloaded from karlcow

20:45:28 <karlcow> L:|Why the QA Matrix in RDF?

20:45:28 <dc_rdfig> Titled item L.

20:45:38 <karlcow> L:Or why RDF has made our life easier.

20:45:38 <dc_rdfig> Added comment L1.

20:51:09 <sbp> ooh. Gill Sans

20:52:48 <karlcow> sbp? :)

20:53:47 <JibberJim> sbp's a font spotter karlcow

20:53:48 <sbp> sorry. the combination of a missive on RDF's practical use and a page set in Gill Sans is overwhelming

20:54:03 <karlcow> ah ok :) lol

20:54:30 <karlcow> happy you like it :) (if you like it)

20:55:01 <sbp> still going through it, looks very good

20:55:33 <karlcow> comments are welcome. My frenglish is always a bit broken.

20:55:33 <ndw> Who's got a page in Gill Sans?

20:55:39 <sbp> you converted the XML to N3 by hand?

20:55:46 <sbp> Norm: see L, above

20:55:52 <karlcow> sbp, with an XSLT

20:56:14 <sbp> good. is the XSLT linked?

20:56:48 <karlcow> hmmm :) not from this document.

20:57:05 <karlcow> I will try to find it :)

20:57:14 <sbp> cheers

21:01:30 <ndw> ndw is now known as ndw^busy

21:08:16 * DanC tries to figure out how to iterate over distinct values of gmr:Cell/@row

21:12:56 <karlcow> Sean: The first time to put it in RDF we have used http://www.w3.org/QA/2002/06/MatriXmltoRdf.xsl

21:13:26 <karlcow> L: [http://www.w3.org/QA/2002/06/MatriXmltoRdf.xsl| first XSLT used to start the rdf version from the xml]

21:13:26 <dc_rdfig> Added comment L2.

21:17:11 <sbp> ah. XML =XSLT=> RDF/XML =CWM=> N3, I presume?

21:17:23 * sbp wonders how much harder it'd be to output straight to N3 using xsl:text

21:17:25 <DanC> compacity isn't a (traditional, widely-deployed) english word. try compactness.

21:18:01 <sbp> .googlecount compacity

21:18:02 <datum> compacity: 1,920

21:18:06 <sbp> .googlecount compactness

21:18:07 <datum> compactness: 136,000

21:18:34 <karlcow> yes sbp :)

21:18:59 <DanC> using xsl:text you'd have to do all the character-level quoting. ugh.

21:19:12 <sbp> good point

21:19:15 <DanC> hmm... this seems to seel N3 as much as RDF

21:19:16 <karlcow> I never tried to create an xslt to transform a file from xml to n3 :)

21:19:22 <DanC> s/seel/sell/

21:19:41 <karlcow> DanC it sells the RDF model :)

21:19:45 <karlcow> and the n3 syntax

21:19:47 <DanC> does the N3 ever get converted to RDF/XML?

21:19:58 <DanC> you might show a snippet of that.

21:20:18 <DanC> hmm... 404 @ http://www.w3.org/2002/06/TheMatrix-manual

21:20:19 <karlcow> DanC read the doc :p it's written in the introduction

21:20:28 <DanC> I read the doc.

21:20:47 <DanC> I don't see any snippets of RDF/XML

21:20:48 <karlcow> ahhh :D good you found a bug :)

21:21:21 <karlcow>http://www.w3.org/QA/2002/06/TheMatrix-manual

21:21:21 <dc_rdfig> M: http://www.w3.org/QA/2002/06/TheMatrix-manual from karlcow

21:21:39 <karlcow> M:| The technical version of the previous article

21:21:39 <dc_rdfig> Titled item M.

21:21:56 <JimJibber> JimJibber is now known as JibberJim

21:22:21 <karlcow> DanC: the article has been written to convince people who doesn't know RDF/n3 to show them the benefits.

21:22:48 <karlcow> Not the high techies ;) like you who will learn almost nothing with my article :)

21:22:50 <DanC> so I gather. But do you really want to sell the N3 syntax? That's not a W3C Recommended technology.

21:23:28 <DanC> I prefer to see N3 positioned as a poor-man's editing tool for RDF/XML. perhaps make the point that you can edit the knowledgebase with IsaViz and the like, if you choose.

21:23:54 <karlcow> one of the point of the article, is that writing xml by hands is painful (RDF syntax is xml and for me as much painful as XML)

21:24:53 <DanC> but that's not an argument for RDF. there are just as many quick-and-dirty converters from other text formats to XML as there are from N3 to RDF/XML.

21:26:08 <karlcow> It's one of the argument in the document for easier management. Some are RDF, some are maintaining by hands. :)

21:27:29 <karlcow> thanks DanC I have fixed the link

21:27:50 <DanC> So is this the argument? "XML is hard to edit by hand. So I'll make my own non-standard data format and manage my data in that format."

21:28:12 <karlcow> I will try to use isaviz to see how it helps with the interface.

21:28:29 <mortenf> are there that many tools that read N3? I know of cwm only (RDF::Notation3 doesn't work)?

21:28:37 <karlcow> one of the argument is that RDF model is good and it's not tied to the syntax

21:28:59 <DanC> do you keep the .rdf version of your .n3 stuff in CVS? I hope so. You don't want to have your source data locked up in .n3 any more than any other non-standard/proprietary format.

21:29:06 <sbp> I've written one full N3 parser, but the syntax moves so swiftly and subtly that it's pointless in trying to keep up

21:29:27 <DanC> it's news to me that RDF:Notation3 doesn't work

21:29:29 <mortenf> does it have lang and datatypes?

21:29:40 <mortenf> it barfs at anything, including long literals

21:29:45 <sbp> N3? notation3.py doesn't support them, that I know of

21:30:05 <sbp> which is what one really means when asking if something is in N3...

21:30:14 <DanC> I think notation3.py groks "str"^^datatypeURI ... I'm not sure about "str"@lang, but I think so.

21:30:33 * DanC considers the tests somewhat more definitive than notation3.py

21:30:59 * mortenf should probably run some tests on hus homegrown (subset) converter

21:31:41 <sbp> I can confirm that both ^^datatypeURI and @lang are supported in notation3.py,v 1.141

21:32:46 <DanC> ^^ is in the test suite too: http://www.w3.org/2000/10/swap/test/syntax/numbers.n3

21:32:46 <sbp> it's a shame that all of the grammar => code implementations were never absorbed into the live SWAP code...

21:32:58 <sbp> cool

21:33:19 <DanC> the grammar=>code stuff never passed all the tests. sign.

21:33:21 <DanC> sigh.

21:33:24 <sbp> and some number types. interesting

21:33:25 <karlcow> arg isaviz is in Java :/

21:33:34 <DanC> arg?

21:33:45 * DanC thought I was the only java luddite left

21:33:58 * danbri stopped writing in Java in 1999

21:34:08 * danbri can't see Java applets on his main desktop

21:34:11 <DanC> writing is one thing; using is another

21:34:27 * karlcow doesn't like so much Java. One of the reason is the UI. Like it's impossible to cut and paste thing in it.

21:35:58 <sbp> I dislike the syntax, stdlib, and approach. can't really comment on GUIs

21:36:53 <karlcow> wow you need a lot of things to install before using isaviz. I don't have time now. I will check later if I can.

21:37:32 * DanC is experimenting with gnumeric as an RDF authoring tool; having a blast

21:40:15 <DanC> on the montreal trip, we kept a trip log: time, odometer reading, notes

21:40:17 <DanC> plus I have receipts.

21:40:34 <DanC> I put them all into a spreadsheet, and now I'm writing a .xsl to convert to .rdf

21:41:03 <DanC> it would be cool to convert the result to animated SVG

21:41:39 <Cardinal> What do you make the triples from?

21:41:47 <JibberJim> that would be fun, I'm still interested in doing that sort of thing, but I need to find the time :-(

21:42:06 <DanC> each spreadsheet cell is a triple.

21:42:14 <DanC> the property comes from the column heading

21:42:33 <DanC> the subject is sorta implicit (a bnode) and the object is the value

21:42:59 <DanC> I might not constrain myself to use the same subject for the whole row... I might consider rows somewhat complex things.

21:44:44 <mortenf> F:[some progress|http://www.wasab.dk/morten/2003/06/cal/action.html]...

21:44:45 <dc_rdfig> Added comment F3.

21:45:33 <mortenf> F:[some progress|http://www.wasab.dk/morten/2003/06/cal/action.html], comments welcome...

21:45:33 <dc_rdfig> Added comment F4.

21:45:38 <mortenf> F4:""

21:45:39 <dc_rdfig> Deleted comment F4.

21:45:41 <mortenf> F3:[some progress|http://www.wasab.dk/morten/2003/06/cal/action.html], comments welcome...

21:45:42 <dc_rdfig> Replaced comment F3.

22:09:07 * DanC is winning...

22:09:08 <DanC> [[

22:09:10 <DanC> <r:Property r:about="http://dm93.org/2003-08triplog/vocab@@#prop1">

22:09:10 <DanC> <s:label>DateTime</s:label>

22:09:10 <DanC> </r:Property>

22:09:10 <DanC> <r:Property r:about="http://dm93.org/2003-08triplog/vocab@@#prop2">

22:09:10 <DanC> <s:label>Miles</s:label>

22:09:12 <DanC> </r:Property>

22:09:14 <DanC> ]]

22:09:16 <DanC> and...

22:09:42 <DanC> [[

22:09:43 <DanC> <prop1 xmlns="http://dm93.org/2003-08triplog/vocab@@#">37833.6222222222</prop1>

22:09:44 <DanC> <prop2 xmlns="http://dm93.org/2003-08triplog/vocab@@#">1779</prop2>

22:09:44 <DanC> ]]

22:17:41 <DanC> ok, winning even better... [[

22:17:43 <DanC> <r:Description>

22:17:43 <DanC> <ts:DateTime>37833</ts:DateTime>

22:17:43 <DanC> <ts:Payee>Applebee's</ts:Payee>

22:17:43 <DanC> <ts:Card>D1459</ts:Card>

22:17:44 <DanC> <ts:Price>47.49</ts:Price>

22:17:46 <DanC> <ts:City>Columbia</ts:City>

22:17:48 <DanC> <ts:State>MO</ts:State>

22:17:50 <DanC> <ts:PayeePhone>tel:+1-573-445-5759</ts:PayeePhone>

22:17:52 <DanC> </r:Description>

22:17:54 <DanC> ]

22:17:56 <DanC> ]

22:18:06 <Cardinal> The ts term names are the columns?

22:18:11 <DanC> yup.

22:18:14 <Cardinal> Nice.

22:18:52 <DanC> zat you, tim? I'm having fun with gnumeric as an RDF authoring tool; converting .gnumeric files to .rdf via .xslt

22:19:36 <DanC> now... let's see if I can use cwm date built-ins to convert gnumeric/excell dates to XML schema dates...

22:22:45 <DanC> 132 lines of XSLT. not bad.

22:33:31 <DanC> hmm... how many days between jan 1, 1900 and jan 1 1970?

22:33:49 <DanC> i.e. what's the difference between the cwm epoch and the excel/gnumeric epoch?

22:34:34 <DanC> ah... let's ask gnumeric...

22:37:55 <AaronSw> the new python datetime module could tell you too

22:38:27 <DanC> Thursday Jul 31 14:56 converts to 2003-07-31T14:56:00Z

22:38:46 <AaronSw> >>> datetime(1970,1,1) - datetime(1900,1,1)

22:38:46 <AaronSw> datetime.timedelta(25567)

22:38:48 <DanC> so that much is working... but I need to factor in the timezone...

22:39:15 <DanC> I got 25569 as the difference

22:39:44 <DanC> maybe 1 is Feb and you need to use 0?

22:40:04 <AaronSw> one is probably doing inclusive and one isn't

22:41:20 <DanC> that doesn't seem right.

22:46:25 <DanC> ok... I get 2003-08-13T15:45:00Z from Thursday Jul 31 14:56 -0500

22:46:27 <DanC> bingo.

22:46:41 <DanC> hmm...

22:49:55 <DanC> no, this is very wrong...

22:54:23 <DanC> ok... Friday Aug 01 9:11 goes to 2003-08-01T09:11:00 -0500 which goes to 2003-08-01T14:11:00Z

22:54:41 <DanC> yes, that's right.

23:01:57 * tim-gone on and off on dial-in connection


The IRC chat here was automatically logged without editing and contains content written by the chat participants identified by their IRC nick. No other identity is recorded.

Alternate versions: RDF Resource Description Framework Metadata and Text

Provided by Dave Beckett. Hosted by Useful Information Company.