Semantic Web Interest Group IRC Chat Logs for 2003-03-12

00:00:12 <dc_rdfig> A: http://www.tuftslife.com/dining/menuview.php?ID=00029&pg=4 from danbri

00:00:16 <dc_rdfig> A: http://www.tuftslife.com/dining/menuview.php?ID=00029&pg=4

00:08:55 <dmwaters> {global notice} Hi all, we've lost one of our main rotation servers, we're working to resolve the issues as quickly as possible. further announcements will be givem in wallops.

00:09:10 <dmwaters> {global notice} to see wallops, set usermode +w. Thank you for using freenode

00:09:22 <MysticOne> [GlobalNotice] The network is undergoing a not-so-nice attack at the moment. We're working on getting everything stable and back to where it should be. No doubt you're experiencing severe lag. This is a result of the problem. So please, bear with us. If you happen to have a large number of clones joining your channel and staff hasn't already come in there, please come into #Freenode to report it. Thanks.

00:09:24 <grault> grault is now known as earle

00:09:24 <earle> evening space

00:18:36 <mdupont-work> mdupont-work is now known as mdupont-zzz

00:19:29 <MysticOne> [GlobalNotice] An update on the attack. It's apparently dying out now. Thanks for all who worked with us to try and defeat it. Also, if you were in a channel that was attacked, *PLEASE* consider setting a limit just a few users higher than your current maximum. This will help keep them from join/part flooding you until we can get them taken care of.

06:26:20 * jeremiah is away: sleep

07:27:12 <arnarl> hi

07:46:47 <arnarl> arnarl is now known as arnarl|meeting

09:20:36 <golbeck> golbeck is now known as golbeck_zzz

09:52:54 <aml_> aml_ is now known as aml

11:20:42 <mdupont> hey dajobe

11:21:05 <mdupont> i got the swigsharp program running under debian

11:21:21 <mdupont> and have been working on the wrappers for redland

11:21:22 <mdupont> in c#

11:21:28 <dajobe> ok

11:21:40 <mdupont> i dont know much about the typemaps, and most of the classes are empty

11:22:03 <mdupont> basically it creates one big class to invoke the functions

11:22:18 <mdupont> and some other satellites to proxy them

11:22:22 <mdupont> like rdf_statement

11:22:37 <mdupont> but there must be a way to get the methods to be in there

11:22:53 <mdupont> how do you do this in perl/swig

11:23:01 <dajobe> I've used swig for a long time, but I never used typemaps

11:23:13 <dajobe> the docs always seemed to lag the implementation, they seem to have caught up a bit

11:23:31 <dajobe> plus you lost some control over object references and alloc/free

11:26:12 <mdupont> ok

11:26:22 <mdupont> well, I will have to look into this in more detail

11:26:28 <mdupont> just wanted to pick your brain

11:26:44 <mdupont> I hope to have the primitive version linking soon

11:27:03 <mdupont> the best would be to use that invoke layer to implement the api discussed

11:27:21 <mdupont> instead of leaving the end user class design to swig

11:28:10 <mdupont> anyway, I'll keep you informed

11:28:15 * mdupont gets back to work

12:47:22 <libby> any w3c-ers know if swada is dead forever.....?

13:55:32 <ericP> libby, it should be up now

13:55:49 <ericP> dunno what's wrong with it. trying different kernels now

13:55:58 <ericP> suspect motherboard, though

13:57:04 <libby> cheers ericp

13:57:07 <libby> bummer :(

13:57:37 <ericP> "cheers\nbummer" seems like a bit of a mixed message

13:58:04 <libby> heh

13:58:32 <ericP> and i'm in for reporting on TP query stuff

13:58:36 <libby> actuall;y I cant access it. maybe I'm confused about what's where - I'm after http://esw.w3.org/t/view/ESW/RdfCalendarSchema

13:58:40 <ericP> sorry to be lame about reply

13:58:40 <libby> ooh, excellent!

13:58:47 <libby> thanks, no, that's great

13:58:58 * ericP checks port 80

13:59:44 <ericP> `lsof -i :80` gives me back zilch

13:59:59 <libby> crud

14:00:44 <ericP> looks like the TAP module went away

14:05:10 <ericP> fixedswada:~# lsof -i :80

14:05:10 <ericP> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

14:05:10 <ericP> apache 4618 root 17u IPv4 3436 TCP *:www (LISTEN)

14:05:10 <ericP> apache 4619 root 17u IPv4 3436 TCP *:www (LISTEN)

14:05:28 <ericP> try now

14:06:39 <libby> hooray!

14:06:43 <libby> thanks ericp

14:21:08 * dajobe crashes brownsauce

14:21:19 <dajobe> hmm, no shellac

14:32:56 <libby> ercp, would you be ok talkign about the tech plenary stuff first tomorrow at the ql meeting?

14:33:03 <libby> ericp even

14:39:31 * DanC works on april itinerary...

14:40:22 <DanC> unknown airport: MIAMI INTERNTNL at ../../2000/10/swap/pim/grokTravItin.pl line

14:40:23 <DanC> 249, <> line 43.

14:40:52 <DanC> hmm... I've been managing a list of airport names by hand... I wonder if there's a better way...

14:44:08 * DanC adds MIA by hand...

14:50:47 <jang> do iata.org have it?

14:50:56 <jang> that is, a machine-readable list?

14:53:08 <ericP> libby, ql meeting, sure

14:53:58 <jang> danc: iata dump here: http://www.nationsonline.org/oneworld/airport_code.htm

14:54:15 <DanC> does 'MIAMI INTERNTNL' occur there?

14:54:39 <jang> MIA is Miama, Florida

14:55:17 <ericP> libby, i should check timing. when is the ql meeting?

14:55:28 <jang> new intl airports don't happen that often, you could probably just scrape those

14:55:50 <ericP> Message-ID: <Pine.GSO.4.44.0303111515530.8200-100000@mail.ilrt.bris.ac.uk> doesn't say it in big letters at the top prefixed by "ERIC, READ THIS:"

14:55:53 <DanC> yeah, I can manually tell that 'MIAMI INTERNTNL' is MIA; I looked it up somewhere else already. But I don't see any way to automate the mapping.

14:56:38 <libby> ericp its at 3 GMT which is er 10am EST?

14:57:02 <libby> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=3&year=2003&hour=15&min=0&sec=0&p1=0

14:57:17 <jang> I'm not aware that "MIAMI INTERNTNL" is a standard name

14:57:41 <DanC> yeah; that's the problem, jang. But that's the name used in the proposed itinerary I just got.

14:57:46 * ericP checks for conflicts

14:57:46 <jang> that website also lists 10 Downing Street as the official residence of "Toni Blair" :-)

14:58:59 <jang> Looking at that list, there are some "obvious" problems, like LGW and LHR, and the two Rochesters

14:59:43 <DanC> so anyway, my solution is to store the mapping from "MIAMI INTERNTNL" to 'MIA' in the nasty perl script that groks the rest of the itinerary syntax.

14:59:47 <jang> You might be able to find reasonable "guesses" by matching individual words in the airport name against the list

15:00:27 <jang> best approach would be to ask the people woh made the itinerary to include iata tlas in the future :-)

15:00:41 <DanC> easier to just hack the perl script ;)

15:01:00 <libby> cheers ericp

15:01:00 <jang> heh, almost always

15:01:22 <libby> probably too late to change this one, but we could change the next if you cant make it

15:01:38 <ericP> libby, i would consider W3C team participation at risk until 1530Z

15:02:29 <ericP> we have a tech review on RDF in XHMTL from 1400Z to about 1530Z, likely shorter

15:02:42 <DanC> eek, is that tomorrow, ericP?

15:02:47 * DanC checks...

15:02:51 <ericP> yup

15:04:03 <ericP> also, how long do you expect the query meeting to go?

15:04:27 <libby> an hour

15:04:31 <libby> crud

15:04:50 <ericP> i have a meeting with Grosof 1615Z to 1915Z

15:05:13 <ericP> so at least that side works

15:06:08 <libby> ok, well I'll leave you second in the agenda for now.

15:06:27 * libby worries about ite 1 too. probably a bit stuck without e.g. danbri or someone from w3c

15:06:32 <ericP> after danbri, who's also supposed to be there?

15:07:02 <libby> from w3c?

15:07:06 <libby> or in general

15:07:27 <ericP> um, i think we're confusing each other now

15:07:35 <libby> ?

15:07:36 <libby> probly

15:08:02 <ericP> do you want to tackle use cases yourself?

15:08:21 * libby twigs...maybe

15:08:42 <libby> for . Reporting back from the W3C technical Plenary

15:08:42 <libby> (volunteers requested)?

15:08:46 <libby> 2?

15:08:50 <libby> usecases??

15:08:55 * libby tired ;)

15:09:48 <ericP> you were also at all the query things i was at so you could take 1 first

15:10:01 <libby> okeydokey

15:10:05 <libby> 2, you mean?

15:10:20 <ericP> yep, "2" was what i meant

15:10:28 <libby> right, yep, am trying ot write stuff up now, but can only really give my impressions :)

15:10:56 <ericP> i think i sent some BOF notes to rules

15:11:07 <libby> ok, I'll link them in

15:12:01 <libby> oh yes, nice one

15:12:06 <libby>http://www.w3.org/2003/03/05-rdf-query-BOF

15:12:07 <dc_rdfig> B: http://www.w3.org/2003/03/05-rdf-query-BOF from libby

15:12:07 <ericP> cheers!

15:12:42 <libby> B:|RDF Query BOF minutes from 2003-03-05

15:12:42 <dc_rdfig> Titled item B.

15:27:05 <AndyS> Libby: SWAD-e phone conf is "Thurs 13th March from 16.00 - 17.30" (to quote Kate)

15:27:40 <libby> yep.

15:28:00 * DanC finishes apr travel itinerary, now available from http://www.w3.org/People/Connolly/

15:28:05 <DanC> hmm... did I update my foaf deely?

15:28:49 <libby> andys, we have said we'll finifsh by 4. if necessary I could be there a little late.

15:30:44 <AndyS> Its just it can't move for the W3C folks if you have to go to that :-(

15:32:10 <libby> I wasnt going to move it - it's too late.

15:42:15 * jeremiah is away: school

15:48:45 <arnarl|meeting> arnarl|meeting is now known as arnarl

16:11:56 <DanC> woohoo! I got hipAgent.py to add an event to my sidekick calendar.

16:25:12 <minddog_> minddog_ is now known as minddog

16:32:09 <DanC> cool... got my Apr itinerary in my sidekick without gui-ing.

16:33:02 <DanC> bummer... reminders didn't work.

16:50:18 <libby>http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0009.html

16:50:24 <dc_rdfig> C: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0009.html from libby

16:51:10 <libby> C:|RDF calendar meeting agenda for today's meeting (at 17:00 GMT, i.e. 10 minutes time)

16:51:11 <dc_rdfig> Titled item C.

16:52:11 <libby> C: 1. is it OK to check GPL'd code in under http://www.w3.org/2002/12/cal/ (Libby) - postponed from last time

16:52:12 <dc_rdfig> Added comment C1.

16:52:36 <libby> C: 2. How will we know when we're done? (Libby)

16:52:36 <dc_rdfig> Added comment C2.

16:52:53 <libby> C: 3. Test data - where's the best place to get it from? (Libby)

16:52:54 <dc_rdfig> Added comment C3.

16:53:07 <libby> 4. Going from RDF to iCal (Ryan Lee)

16:53:15 <libby> C: 4. Going from RDF to iCal (Ryan Lee)

16:53:15 <dc_rdfig> Added comment C4.

16:53:22 * DanC recommends a BLURB-per-item

16:53:37 <libby> yeah, wasn;t sure how you did it danc

16:53:45 <DanC> oh frap; not sure I can make it today... there's a telcon tomorrow I need to send an agenda for.

16:53:58 <libby> darn.

16:54:10 <libby> well, we'll see how we go

16:56:46 <libby> BLURB:Calendar meet agenda 1: GPL'ed code under http://www.w3.org/2002/12/cal/

16:56:46 <dc_rdfig> D: Calendar meet agenda 1: GPL'ed code under http://www.w3.org/2002/12/cal/ from libby

16:57:13 <libby> BLURB:Calendar meet agenda 2: How will we know when we're done?

16:57:13 <dc_rdfig> E: Calendar meet agenda 2: How will we know when we're done? from libby

16:57:37 <libby> BLURB: Calendar meet agenda 3: Test data - where's the best place to get it from?

16:57:38 <dc_rdfig> F: Calendar meet agenda 3: Test data - where's the best place to get it from? from libby

16:57:56 <libby> BLURB: Calendar meet agenda 4: Going from RDF to iCal (Ryan Lee)

16:57:57 <dc_rdfig> G: Calendar meet agenda 4: Going from RDF to iCal (Ryan Lee) from libby

17:01:12 <libby> oh well, guess it's time

17:01:25 <libby> --------RDF interest group calendar meet ------

17:01:44 * libby wonders if anyone is here for the meeting

17:02:00 * eikeon is lurking

17:02:07 <libby> :)

17:02:07 * danbri is lurking

17:02:16 <danbri> hi eikeon!

17:02:28 * danbri happy to be able to put face to irc nick better now :)

17:02:30 <mdupont> danbri: the developer from forum wants to move to rdf

17:02:35 <mdupont> using ruby

17:02:36 <eikeon> Hi danbri... me too :)

17:02:36 * libby wonders if ryan's about

17:02:50 <mdupont> can I forward him to you? I think he needs some direction

17:03:05 <danbri> sure

17:03:11 <mdupont> great :)

17:03:20 <danbri> send mail, kick me in irc if i don't respond within a few days

17:03:24 <libby> is anyone here for the calenfdar meet and not lurking?

17:03:31 * libby hopes so....

17:03:38 <libby> ooh, hey ryanlee

17:03:39 * mdupont hides

17:03:47 <ryanlee> hello libby

17:03:54 <libby> thanks for coming

17:04:04 <libby> it's a little quiet today....

17:04:36 <ryanlee> sure seems that way...

17:05:05 <libby> ryanlee, since you and I are the only ones not lurking, would you care to talk about your agenda item first?

17:05:15 * danbri unlurks and listens

17:05:35 <ryanlee> it would be nice if DanC were to tune in too

17:06:00 <danbri> I have a use case I'd be interested to share, possible use for recurrance rules

17:06:15 <libby> <DanC>oh frap; not sure I can make it today... there's a telcon tomorrow I need to send an agenda for.

17:06:23 <ryanlee> ah, ok

17:06:48 <ryanlee> i can blab for a little bit... the main idea is just going from RDF to iCal

17:06:57 * danbri votes for blabbing!

17:07:00 <libby> thanks ryan

17:07:09 * libby likes this idea

17:07:22 <ryanlee> we have a tool, but it was DanC's hack to go from RDF into his own evo calendar

17:07:23 <danbri> queue me up for use-case blabbing too, lib...

17:07:28 <libby> okey

17:07:46 <libby> ---agenda item 4: ryan on rdf to ical

17:07:53 <ryanlee> other calendars (korganizer, ical itself) didn't like it very much, so we're looking to either improve the python

17:08:01 <ryanlee> ...or go with an xslt solution

17:08:07 * eikeon listening too... wonders where I should start reading to make sure I am in sync with you all... calendaring homepage is where?

17:08:17 <libby> BLURB: calendar agenda 5: Danbri talks about recurrence usecase

17:08:17 <dc_rdfig> H: calendar agenda 5: Danbri talks about recurrence usecase from libby

17:08:33 <ryanlee> ...or listen in on whether someone here as better ideas

17:08:34 <libby> xslt sounds interesting

17:08:59 <LotR> eikeon: w3.org/2002/12/cal/

17:09:03 <libby> ..since we hav ea syntactic conversion to rdf from ical

17:09:29 <libby> - although I guess might run into trouble with more flexibly-written RDF later

17:09:42 <danbri> I'd suggest going with improved Python, since generalised RDF processing in XSLT is a pain

17:09:48 <libby> ryanlee, have you done a lot of RDF?

17:10:06 <ryanlee> yeah, the xslt would have to go with rigid rdf/xml

17:10:16 <danbri> There are XSLT RDF parsers, eg. MaxF's http://www.w3.org/2001/12/rubyrdf/xsltrdf/ but not much in xslt that can then consume general triples.

17:10:31 <danbri> yup, its all usually done w/ stereotyped / rigid / canonicalised doc typing

17:10:35 <ryanlee> um, maybe you want to ask if i understand it well :) been working with it for almost a couple years

17:10:38 * libby wonders if DanC's and my sytacxtic conversions would work with xslt

17:11:24 <libby> - mine folloiws the format of the ical file...

17:11:25 <ryanlee> (by Python, i actually mean cwm)

17:11:46 <libby> what do you think was wrong with the initial version?

17:11:56 <libby> (the lythin one)

17:12:05 <libby> s/lythin/python/

17:12:07 <danbri> I was thinking about Cwm-based processing earlier, wondering whether anyone ever uses it via API calls from another program instead of as a commandline text filter

17:12:30 <ryanlee> danbri, i did for my thesis work, but that API probably doesn't work anymore

17:12:52 <ryanlee> libby, it's out of date and doesn't handle everything (particularly timezones), plus the current output isn't valid, so DanC tells me

17:13:21 <timbl-scribe> The API changed -- some back-compatible stuff put in.

17:13:26 <timbl-scribe> s/put/left/

17:13:47 <eikeon> Anyone have a pointer to the current .py for rdf to ical?

17:13:57 <ryanlee>http://www.w3.org/2000/10/swap/pim/toIcal.py

17:13:57 <dc_rdfig> I: http://www.w3.org/2000/10/swap/pim/toIcal.py from ryanlee

17:14:02 <timbl-scribe> Now it is much more freinedly API IMHO and more like rdfLib -- triples based rather than quads.

17:14:08 <timbl-scribe> timbl-scribe is now known as timbl

17:14:23 <libby> I:|python code for RDF to icalendar

17:14:23 <dc_rdfig> Titled item I.

17:15:04 <ryanlee> so one improvement to the current toIcal is to use the newer API, aside from issues of correctness of output

17:16:29 <djay> hi

17:16:32 <ryanlee> i believe DanC would like for me to take on that task... so if no one has any other observations, i'll throw that into my to do list and pass things on to danbri...

17:16:32 <libby> so ryanlee, what are yu going to do with the icalendar output when you have it; i.e. where are you going to get the ical from anbd wher's it going to?

17:16:57 <libby> (just for interest)

17:17:00 <danbri> ah, http://www.w3.org/2000/10/swap/pim/toIcal.py makes me think my ruby api could end up same as cwms quite cheaply

17:17:30 <danbri> Yup, updating to new API would be good.

17:17:35 <ryanlee> the ical is the end product for most of my use cases

17:17:38 <danbri> So is it me? Am i on?

17:17:45 <libby> also, how do you get ical from your html?

17:17:51 <ryanlee> some of them go xhtml -> rdf -> ical

17:17:56 <ryanlee> others are rdf -> rdf -> ical

17:18:16 <libby> I'd be interested to know more - do you have a writeup anywhere?

17:18:26 <libby> danbri in a sec?

17:18:30 <danbri> sure

17:18:45 <ryanlee> not at the moment, no

17:18:56 * danbri will send it in mail and chump a ptr, in 2-3 mins

17:19:25 <libby> I say this because we experimented with xhtml->sort of rdf calendar format in SWAD-E project; would like to know what others are doing

17:19:37 <libby>http://www.w3.org/2002/10/scrape/

17:19:37 <dc_rdfig> J: http://www.w3.org/2002/10/scrape/ from libby

17:19:39 * DanC still futzing with http://www.w3.org/2001/11/StdLiaison#IETF telcon. :-{

17:19:40 <danbri> having a template for webmasters to follow in their html would be cool

17:19:46 <ryanlee> i believe most of the stuff i'm playing with is w3c-sensitive info in some way...

17:20:06 <libby> J:|oops, protected link - member only?

17:20:07 <dc_rdfig> Titled item J.

17:20:09 <timbl> Note for iCal to HTML on a web site, [phpIcalendar http://phpicalendar.sourceforge.net/nuke/] is a great though read-only human interface

17:20:31 <timbl> Needs PHP4, not currently run on www.w3.org alas

17:20:46 <ryanlee> oops... try http://www.w3.org/2002/10/scrape/WG-Style-Guidelines.html

17:20:55 <libby> thanks ryan

17:21:16 <libby> J:=http://www.w3.org/2002/10/scrape/WG-Style-Guidelines.html

17:21:16 <dc_rdfig> Replaced URL of J.

17:21:37 <ryanlee> that's a step away from calendar work though... things that come out of scraping may make it into an ical presentation

17:21:38 <libby> J:|heh, still portected

17:21:39 <dc_rdfig> Titled item J.

17:21:50 <libby> sure

17:21:57 * timbl wondrs whether phpicalendar ahs been chumped before

17:21:58 * danbri writing up use case

17:22:02 <libby> I was just going to say that it lloks very useful

17:22:28 <ryanlee> hm...that uri has public access assigned to it...

17:23:10 <libby> thanks danbri

17:23:18 <libby> tell me when you're ready

17:23:35 <libby> timbl, dont think so

17:23:58 <libby> oop, yes it has

17:24:15 <timbl> (how do you tell? is there an index?)

17:24:18 <libby> - http://swordfish.rdfweb.org/discovery/2001/04/rdfig/search.jsp?term=php&date=&ask=Submit

17:24:40 <libby> nromally you can search, see RHS of the rdfig.xmlhack.com page - but it's broken currentl;y

17:24:47 * ryanlee is probably done blabbing, barring other questions

17:25:01 <DanC> re cwm API... I was hoping it would work kinda like the one in the xml.com article about rdflib

17:25:04 <libby> ryan, is that page supposed to be public?

17:25:28 <libby> hey chaals

17:25:47 <libby> thanks ryan.

17:25:54 <ryanlee> it should be, according to our systems

17:26:00 <libby> I think cwm is a good idea for the reasons danbri said

17:26:12 <libby> maybe my broser being funny

17:26:15 <libby> danbri?

17:26:23 <timbl> article? http://xmlhack.com/search.php?q=rdflib&s=Search+site -> {}

17:26:57 <libby> nope, I still get asked for a pwd

17:26:59 <LotR> hmm, chaals. that seems to ring a #linpeople bell

17:27:07 <eikeon> timbl: http://www.xml.com/pub/a/2003/02/12/rdflib.html

17:27:47 * chaalsNCE wonders whether #linpeople should ring any bells.

17:28:12 <timbl>http://www.w3.org/2000/10/swap/llyn.html#Formula

17:28:12 <dc_rdfig> K: http://www.w3.org/2000/10/swap/llyn.html#Formula from timbl

17:28:15 * chaalsNCE apologises for being late and then starting on a tangent

17:28:52 * danbri sends his usecase to www-rdf-calendar

17:29:00 <timbl> K:|cwmstore (llyn) api -- Formula class is equivalent of rdflib store

17:29:00 <dc_rdfig> Titled item K.

17:29:09 * ryanlee apologizes, the stylesheet had the wrong permissions... should be available now

17:29:15 <libby> thanks :)

17:29:18 <danbri>http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0014.html

17:29:18 <dc_rdfig> L: http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0014.html from danbri

17:29:34 <danbri> L:|RDF calendar for small business opening hours Use Case, danbri@w3.org

17:29:34 <dc_rdfig> Titled item L.

17:29:53 <libby> ryanlee, thanks again for talking. wll you show us your work on RDf to ical when youre ready sometime?

17:30:02 <ryanlee> will do

17:30:06 <libby> thanks\

17:30:09 <danbri> So I've satisfied my urge to go on about this use case by writing that email. It's reasonably short.

17:30:37 <danbri> Rather than re-typing here, can I ask folks to take a look at http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0014.html and let me know when/if you've read or at least skimmed it.

17:30:44 <timbl> K: add() then close() to input, any(), each() and the() for easy queries.

17:30:44 <dc_rdfig> Added comment K1.

17:30:45 <libby> H:[see usecase|http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0014.html]

17:30:45 <dc_rdfig> Added comment H1.

17:31:01 <libby> ---agenda item 5: danbri usecase

17:31:33 <danbri> Goals for brief chat here: (i) Is the use case clear? If not I'll try to clarify. (ii) can someone with recurrance expertise suggest a strawman representation of opening hours, so I can augment it with other info (geo, photo, homepage etc) in other namespaces.

17:31:46 <danbri> s/goals/my wishlist/

17:32:33 <libby> J:|W3C Working Group Home Page Style Guidelines

17:32:34 <dc_rdfig> Titled item J.

17:33:33 * ryanlee reads, fondly remembers a web service he didn't finish to provide info for MIT people on where to get food, based on time of day

17:33:35 <chaalsNCE> I like the use case. Is the goal specifically to motivate dealing with recurrence?

17:33:40 <danbri> H:Basic idea is simple: shops and services aren't available 24x7, so we should be able to use RDF calendar representation to show when services are available, alongside other information about those services that (thanks to RDF's data mixing emphasis) can draw on other RDF/XML vocabularies.

17:33:40 <dc_rdfig> Added comment H2.

17:33:46 <libby> hey gk

17:34:08 <libby> so this is rather like people freebusy tie, but more regular

17:34:15 <libby> s/tie/time

17:34:20 <libby> sounds very useful

17:34:32 <gk-scribe> Hi Libby ... (just watching; my attention's not really on calendar stuff at the moment)

17:34:36 <danbri> Charles, thats a good question. Recurrence struck me as relevant, since there are repeating template pattern(s)

17:34:50 <gk-scribe> gk-scribe is now known as gkgk

17:35:06 <libby> perhaps lotr could help us express it as ical recurrence and we could convert to rdf?

17:35:27 <danbri> sounds plausible...

17:35:49 * danbri happy having just written it down (perhaps redundently, suspecting Greg has a better writeup somewhere).

17:36:02 <libby> or perhaps we could use lotr's recurrence tutorial to do it ourselves :)

17:36:23 <chaalsNCE> H: Simple answer is to encode straight cycles (every 7 days. Monday is a thing that happened every 7 days for over 2 millenia...)

17:36:23 <dc_rdfig> Added comment H3.

17:37:13 <danbri> H:If someone gives me a start on the RDF cal bit, I volunteer to decorate it with other RDF goodness. I have a collection of photos of local (Bristol) shops I'd like to use for this.

17:37:13 <dc_rdfig> Added comment H4.

17:37:38 <chaalsNCE> H: Exceptions such as Anzac Day (every 25th April) should be reasonably straightforward to lay on top?

17:37:38 <dc_rdfig> Added comment H5.

17:37:43 <libby> H:see [Martijn van Beers' recurrence tutorial|http://tipi.sourceforge.net/doc/recur/]

17:37:43 <dc_rdfig> Added comment H6.

17:37:51 <libby> anzac day?

17:38:14 <chaalsNCE> 25th April. Every year.

17:38:33 <libby> danbri, want to say more about this? or shall we take it away and see what we can make of it?

17:38:38 <chaalsNCE> It's a simpler exception than Easter Monday.

17:38:43 <libby> sure

17:38:50 * libby does know what ananzac is

17:38:57 <libby> doesn;t! doesn;t know

17:39:03 <danbri> H:Exceptions are subtle problem in RDF, due to monotonicity requirement.

17:39:03 <dc_rdfig> Added comment H7.

17:39:18 <LotR> this is what I came up with: http://nopaste.snit.ch:8001/2238

17:39:19 <danbri> libby, I think can leave things here for now.

17:39:27 <ryanlee> easter sunday, chaals? :P

17:39:50 <chaalsNCE> Easter Monday. Holiday in many countries, irrelevant in others.

17:39:53 <libby> lotr, for danbri's example? wow

17:39:56 <danbri> ooh, thanks LotR

17:40:05 <danbri> anybody in a position to RDFize?

17:40:16 <libby> maybe....

17:40:27 <libby> want to paste in lotr's example?

17:40:31 <libby> (for the record)

17:41:40 <chaalsNCE> is the URI given a stable one (and therefore useful in the record) ?

17:41:45 <danbri> [[

17:41:45 <danbri> From: "LotR" at 212.83.72.215

17:41:45 <danbri> Summary: shop hours

17:41:45 <danbri> BEGIN:VCALENDAR

17:41:45 <danbri> BEGIN:VEVENT

17:41:45 <danbri> DTSTART:20030101T160000

17:41:46 <dc_rdfig> Label BEGIN not found.

17:41:46 <dc_rdfig> Label BEGIN not found.

17:41:47 <danbri> DTEND:20030101T230000

17:41:48 <dc_rdfig> Label DTSTART not found.

17:41:48 <dc_rdfig> Label DTEND not found.

17:41:49 <danbri> RRULE:FREQ=WEEKLY;BYDAY=TU

17:41:50 <dc_rdfig> Label RRULE not found.

17:41:50 <ericP> danc, my argument for external key handling in FeDeRate --> http://www.w3.org/2003/01/21-RDF-RDB-access/#migration

17:41:51 <danbri> END:VEVENT

17:41:51 <dc_rdfig> Label END not found.

17:41:53 <danbri> BEGIN:VEVENT

17:41:53 <dc_rdfig> Label BEGIN not found.

17:41:55 <danbri> DTSTART:20030101T113000

17:41:55 <dc_rdfig> Label DTSTART not found.

17:41:57 <danbri> DTEND:20030101T230000

17:41:57 <dc_rdfig> Label DTEND not found.

17:41:59 <danbri> RRULE:FREQ=WEEKLY;BYDAY=WE,TH,FR,SA,SU

17:41:59 <dc_rdfig> Label RRULE not found.

17:42:01 <danbri> END:VEVENT

17:42:01 <dc_rdfig> Label END not found.

17:42:03 <danbri> END:VCALENDAR

17:42:03 <dc_rdfig> Label END not found.

17:42:05 <danbri> ]]

17:42:07 <danbri> Urk!

17:42:08 <ericP> timbl, perhaps of interest to you, too

17:42:36 <gkgk> Regarding exceptions, if there's an extra property that says "these rules apply", then I think there's a way to include exceptions without breaking monotonicity. We had a similar exchange a while back about the basic calendar being used.

17:42:41 <ericP> or anybody else intrigued by accessing relational stores from RDF queries.

17:43:27 * danbri nods to gkgk, yep, just requires being very explicit about things

17:43:50 * danbri sends lotr's example to www-rdf-calendar thread too

17:43:54 <danbri> logger_1, pointer?

17:43:54 <danbri> See http://ilrt.org/discovery/chatlogs/rdfig/2003-03-12#T17-43-54

17:44:06 * timbl thought Easter Monday was given as a/the programming example in the Algol68 report

17:44:34 <gkgk> DanBri, ... depends what you mean by explicit... I think you can avoid having to say in advance what all the assumptions are, as long as you have a handle to tag them with.

17:44:41 <danbri> Libby, I'm happy closing this agenda item, unless someones in a position to RDFize it right now and chat needed...

17:44:55 <libby> I was just trying too....

17:46:43 <libby> this iswhat mine comes up with: http://swordfish.rdfweb.org/~libby/tmp.rdf (tmp url, sorry)

17:46:52 <libby> - not sure if even valid rdf

17:47:41 <danbri> 'Exception parsing: The scheme is not conformant.' from rdf validator, mysteriously.

17:47:54 <danbri> I have to drop back to lurking shortly, sorry folks... snowed under w/ other stuff.

17:48:12 <libby> odd

17:48:18 <libby> I'll have aproper look later

17:48:21 <libby> thanks danbri

17:48:26 <libby> should make a useful testcase too

17:48:50 <eikeon> libby: rdflib parsed it.

17:48:59 <libby> how odd

17:49:28 <libby> ok, we have 3 agenda items left, all from me...

17:49:33 <danbri> testcase, yes please!

17:50:24 <libby> ...not sure if possible to chat about them now.

17:50:38 <libby> e.g. Calendar meet agenda 1: GPL'ed code under http://www.w3.org/2002/12/cal/

17:51:16 <libby> I brought this up again (postponed last time), because I've checked, and my code can;t be un-gpled, as teh author of the library doesnt want torelease as non-gpl.

17:52:01 <DanC-AIM> (I'm off to a dr's appointment, btw. Kyle, not my hand)

17:52:08 <danbri> I think as long as any GPL'd code is kept clearly separate (and independent) from tests and vocab, I'm happy.

17:52:26 <libby> danC had a problem since he wanted all code to be under the same license, and wasn;t sure if he could contrib to gpl

17:52:54 <libby> I think we have to postpone indefinitely, keep GPLed code out of teh w3c repository. that's fine by me.

17:53:21 <gkgk> What's the library that's GPLed?

17:53:28 <libby> I propose that we postpone indefinitely, keep GPLed code out of the w3c repository

17:53:46 <libby> it's a java mime-directory parser, written by Daniel resare

17:53:54 <timbl> If DanC has gone, I suggest you just check back with him when he's back.

17:53:56 <libby> i could look for others

17:54:01 <libby> ok

17:54:18 <timbl> I suspect taht it will be fine to have GPL code, it just has to be made disinct.

17:54:34 <libby> I propose postpone until next meeting then.

17:54:38 <timbl> This is easier directory by directory of course

17:54:54 <libby> sure, but people get very tense about even being in the proximty of GPLed code

17:55:18 <libby> - very important that they don;t get confused and think the tests are gpled...

17:55:19 <timbl> One could make separate tar balls.

17:55:27 <timbl> Indeed vfery important.

17:55:43 <timbl> Nothing like putting RDF metadata in the manifest.

17:56:28 <libby> any seconders for postponement?

17:56:40 <danbri> sure

17:56:43 <chaalsNCE> I think postponing this is a bad move.

17:56:50 <danbri> postpone till next meeting.

17:56:53 <libby> really? why?

17:57:16 <libby> chaals, danc had the objection, bit stuck without him

17:57:30 <libby> or rather, he had some comments last time

17:57:43 <chaalsNCE> If we can find an answer, or some of the parts of it now, we reduce the impression that this simply won't get discussed, and people wondering about contributing, like DanC, should do something else instead.

17:58:23 <chaalsNCE> We could provide an answer such as "for now, do not check in GPL code"

17:58:38 <libby> ok, well I think that would be a good move

17:58:42 <libby> wanna propose it?

17:58:45 <danbri> I propose creating a g/ subdirectory, and only putting GPL'd things there.

17:59:31 * chaalsNCE thinks the action item of creating a directory and making sure that human and machine readers realise the stuff is GPL is non-trivial.

18:00:33 <libby> any seconders for chaals' or danbri's proposals?

18:00:34 <danbri> I don't care about machine readers for now.

18:00:43 * libby inclines towards chaals'

18:01:01 <danbri> so long as your code remains available from somewhere, and is linked, I don't care where it lives.

18:01:10 <danbri> and where it lives, please be clear about the GPL-ness.

18:01:15 <danbri> s/where/wherever/

18:01:19 <libby> it should be ok

18:01:23 <chaalsNCE> this looks like the deep-linking issue on the web.

18:01:27 <libby> will do (have, actually)

18:02:15 <chaalsNCE> In what way is the fact that code is GPL'ed discoverable?

18:03:13 <chaalsNCE> (given the use patterns of finding things in the first place)

18:03:15 * danbri suspects we can go into these details outside of the cal meeting

18:04:12 <chaalsNCE> Proposed: "For now, do not check in GPL code. Establishing a GPL-friendly repository or part of one remains on the agenda"

18:04:13 <libby> ok, I propose, "for now, do not check in GPL code under http://www.w3.org/2002/12/cal/"

18:04:21 <libby> heh

18:04:27 <libby> I seocnd chaals proposal

18:05:28 <libby> C:RESOLVED: "For now, do not check in GPL code. Establishing a GPL-friendly repository or part of one remains on the agenda"

18:05:28 <dc_rdfig> Added comment C5.

18:05:41 * timbl sighs

18:05:45 <libby> C5:""

18:05:45 <dc_rdfig> Deleted comment C5.

18:05:54 <libby> D:RESOLVED: "For now, do not check in GPL code. Establishing a GPL-friendly repository or part of one remains on the agenda"

18:05:55 <dc_rdfig> Added comment D1.

18:05:58 <libby> sighs?

18:06:04 * chaalsNCE seconds danbri's proposal of not going too far down a potential Rathole

18:06:13 <libby> :)

18:06:21 <libby> next agenda item

18:06:33 <libby> ---Calendar meet agenda 2: How will we know when we're done?

18:06:41 * timbl doesn't like IPR getting in teh way of commication between well-meaning open source programmers

18:07:03 <libby> I dont think it is in this case.

18:07:09 * danbri neither, slapping the gpl stuff on another site seems reasonable for now

18:07:28 <timbl> KNow when we are done?

18:07:50 <libby> yeah. I was wondering when we might be finished :)

18:07:57 <timbl> - Having a set of test cases teh community agrees to be a godo test of conformance

18:07:59 * chaalsNCE too. Nor of IPR getting in the way of communication between well meaning open source and closed-source programmers.

18:08:17 <libby> perhaps a little premature, but it's nice to be able to say to people - "we're near finished"

18:08:38 <timbl> - Being able to round-trip stuff from iCal to RDF and back

18:08:44 <danbri> If there were an agreed target iCal test suite, I'd propose rountripping thru RDF/XML as a metric of success

18:09:10 <libby> yep, I guess its the test suite that's the issue

18:09:11 <timbl> - Being able to do simple dat calculations on non-recurring events

18:09:24 <chaalsNCE> - having an RDF/XML calendaring tool that can interoperate with iCal-based tools?

18:09:33 <danbri> I've proposed a use case that I plan to use as a measure of success.

18:10:00 <libby> danbri, your earlier case?

18:10:17 <timbl> (H?)

18:10:22 <chaalsNCE> which is more complex than Tim's "non-recurring events" and less complex than reality.

18:10:44 <danbri> (yes, the opening hours one) I suspect different folks will want to stop at varying points. If we were targetting a w3c Note or other publication of 'version 1', this 'when are we done' question might have more teeth...

18:11:06 <chaalsNCE> tools that work in addition to agreed test cases, which I think are critical

18:11:35 <libby> what sort of tools chaals?

18:11:43 <libby> conversion toolls, or tools that use the rdf?

18:12:05 <timbl> I'd set two goals - the items I just said, all with respect to non-recurring events. and then possible a second tier at which you model recurring events including a set of rules.

18:12:20 <libby> danbri, do you think a note would be useful?

18:12:39 <timbl> I don't think you need tools based on RDF as a proof of goodness of the ontology, so long as you can convert into iCal and other formats which have cool tools.

18:12:47 <danbri> A clear writeup would be useful, and tech reports (Notes etc) are the traditional way of sharing those in the W3C community

18:13:27 <libby> I certainly think tools which do the conversion are essential, but we hav ethose.

18:13:28 <chaalsNCE> tools that can author events, find out whether two events (created by different tools) overlap

18:13:29 <danbri> I agree re tools. Just being able to deploy in XML mixed with other stuff is a win.

18:13:36 <golbeck_zzz> golbeck_zzz is now known as golbeck

18:14:23 <libby> tibl, I agree with fiorst 2 cases, could you expand on third a bit? "- Being able to do simple dat calculations on non-recurring events"

18:14:36 <libby> s/tibl/timbl/

18:15:04 <danbri> meetings that occur within a larger meeting, for eg.

18:15:25 <danbri> "Find me events that occured during the W3C Tech Plenary (that were in Boston... hmm)"

18:15:52 <libby> I guess another useful thing that came up last tie is expending recurring events. Bert Bos has a thing that does that

18:15:58 <danbri> "What shops are open now and nearby within n metres?"

18:16:10 <libby> these are the simple date calcs?

18:16:17 <danbri> simple-ish ;)

18:16:22 <libby> heh

18:16:24 <libby> :)

18:16:51 <chaalsNCE> I think we can get away with leaving out "nearby" in this work, but do need to cope with timezone variations on "now"

18:17:23 <timbl> simple date calculations; just some test cases where you take an event and test that it is or is not in progress at 13:00 on 2003-03-07 and so on.

18:17:37 <timbl> - or test whether two events overlap.

18:17:54 <timbl> I can't think of very many things to test with non-recurring events.

18:18:00 <timbl> Timezones I suppose.

18:18:21 <libby> I thought what we were doing was more constrined than some of these suggetions.

18:18:35 <timbl> The thing becomes more of a test harness for the timezone stuff and time handling functions than the iCal translation itself.

18:19:07 <timbl> Well, what we are doing was IIRC "just" deciding on a common format for calendar data.

18:19:17 <timbl> That means test cases.

18:19:28 <libby> so, a test harness that tests how good the icalendar descriptions themselves are at doing what we want them to.

18:19:29 <timbl> And automatable test cases are better than human-inspection ones.

18:19:32 <libby> sure

18:20:54 <libby> ok, well how about I try to summarise this discussion into smethign we can discuss again and maybe agree on in an email?

18:21:07 <chaalsNCE> sounds good to me

18:21:13 <libby> k

18:21:36 <libby> E:ACTION libby summarise this discussion into smethign we can discuss again and maybe agree on in an email

18:21:36 <dc_rdfig> Added comment E1.

18:22:02 <libby> well there's one item left on the agenda, and 10 inutes or so

18:22:18 <libby> -----Calendar meet agenda 3: Test data - where's the best place to get it from?

18:23:15 <libby> this was triggered by a converastion I had with DanC - some of our testdata comes from descriptions of these meetings, and for this I use apple ical. but there are a few problems with apple: ical's output in icalendar

18:23:29 <danbri> Is it possible to do Google searches for things whose URIs end in ".ics" ?

18:23:39 <libby> a broader issue is that we need lots of interesting and varied icalendar data

18:23:52 <libby> maybe it's as simple as that!

18:24:03 <danbri> .google *.ics

18:24:04 <datum> *.ics: http://www.ics.com/

18:24:05 <libby> pixel had that rdf search thing

18:24:08 <danbri> doh

18:24:14 <mortenf> danbri, try inurl:.ics

18:24:28 <deltab> filetype:ics

18:25:04 <danbri> odd, 0 hits page with no text on it.

18:25:13 <libby> weird

18:25:41 <danbri> libby, re broader data, I'd like to come up with some scenarios (eg. small business one above) that would motivate folk using RDF cal structures in their FOAF files.

18:25:48 <danbri> Then we can just run a crawler to find the data.

18:26:00 <libby> ooh, that's an idea

18:26:02 <danbri> (via rdfs:seeAlso and other foaf discovery hacks, link-rel etc)

18:26:34 <libby> lotr, did you create that example by hand earlier?

18:28:13 <libby> part of it is a chicken and egg problem. There are quite a few icalendar old shema files in my database, but people probably won;t create very many new ones unless they think it's finished.

18:28:21 * chaalsNCE finds non-recurring events unmotivating.

18:28:25 <libby> excepty maybe foaf people

18:28:59 <libby> chaals, why?

18:29:09 <danbri> "recurring" events are just categories for non-recurring ones...

18:29:31 <danbri> every photo is associated with a non-recurring event. every action too. there's plenty left of interest.

18:29:58 <chaalsNCE> Sure, but the relative amount of work to generate data seems high a this stage.

18:30:02 <libby> I was wonderig whether in general better to use auto-generated files for tests rather than hand-crafted ones, in case mistakjes creep in that way

18:30:21 <libby> -unless we have a way of testign whether a file is valid ics

18:31:00 * libby intersted in the idea danc mentionned last week - photos that 'prove' you were at an event

18:31:06 <chaalsNCE> So I am trying to think of recurring ones that I can auto-generate as a series of non-recurring ones. Moonrise perhaps.

18:31:33 <danbri> most of those are liekly in icalshare.com already

18:31:36 <timbl> Scenarios: Filtering event data for relevance to people.

18:31:56 <timbl> I filter Zakim bridge-booking data for the meetings I attend.

18:32:00 <timbl> It's not public data.

18:32:23 * libby notices time is up :(

18:32:25 <DanC-AIM> Tuning in briefly... Check with me about what?

18:32:57 <libby> we wre discussing the checking in gpled code into w3c calendar space issue again

18:32:59 <timbl> changing your mind re putting gPL code, probably. If well marked

18:33:09 * chaalsNCE keeps travel data private, otherwise it would be useful.

18:34:06 <timbl> All this data is private, but the tools could be open.

18:34:09 <chaalsNCE> travel data as a test case: ignoring the fact that each end of a journey happens in a different place, the fact that you can't talk to anyone in the middle of it can be tested against.

18:34:31 <timbl> Scenario: ical + iPhoto => album built directly foir any event at which you take photos.

18:34:48 <libby> that'd be useful

18:34:55 <DanC-AIM> .google ping?

18:34:56 <datum> ping?: http://www.pinggolf.com/

18:35:43 <chaalsNCE> scenario: I can use a tool to annotate an image (e.g. for co-depiction) such that an RDF query can find that it shows me at an event, and present other information about the event.

18:36:06 <DanC-AIM> byebye

18:36:26 <chaalsNCE> er, that's a testcase perhaps. Hmm

18:36:40 <libby> since our time is up, I propose 26th March, 2003 at 17:00 UTC for next meeting: http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=3&year=2003&hour=17&min=0&sec=0&p1=0

18:37:44 <DanC-AIM> Got disconnected... Please don't put me in the critical path for the license issues.

18:38:43 <danbri> 2nded

18:38:47 <danbri> (re next meet)

18:38:48 <DanC-AIM> /me checks chump for meeting outcomes...

18:39:06 <libby> thanks danbri

18:40:19 <libby> do people have clashes?

18:42:10 <libby> chaalsNCE: next meeting [26th March, 2003 at 17:00 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=3&year=2003&hour=17&min=0&sec=0&p1=0]

18:42:13 <libby> oops

18:42:18 <libby> C:next meeting [26th March, 2003 at 17:00 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=3&year=2003&hour=17&min=0&sec=0&p1=0]

18:42:19 <dc_rdfig> Added comment C5.

18:42:37 <libby> - I'll see what the agenda's like: mabe 1 hour is ewnough?

18:43:25 <DanC-AIM> 26mar seems ok... Not quite sure, though.

18:44:08 <DanC-AIM> Hmm... Nothing got decided today, I gather?

18:44:25 <danbri> was a bit quiet, yeah.

18:44:34 <libby> there was a resoluton

18:45:07 <libby> ibby: RESOLVED: "For now, do not check in GPL code. Establishing a GPL-friendly repository or part of one remains on the agenda"

18:45:12 <DanC-AIM> Ah... I see a decision re licensing.

18:45:20 <libby> and an action

18:45:37 <libby> it was quiet though yep

18:45:48 * danbri didn't try to turn his use case thing into an action or decision

18:46:09 <libby> still, some interesting stuff, esp on 5,4,2

18:47:03 * libby finds it tricly to mange the irc chump and logs properly all at once

18:47:31 <DanC-AIM> Re 'how do we know when we're done?' ... That's the sort of hard question that I'm not really interested in unless/until we're chartering a wg.

18:48:34 <libby> well, I found the answers interesting

18:48:40 <danbri> I'm happy with the answers we sketched, re roundtripping, and scratching itches w.r.t. use cases

18:48:50 <libby> I've not tried this kind of thing before

18:48:59 <DanC-AIM> Meanwhile, we're done when (a) nobody shows up any more, or (b) wide deployment breaks out.

18:49:30 * libby hopes not (a) quite yet

18:50:43 <DanC-AIM> Done driving.

18:50:52 <DanC-AIM> (I.e. Riding)

18:52:37 <libby> the testcases are the most important thing.

18:55:55 <timbl> I notice that the RDF query usecases allow one to put in an engilsh query without an example solution.

18:56:09 <LotR> re example: yes, created by hand, no, not a permanent url

18:57:27 <timbl> One could thow in a "return all events in the group calendar which I should be attending this afternoon" as an english use case.

18:57:52 <ericP> timbl, is " [ p1 v1 ; p2 v2 ] " i legaal document?

18:58:16 <ericP> or should it be phrased " [ p1 v1 ] p2 v2 . " ?

18:58:49 <DanC-AIM> Either is ok.

18:59:03 <DanC-AIM> Well, you need . at end

18:59:34 <ericP> " [ p1 v1 ; p2 v2 ] . " ?

18:59:43 <ericP> even though there's no predicate or object?

19:00:11 <DanC-AIM> Yup.

19:00:14 <ericP> tx

19:00:58 <timbl> There are two predicates, p1 and p2.

19:01:17 <timbl> But I know what you mean. a predicateList can be void.

20:11:47 <jordan> jordan is now known as radioraheem

20:38:23 <DanC-AIM> byebye

20:38:33 * DanC away

20:38:36 * DanC is back (gone 20:55:52)

21:01:55 * DanC works on http://www.w3.org/2001/sw/meetings/tech-200303/ ;wonders if EricM is around

21:41:19 * timbl joins on request ... not sure if this will help

21:42:04 <ericP> ericP and timbl continue a discussion of http://www.w3.org/2003/01/21-RDF-RDB-access/#migration

21:42:12 <timbl> So i've been asked to state here that yo can't on the sweb have some information which changes its meaning depedning on what you later find out - the sem web is at core monotonic.

21:42:34 <timbl> The thing ericp just mentioned says 'When later informed of these external keys, the object will no longer be an integer, but instead an entity reference.".

21:43:04 <timbl> I was just objecting to that and suggesting that EricP should fix it by giving the number and teh thing identified by the numebr different names.

21:43:24 <timbl> (as properties in a table)

21:43:49 <ericP> the tool was initially unaware of the actual data it was claiming to represent

21:44:39 <ericP> ie, it did not know which attributes in a relation were foreign keys to a primary key in some (other) relation

21:45:07 <ericP> when used incorrectly, it concluded that the customer for the example order was 2.

21:45:46 <ericP> when later corrected, it instead reported that the customer was some entity represented by a tuple in the Customers relation

21:46:04 <ericP> This is, indeed, an inconsistent system.

21:47:07 <ericP> much as if the item number for the order changed 'cause the person called up and said "no wait, i want a skateboard instead of a nose ring."

21:47:57 <ericP> it turns out that the former reflects a change in the tools understanding of the universe, and the latter reflects a change in the universe, but they both must be reflected as changes in the universe.

21:49:08 <ericP> 'zat make sense (to anyone but me and probably sandro)?

21:53:48 <ericP> I added this as furthur explaination of the unconfigured state expressed above: "This would be analogous to a generic triple store reporting that the object of an arc some memory address instead of the node in the graph that was the true object of that arc."

21:56:51 <timbl> Its fien for it to report it *as a memory address of the node" but not as the node.

21:57:04 <timbl> s/fien/fine/

21:59:20 <ericP> encoding data in a relational store involves inventing attributes to serve as primary and external keys.

21:59:59 <ericP> using the tool in a way in which it is not aware of the true graph encoded in the relation will give you incorrect data.

22:00:24 <ericP> fixing the tool (configuration) will give you correct data.

22:00:40 <ericP> the two are, and should be, non-monotonic

22:01:56 <timbl> I don't see why you are hanging onto that notion of the tool using the same word for the earlier notion as for the later notion.

22:02:17 <timbl> I don't belive that there is anything non-mon going on.

22:02:28 <ericP> the monotonic violation reflects the fact that the tool incorrectly reported that some order had a customer of "2" when in fact, that was not data that was encoded in the relational model

22:03:28 <timbl> It first retuens that it has customernumber 2. later it can return that it has customer [name "joe"; hieght "1.76"].

22:03:34 <timbl> Just use different property names.

22:03:40 <ericP> i don't mind having a different accessor for the value of external keys, but i believe that the accessor "product" indicates the object that came from a generic triple store and had a name of "nose ring".

22:03:54 <mortenf> perhaps the attribute with the foreign key should have been typed as such, even though the corresponding table weren't connected - that would have resulted in an anonymous node.

22:04:29 <mortenf> i.e. not as ant "int", but as a "foreign key".

22:04:34 <mortenf> s/ant/an/

22:04:57 <timbl> What you mean, Eric, is that EricP's veiw of how this would be best modelled in RDF chanegs with new datya. But teh data don't change, the nose ring don't change, the database don't change.

22:04:59 <ericP> i agree. the prob is that some dbs dont' require you to express foreign key relations

22:05:38 <ericP> (agree with mortenf, but timbl probably guessed that)

22:05:49 <golbeck> golbeck is now known as golbeck_malty

22:05:58 <mortenf> seems then to be a defect in the db, not in the model...

22:06:51 <ericP> so then what happens when the defect is repaired, do you expect the system to be consistent with the old data?

22:06:54 <mortenf> so I'm not sure we agree, I think the unresolved case just returns fewer (0) properties than the "right" one.

22:07:33 <ericP> the prob with not returning things that might be an external key is that you also don't return peoples shoe sizes

22:07:44 <timbl> I agree that the unresolevd cae returns less triples. Its also fine to hide the foreign key when you know about it.

22:07:49 <ericP> ints are hard to distinguish from ext keys in such dbs.

22:08:10 <timbl> So you can model them and let the inference engine on top figure it out.

22:08:16 <mortenf> sure, the problem exists, but the key relationship should be just that, nothing more.

22:09:14 <timbl> You also have the nasty case in which ou have hidden the foreign key and then someone changes it so it now appears as a key in more tables o n more systems, and needs to be visible.

22:10:37 <ericP> if the systems are part of the same schema, i don't think the visibility needs to change

22:11:29 <ericP> if they are part of a different schema, they are relying on a published primary key which is discussed (briefly) in http://www.w3.org/2003/01/21-RDF-RDB-access/#migration

22:11:57 <ericP> for a consistent system, one can publish the primary key.

22:12:29 <ericP> and accesses it via that attribute in the table.

22:12:53 <ericP> ie, you never need to tell folks that the order was for customer 2

22:13:25 <ericP> hold on, that's ambiguous

22:13:41 <ericP> ie, you never need to tell folks that the order has a customer "2"

22:14:07 <ericP> instead you say it had a customer [ id "2" ... ]

22:21:58 <ericP> i had a similar argument with HFN about RDF data in SOAP encoding

22:22:19 <ericP> since SOAP encoding can represent graphs, he was saying it could be used to represent RDF data.

22:22:56 <ericP> rdf:{about,id,resource} had no special standing in his proposed mapping to RDF.

22:24:08 <ericP> this meant that every graph that it encountered that was serialized with, say, rdf:about http://example.org/#1 would be split into separate notes that all had a coincident attribute value for rdf:about

22:24:35 <ericP> given <http://example.org/#1> p1 v1 .

22:24:36 <ericP> <http://example.org/#1> p2 v2 .

22:24:50 <ericP> what would have been two term query:

22:24:54 <ericP> this log:forEach :n .

22:24:54 <ericP> { :n p1 v1 .

22:24:54 <ericP> :n p2 v2 . } log:implies { :n p12 v12 . }

22:25:04 <ericP> turned into a four term query:

22:25:08 <ericP> this log:forEach :n1 :n2 :o .

22:25:09 <ericP> { :n1 p1 v1 .

22:25:09 <ericP> :n1 rdf:about :o .

22:25:09 <ericP> :n2 p2 v2 .

22:25:09 <ericP> :n2 rdf:about :o .} log:implies { :o p12 v12 . }

22:25:40 <ericP> and didn't accurately reflect the graph data that was in the original RDF graph.