Semantic Web Interest Group IRC Chat Logs for 2004-04-07

00:23:24 <eaon> eaon is now known as the

00:23:58 <the> the is now known as eaon

04:07:30 <adamhill> adamhill is now known as _dreaminofjeanni

08:04:05 <sh1m> morning

08:05:15 <shellac> mornin'

08:08:54 <danbri> mornoon

08:10:06 * sh1m chuckles. very good

08:15:46 <mattme> morning?

08:16:20 <mattme> 16:17

08:16:57 <sh1m> mattme: its always morning somewhere

09:36:05 <dajobe>http://www.oreillynet.com/pub/wlg/4658

09:36:06 <dc_rdfig> A: http://www.oreillynet.com/pub/wlg/4658 from dajobe

09:36:12 <dajobe> A:|RELAX NG and OpenOffice

09:36:12 <dc_rdfig> Titled item A.

09:36:35 <dajobe> A:Michael Fitzgerald reads that relax ng is the normative schema language for OpenOffice.org

09:36:35 <dc_rdfig> Added comment A1.

11:19:06 <LTjake> Hello.

11:32:46 * LTjake waits for people to wake up...

11:35:28 <sh1m> hello

11:35:36 * sh1m just got back from lunch

11:37:45 <LTjake> howdy.

11:39:04 <LTjake> I'm working on exporting foaf files from a GEDCOM file (genealogy file) and I'm using the relationship schema (http://vocab.org/relationship/)

11:39:54 <LTjake> however, in GEDCOM, you generally split things up along "family unit" lines, and not just who your children and spouses are.

11:41:22 * crschmidt is awake, but doesn't know anything ;)

11:42:30 <LTjake> This is because certain children are only from a certain spouse and not directly related to other spouses (at least from the "family unit" perspective)

11:43:27 <LTjake> anyway! how do i represent that in my foaf?

11:43:52 <LTjake> here's an example where that problem occurs: http://www.alternation.net/gedcom/I0120/foaf

11:46:50 <sh1m> LTjake: I am afriad I don't know, but as general advice it is better to ask and see if someone knows than see who is here. Lots of people lurk. ;)

11:47:06 <libby> you could also ask on #foaf, tho quiet there too

11:47:08 <libby> atm

11:47:21 <crschmidt> LTjake: I'm not sure I see the problem. If my parentage is from my mother, then I am a childOf her. The fact that she is married to my father doesn't seem to indicate anything about my relationship with him, does it?

11:47:30 <sh1m> libby: that reminds me...

11:47:50 <crschmidt> Er, married to some other guy. if he was my father, ti wouldn't work ;)

11:48:32 <LTjake> crschmidt: the problem is defining family units. if you have just a jumble of spouses and children, then you have no idea which children were "made" with which spouses.

11:48:52 <libby> foaf:maker doad:made ;)

11:49:00 <libby> s/doad/foaf/

11:49:12 <LTjake> heh.

11:49:18 * crschmidt thinks that might be slightly abusing the FOAF spec :P

11:49:27 <crschmidt> But I dunno.

11:49:28 <LTjake> i guess, if i need to recycle the current foaf spec, then yeah. :)

11:50:07 <crschmidt> LTjake: I understand that, but I'm wondering if the relationships that currently exist are enough to describe it to the point where it could be reformed into GEDCOM format.

11:50:41 <LTjake> i'm going from gedcom->foaf, though.

11:51:13 <crschmidt> Right, but if the rel schema can describe, accurately enough to bring back to the original format, then no data is lost.

11:51:21 <LTjake> (the end result will be in a foafnaut-like family tree browser)

11:51:39 <crschmidt> So, can you take information from a foaf file using the rel: schema and drag it back into GEDCOM? What information, exactly, do you lose?

11:52:03 <LTjake> crschmidt: once again, at _least_, family units.

11:52:44 <LTjake> here's a good example: http://www.alternation.net/gedcom/I0123/

11:52:51 <LTjake> and the current foaf: http://www.alternation.net/gedcom/I0123/foaf

11:52:55 <crschmidt> LTjake: Pretend I'm dumb for a minute. (Okay, okay, you don't have to pretend ;)) How would family units be described?

11:52:58 * crschmidt looks.

11:53:15 <LTjake> he has 4 spouses.

11:53:38 <LTjake> with which he has children with 3.

11:54:13 <LTjake> anyway, the family unit is simple himself, a spouse, and any children from that spouse

11:54:20 <LTjake> urr simply

11:55:01 <Arnia> Family units in general, or one person's? :)

11:55:22 <crschmidt> LTjake: but surely that information is recoverable by looking at the child's "childOf" information? If they are the child of Stan and Joy, then they are in one family unit, if they are the child of Stan and Jean, another?

11:55:36 <LTjake> Arnia: ...not sure i follow (but it's early here, give me time :)

11:56:15 <Arnia> Well... my family unit doesn't include my father, but does include my mother's mum

11:58:27 <crschmidt> LTjake: Is the kind of example Arnia just stated something you're looking to represent more clearly?

11:58:53 <LTjake> (phone, sec)

11:58:57 * crschmidt nods.

12:00:40 <LTjake> right, so it's really just the spouse's children.

12:00:44 <LTjake> *ding* :)

12:01:36 <crschmidt> LTjake: So, what would you propose as a solution?

12:02:37 <LTjake> in order to define family units i need to look at the person's spouse's children.

12:02:58 <LTjake> oh crap though.

12:03:02 <Arnia> LTjake: I don't think family units can be defined...

12:03:17 <LTjake> if that spouse has remarried several times then that gets messed.

12:03:20 <LTjake> doh.

12:04:09 <LTjake> Arnia: this is not a philosophical question. In genealogy terms it's just the person, their spouse and any children from that spouse.

12:04:29 <Arnia> And what about bastards?

12:05:11 <LTjake> well, you are restricted to the GEDCOM spec, so they fit in somewhere, regardless.

12:05:20 <LTjake> be it their own family unit, on their own.

12:05:45 <Arnia> Woo, I'm not part of any family unit

12:05:54 <Arnia> And these are the guides governments use

12:07:39 <LTjake> people can choose to model it how they want though.

12:08:10 <LTjake> though that's the not the question at hand. :)

12:08:58 * crschmidt can't think of a good way to represent family units in rdf though

12:10:09 <crschmidt> 06:42:03 < LTjake> anyway! how do i represent that in my foaf?

12:10:18 <crschmidt> Isn't that the question at hand? :)

12:10:25 <LTjake> yes.

12:11:05 <Arnia> I think modelling family units is the wrong idea... you just want to model who lives with whom, who has lived with whom and who knows whom

12:11:11 <LTjake> (and not how we choose to place children of unwed parents in GEDCOM, though that's an interesting topic :)

12:11:39 <crschmidt> Arnia: I think LTjake wants to implement the GEDCOM schema, basically.

12:12:00 <LTjake> crschmidt: not fully, but enough to let me draw family trees

12:12:03 <crschmidt> Arnia: Not correct the problems in the GEDCOM way of doing things ;)

12:12:51 <LTjake> Arnia: i see your point, but most GEDCOM data is based on spousal relationships.

12:13:08 <Arnia> Silly model then :)

12:13:39 <Arnia> Ok, so its great for mining for information (cos of records) but the underlying model shouldn't deny other relationships

12:14:04 <LTjake> actually..sec phone..

12:18:49 <LTjake> okay, so i take that back.

12:18:58 <LTjake> it's based on mother-father relationships.

12:19:09 <LTjake> (so says my father who knows more about gedcom that i)

12:19:46 <LTjake> the fact that your parents are never married is irrelevant. so technically spouse is the wrong term.

12:20:19 <Arnia> Ok, that makes more sense :)

12:20:30 <LTjake> Arnia: So! you DO have a family unit, of blood origin.

12:21:51 <Arnia> One thing that concerns me though... what happens (as I've seen several times) if a parent remarries twice, has children with only two of the spouses and yet, due to death, ends up with the children of the other spouse from other marriages

12:21:52 <LTjake> Aria: But what exactly do you call the relationship between your parents? the easy way out it just to use "spouse" ... thoughts?

12:22:08 * Arnia likes difficult cases

12:22:14 <Arnia> LTjake: Enemy? :p

12:22:31 <LTjake> Arnia: that doesn't change _blood_ relationships.

12:22:39 <LTjake> Arnia: =)

12:23:01 * chaalsMEL offers an aboriginal australian model, where nobody has parents until they reach puberty. Or a Mongolian model where people don't have fathers.

12:23:19 * chaalsMEL would be surprised if you culd cover such relationships in anything _except_ RDF

12:23:50 <LTjake> chaalsMEL: lordy! let's not go there, okay? :)

12:23:59 <Arnia> I'm not doubting that :)

12:24:20 <chaalsMEL> well, without going there it seems a bit silly to invest effort from where I sit...

12:24:34 <Arnia> Likewise

12:25:32 <LTjake> Well, i'm not trying to diagram the world, here.

12:25:55 <LTjake> my own family tree is the main problem at hand.

12:26:09 <Arnia> Yes, but how is your model going to be interpreted by other cultures?

12:26:11 <chaalsMEL> (Not to discourage you, just to point out that working on ASCII relationshipsbecomes tricky if you don't anticipate Unicode relationships,.. Not that I think you are doing this, actually)

12:26:21 <LTjake> and i'm not of mongolian descent. :)

12:27:07 <LTjake> Arnia: with as much confusion as i have of their model. :)

12:27:08 <chaalsMEL> Are you sure? :-)

12:27:40 <LTjake> chaalsMEL: heh...

12:27:56 <chaalsMEL> Yeah, I don't think that there is a problem in developing something simplistic.

12:28:27 <Arnia> LTjake: Are you modelling social relationships (as in FOAF style), or blood relationships (he beget him who beget her)

12:28:31 <chaalsMEL> You just need to anticipate that people will try to do something more clever, and be prepared to follow or vanish if it does come along...

12:28:32 <LTjake> keep in mind that i'm modeling specific vocabulary.

12:28:44 <Arnia> LTjake: I think there is a signficant difference between the two models

12:29:01 <chaalsMEL> I am not sure that is the best way to go in the long run.

12:29:36 <Arnia> The first is impossible to define sensibly in a universal way, the second doesn't imply anything about the first (adoption, tangled marriages etc)

12:29:50 <chaalsMEL> It seems to make sense as a quick way of developing stuff that works with existing work - see the RDF/iCal work, which explicitly started out by modelling an existing vocabulary.

12:29:52 <Arnia> At least its impossible using a simple vocabulary ;)

12:29:53 <LTjake> Arnia: the heart of it is blood relationships. But the hope was to use existing foaf/relationship vocabs.

12:30:11 <Arnia> LTjake: I don't think they mean the same thing

12:30:41 <Arnia> LTjake: FOAF models social relationships... blood relationships are a genetic thing, and often have little bearing on the social relationships around them

12:30:53 <chaalsMEL> But after a while you discover the problems with the modelling behind the vocabulary you started from, and need to be able to separate your model out...

12:31:34 <LTjake> Arnia: yeah -- that's why i don't use any foaf terms other than "person" and attribute terms (like name) -- the rest comes from the relationship vocab

12:31:56 <LTjake> chaalsMEL: So, what exactly are you suggesting? :)

12:32:15 <chaalsMEL> That you treat modelling vocabularies as a temporary step.

12:32:52 <LTjake> ...and that i need a new vocabulary, at some point, to get what i really want?

12:33:00 <chaalsMEL> and expect it to require some stepping beyond the vocabulary, into thinking about the underlying model.

12:33:19 <chaalsMEL> (This isn't inevitable, it is just something that seems worth anticipating as it happens often).

12:34:46 <LTjake> chaalsMEL: right, so basically hacking things together right now is only a means to a quick, workable solution, but doesn't solve the larger issue at hand....?

12:35:36 <LTjake> i need coffee -- in a bad way. :)

12:36:29 <chaalsMEL> Yeah. But if you think a bit about it as you go, there is no reason why you actually cut yourself off from solving the larger problem at hand by and by...

12:40:04 <LTjake> I'm not trying to solve the larger problem anyway. :)

12:41:30 <LTjake> okay so i think that actually comparing the person's children with the spouse's children works.

12:41:44 <LTjake> any matching children means a family unit.

12:42:49 <LTjake> Diagramming this is going to be so damn hard...

12:47:58 <LTjake> Thanks for the help y'all -- if i make any progress i'll be sure to mention it here. :)

12:48:11 <timbl> I did some family tree stuff, tried diagraming it with graphviz

12:48:22 <LTjake> timbl: any luck? :)

12:48:35 <timbl> I just input parent-child relatonships

12:49:06 <timbl> Then deduced that if two people have the sema child they must have had a union of some sort, and generated a union node labelled "=".

12:49:48 <timbl> worked quite well. the original parent/child data was much more compact as a graph, but confused people who expected a family treee.

12:49:54 <LTjake> right, that's basically what i said a few lines up, i think.

12:50:20 * timbl hadn't been following, distracted, just tuned in and is in anopther meeting nyway :-/

12:50:28 <LTjake> (i.e. matching children between either parent)

12:50:42 * timbl rummages for rules

12:50:43 <LTjake> no problem. :)

12:51:10 <LTjake> my father sent me a fax on how he might graph a family tree...

12:51:15 <LTjake> not sure it works exactly.

12:51:32 <LTjake> looks damn confusing. :)

12:52:24 <timbl> hmmm.... http://www.w3.org/2000/10/swap/pim/tree.n3

12:53:37 <timbl> The tree I used it on had a lot of properties you can't count on -- only one marraige, always man-woman, name propgates down male line etc... this makes generatoin much easier but is a representation of the western culture of a century ago.

12:54:13 <LTjake> yeah.

12:54:24 <LTjake> gender is technically irrelevant in GEDCOM relationships.

12:55:33 <LTjake> multiple "family units" (*groan*) are doable too.

13:09:14 <LTjake> timbl: I'm not exactly sure what to make of that tree.n3 -- my n3-fu is not good.

13:09:37 <LTjake> timbl: i get the gist of it, though.

13:10:28 <timbl> Oh, those are rules. They deduce where "=" (Marrgiage) nodes ar, and what color they should have when rendered.

13:11:16 <LTjake> oh, okay.

13:11:25 <LTjake> is that your work?

13:31:48 <LTjake> LTjake is now known as LTmeeting

13:58:29 <eaon> eaon is now known as eaon|zZz

14:06:04 <JimJibber> LTJake?

14:06:47 <_dreaminofjeanni> _dreaminofjeanni is now known as adamhill

14:07:05 <JimJibber> I was reading back, if you're wanting to define family units, can you not define a foaf:Group that is that family unit, and make each person a member of it it - in addition to the relationship schema for individual relationships?

14:07:24 <JimJibber> Have you also read the FOAF list discussion on the rel schema?

14:14:51 <LTmeeting> LTmeeting is now known as LTjake

14:14:58 <LTjake> Jim?

14:17:01 <LTjake> JimJibber: I guess i'm not really familiar with foaf:Group let me look at the spec.

14:17:46 <LTjake> JimJibber: I've read some stuff, but most of it was blasting it for not having terms like "sleptWith" and such. :)

14:17:58 <JimJibber> hehe

14:18:30 <JimJibber> There was a suggestion that relationships could be inferred from son/parent etc.

14:19:13 <chaalsMEL> Not without a watertight modelling of child/parent relationships as biological...

14:19:15 <LTjake> Well, i can infer family units be comparing the current person's children with their spouses' children.

14:20:53 <JimJibber> indeed chaals, which was my point, complete with personal examples

14:21:12 <JimJibber> are you sure LTJake?

14:21:33 <LTjake> absolutely. let me show you an example.

14:21:52 <LTjake>http://www.alternation.net/gedcom/I0123/

14:21:53 <dc_rdfig> B: http://www.alternation.net/gedcom/I0123/ from LTjake

14:22:03 <LTjake>http://www.alternation.net/gedcom/I0132/

14:22:03 <dc_rdfig> C: http://www.alternation.net/gedcom/I0132/ from LTjake

14:22:13 <LTjake> oops. those were logged, and we unlog those?

14:23:12 <LTjake> anyway, compare I0123's children with I0132 and you have 3 matches, thus a family unit.

14:23:18 <JimJibber> with difficulty, you can replace.

14:23:30 <JimJibber> no you don't know that, unless you have a constrained version of child.

14:23:48 <LTjake> i do know that because the have the same IDs.

14:23:59 <chaalsMEL> Where family unit is people who are married, or have some "child" relationship

14:24:27 <chaalsMEL> You haven't yet deomnstrated either that anyone selptWith anyone, or that anyone has a biological relationship to anyone else.

14:24:55 <LTjake> chaalsMEL: it's all based on biological relationships. marriage is irrelevant.

14:25:16 <chaalsMEL> Oh. So there is no adoption information included.

14:25:24 <JimJibber> but biological relationship is a constrained version of child, and pretty irrelevant info at that I think.

14:25:55 <chaalsMEL> In which case spouse is irrelevant (and for that matter inaccurate in the way it is generally understood)

14:26:02 <LTjake> chaalsMEL: not that i know of.

14:26:13 <JimJibber> and A and B can have a child together, but at no time be a family unit.

14:26:15 <LTjake> chaalsMEL: and yes, spouse is an incorrect term. but an easy term to use.

14:26:27 <chaalsMEL> (although inferring a label from the string of characters that identify a property is a bad practice, IMHO)

14:26:51 <LTjake> JimJibber: But the fact that they had a child makes them a family unit. it's biology.

14:27:11 <JimJibber> so child is "biological child" ?

14:27:17 <LTjake> and so we come to realize that "family" is a bad term too! :)

14:27:19 <JimJibber> and is only valid for women?

14:27:22 <chaalsMEL> The trap is when A and C are in fact spouses, and legally recognised parents of D, but D's biological parents are A and B

14:27:28 <libby> .time

14:27:28 <datum> Wed, 07 Apr 2004 14:27:29 GMT

14:27:50 <chaalsMEL> Unless your dataset already claims to exclude such cases.

14:27:52 <libby> guys, we have a scheduled topic chat here in 3 mins, fancy moving discussion to #foaf for a bit?

14:28:01 <libby> sorry to be a nuisance

14:28:02 <LTjake> sure.

14:28:05 <JimJibber> what's the scheduled chat on?

14:28:05 <LTjake> no sweat.

14:28:07 <sh1m> libby: I was about to ask that ;)

14:28:14 <libby> calendaring jimjibber

14:28:32 <libby> cheers :)

14:28:38 <JimJibber> okay, I'll um have to drop out, and go visit #foaf. bye

14:28:53 <libby> hm, DanC sggested he might chair this time...

14:28:56 <libby> aw boo

14:29:16 <DanC> hmmm.

14:29:31 * DanC owes an RDF DAWG agenda again.

14:30:02 <libby> heyho

14:30:10 <paulc> hi all

14:30:11 * chaalsMEL slaps bijan with a very very long-winded motion on a very obscure point of order...

14:30:22 <libby> hi paulc

14:30:31 * DanC nominates chaalsMEL to chair

14:30:35 * bijan seconds

14:30:44 <libby> hurrah!

14:30:54 <bijan> Motion passed by acclamation

14:30:59 <libby>http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Apr/0005.html

14:30:59 <dc_rdfig> D: http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Apr/0005.html from libby

14:31:15 <chaalsMEL> D'oh!

14:31:17 <libby> D:|RDF Calendar chat, now, suggested agenda items

14:31:18 <dc_rdfig> Titled item D.

14:31:57 <libby> D:see [http://www.w3.org/2002/12/cal/|rdf calendar workspace]

14:31:57 <dc_rdfig> Added comment D1.

14:32:19 <libby> D:attending [LIbby Miller|http://ilrt.org/people/libby]

14:32:19 <dc_rdfig> Added comment D2.

14:32:27 <libby> chaalsMEL, will you chair?

14:32:32 <chaalsMEL> D:Any interesting use cases for airline industry people?

14:32:33 <dc_rdfig> Added comment D3.

14:32:35 <chaalsMEL> Sure...

14:32:37 * DanC hopes chaalsMEL will accept the nomination. I'd be much obliged.

14:32:38 <libby> ta

14:32:54 * chaalsMEL back in half a minute

14:32:55 <paulc> D:attending [Paul Cowles|http://pcowles.eventsherpa.com]

14:32:55 <dc_rdfig> Added comment D4.

14:32:58 <libby> .time

14:32:58 <masaka> D:attending [Masahide Kanzaki|http://kanzaki.com]

14:32:58 <dc_rdfig> Added comment D5.

14:32:59 <datum> Wed, 07 Apr 2004 14:32:59 GMT

14:33:20 <ndw> D:attending [Norman Walsh|http://norman.walsh.name/]

14:33:20 <dc_rdfig> Added comment D6.

14:33:47 <libby> heya norm

14:33:50 <timbl> D:attending [Tim Berners-Lee|http://www.w3.org/People/Berners-Lee]

14:33:50 <dc_rdfig> Added comment D7.

14:33:58 <masaka> I have a short memo on agenda items at http://kanzaki.com/works/2004/cal/0406vocab.html

14:34:09 <ndw> heya libby (I made it for a change :-)

14:34:27 <libby> yay

14:34:29 <chaalsMEL> D:Attending [Charles McCathieNevile|http://www.w3.org/People/Charles] (chair)

14:34:29 <dc_rdfig> Added comment D8.

14:35:24 <libby> oh cool, masaka, that looks very useful

14:35:39 <chaalsMEL> Yep, looks like good stuff.

14:35:45 <libby>http://kanzaki.com/works/2004/cal/0406vocab.html

14:35:45 <dc_rdfig> E: http://kanzaki.com/works/2004/cal/0406vocab.html from libby

14:35:57 <libby> E:|Masaka's notes on agenda item 2

14:35:58 <dc_rdfig> Titled item E.

14:36:26 <masaka> hope it works

14:36:49 <chaalsMEL> Shall we go with that as a first agenda item?

14:36:53 <DanC> D:attending [DanC|http://www.w3.org/People/Connolly/]

14:36:53 <dc_rdfig> Added comment D9.

14:36:58 <libby> ok

14:37:12 <chaalsMEL> (since it turns out to be important to all the airline stuff I can think of anyway :-)

14:37:47 * chaalsMEL wonders how to blog the photo of the woman in Brixton who made him a brixton (and then another)

14:37:50 <DanC> that's a bug: "On the other hand, the definition of ical:geo in RDFical schema is owl:ObjectProperty"

14:37:51 <libby> makes sense to me

14:38:49 <chaalsMEL> BLURB:

14:38:50 <dc_rdfig> F: from chaalsMEL

14:39:04 <chaalsMEL> F:|Incorporating geo information in iCal

14:39:05 <dc_rdfig> Titled item F.

14:39:17 * chaalsMEL forgets how to get a bookmark

14:39:39 <DanC> logger, chump F

14:39:39 <DanC> F:See [http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-04-07#T14-39-39|discussion]

14:39:40 <dc_rdfig> Added comment F1.

14:39:59 * chaalsMEL sweet :-)

14:40:21 * DanC isn't sure where we are... E:?

14:40:26 * libby very interested in these issues. thanks for the great writeup masaka

14:40:33 <chaalsMEL> Masaka, you want to introduce this (summarise your page and thoughts?)

14:40:53 <masaka> well

14:41:14 <masaka> it's important to combine other vocabs in RDFical

14:41:18 <DanC> E:|RDFical and related vocabularies (agendum E)

14:41:18 <dc_rdfig> Titled item E.

14:41:34 <masaka> especially Geo and FOAF

14:41:41 * chaalsMEL Ciao verbosus. Stai qui per la discussion su calendar?

14:42:20 <verbosus> chaalsMEL: hey! not really, no, but I'll happily lurk while you discuss calendaring as I did in Bristol :-)

14:42:26 <masaka> from current schema, it looks of to include geo: vocab in ical:geo

14:43:07 <masaka> i'm not sure DanC said it's a bug, but anyway it's nice

14:43:09 <libby> hey Ol

14:43:16 <chaalsMEL> Why is it important? I think if we have a good answer to this question we will have one part of a good motivation for people to use RDF.

14:43:21 <DanC> I consider it a bug that ical:geo is an ObjectProperty. RFC2445 says ical:geo takes a string value.

14:43:30 * Ol late, sorry

14:43:31 <Ol> D: attending [Olivier Gutknecht|http://www.apple.com/]

14:43:31 <dc_rdfig> Added comment D10.

14:43:42 <libby> not a bug so much as an inconsistency with RFC 2445?

14:43:47 <chaalsMEL> (the other part is being able to demonstrate that it works, which I gather is where Masaka is going with this discussion. So I will hold motivation until a little later)

14:43:56 <libby> --which we aim to represent

14:44:52 <chaalsMEL> As a maybe naive question, is there any explanation of the granularity of geo:lat ?

14:45:10 <paulc> important to us for new services we'd like to provide, such as events within radius of user location

14:45:19 <DanC> there's more and more strain on the very literal approach to mapping .ics<->.rdf . Timezones are a mess, for example. I did unpack RECUR values into structures.

14:45:47 <libby> right, that's true. the difference here is that using a different namespace maybe?

14:45:52 <chaalsMEL> (I recall a discussion that said there were no known units for elevation in the geo vocab at w3.org/somewhere

14:46:43 <chaalsMEL> I would like to hold the question of whether we keep staying strictly to RFC2445 as a separate agenda item

14:46:54 <swh> swh is now known as swh_afk

14:47:06 <paulc> yes that would be another great agenda item

14:47:07 <DanC> hmm... I got the geo schema stuff right in the .html version: <dd class='ValueType'><a rel='list-of' href='#Value_FLOAT'>FLOAT</a> . Dunno why I didn't get it right in the .rdf version.

14:48:01 <libby> so, what's this agenda item exactly?

14:48:19 <DanC> whatever we make of it :)

14:48:35 <libby> hey amy__!

14:48:40 <libby> nice photos recently

14:48:49 <amy__> hi libby! :)

14:48:52 <amy__> thanks, you too :)

14:49:04 <masaka> i like current schema definition (owl:ObjectProperty)

14:49:04 <chaalsMEL> Looking at how to mix location information into ical stuff, I think.

14:49:46 * chaalsMEL as chair will rule out any off-topic discussion unless he thinks it is more interesting than what he thought the topic was, in which case he will just change his mind about the topic :-)

14:50:00 <DanC> mk's writeup (http://kanzaki.com/works/2004/cal/0406vocab.html) and timbl's recent request (http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Mar/0016.html) are making me re-think the low-level mapping of things like lists of floats, RECUR, and time/dateTime values.

14:50:12 <timbl> re stress on literal approach, it was frustrating to find that I could almost make iCal.rdf fiels diffable, but not quite. eg tzid

14:51:37 <chaalsMEL> masaka, what is good about ObjectProperty?

14:51:47 <masaka> if it is owl:DatatypeProperty, we have to find another way to include geo:lat/geo:long

14:51:53 <libby> so, maybe if it's roundtrippable, it doesn;t really matter if object properties or literals? or ical or non-ical namespace?

14:51:59 <DanC> a proposal... call it glist for the sake of IRC mechanics... suppose we convert GEO:40.442673;-79.945815 to { [ ical:geo (40.442673 -79.945815) ] }. in RDF/XML, that'll use parseType="Collection".

14:53:08 <masaka> is it turtle ?

14:53:29 * DanC forgets whether turtle has picked up () or not yet

14:54:02 <DanC> with glist, you can write rules to relate ical:geo to geo:lat adn geo:long without microparsing the ; delimiter.

14:54:07 <ndw> I'm with libby, I think. I want the data to be round tripable, but I'm happy to use whatever structures are most "pleasing" in RDF for the RDF representation

14:55:13 <ndw> glist is certainly an improvement then. microparsers suck.

14:55:14 <DanC> I'm comfortable dispatching to specific RDF structures based on the iCalendar data type, but not on the property. So I'm happy to represent "list of float" naturally in RDF, but not "geo value".

14:55:48 <ndw> Hmm. I think I see your point.

14:56:11 * timbl didn't

14:56:14 <libby> why do you make that distinction DanC?

14:56:23 <DanC> my comfort is based on having implemented the conversion twice now...

14:56:26 <timbl> This is because of scrapiong the iCal spec?

14:56:50 <ndw> I imagined that it was a case of wanting to write a converter based on data types but not having to special case individual properties

14:56:51 <DanC> the first conversion dispatched on property name, and it was a mess. The current version dispatches on the property type, and I'm much more confident that it's maintainable.

14:57:02 <DanC> roughly, yes, because of the scraping experience.

14:57:17 <DanC> s/property type/value type/

14:57:24 <timbl> So what data type does location have?

14:57:50 <DanC> list of float

14:57:57 <ndw> From 2445: geovalue = float ";" float

14:58:19 <DanC> which I scraped as: [[

14:58:19 <libby> isn;t location different? a string?

14:58:21 <DanC> <dd class='ValueType'><a rel='list-of' href='#Value_FLOAT'>FLOAT</a> <pre> . The value MUST be two SEMICOLON separated FLOAT

14:58:21 <DanC> values.

14:58:22 <DanC> ]]

14:58:33 <timbl> sorry I meant geo

14:58:50 * ndw discovers he's double booked. His attention will be divided henceforth.

14:59:01 <masaka> location is TEXT

14:59:02 <DanC> D:ndw is double-booked, actually

14:59:03 <dc_rdfig> Added comment D11.

14:59:12 <timbl> Ok, that makes sense. It means that the s=yntactic mapping becomes very direct and low cost.

14:59:51 <DanC> right. the dispatching code is in doProperties in http://www.w3.org/2002/12/cal/fromIcal.py

15:00:02 <libby> what's your opinion masaka?

15:00:06 <chaalsMEL> So the point is to work with them both as useful things, or just how to build the conversions?

15:00:16 <timbl> But then we nened to talk about a better vocab for exchanging things.

15:00:17 <DanC> both what, chaalsMEL?

15:00:47 <DanC> re better vocab: I tend to use cyc. (thought I'm evaluating SUMO)

15:00:49 <masaka> I think it's desirable to use geo: vocab to describe coordinates

15:01:08 <timbl> Do you really want streams of calandar data on the planet propagating the ical:geo(x y) form, or do you want peopl eto use geo:lat and geo:long for interchange?

15:01:16 <timbl> iCal:location [ geo:lat 40.442673; geo:long -79.945815].

15:01:21 <chaalsMEL> both location and geo

15:01:29 * libby would prefer the geo:

15:01:38 <DanC> yes, it's desireable to use geo: vocab to describe coordinates. But somebody who published a .ics file did not license the use of the geo: properties. So I don't think fromIcal.py should emit them.

15:01:49 <chaalsMEL> I agree that it is preferable to use the geo: vocab for lat/long

15:02:31 <chaalsMEL> But that sort of gets to the question of whether we want the iCal vocab to be a literal model of RFC2445

15:02:35 <timbl> Can one not use the wording in the Icalendar spec to connect to the geo: definitions of lat and long and show that that IS what they meant?

15:02:37 <DanC> iCal:location is a misnomer, timbl. The spec makes it clear that it's a location name.

15:02:51 <timbl> Ok, lets drop location. my fault.

15:02:55 <DanC> indeed, one can not, timbl.

15:03:06 <chaalsMEL> I think that someone who publishes .ics licensed the use of a way of describing latitude and longitude.

15:03:39 <libby> I think this is avery important question...and we did make a decision to stick very closely to icalendar spec

15:03:39 <DanC> in particular, the w3.org/200X geo vocab is specific about its coordinate system. ical:geo is not.

15:03:51 <timbl> iCalendar makes no mention of the coordinate system? I huess we could ask for it as an erratum?

15:04:06 <DanC> I'm not interested in changing the iCalendar spec.

15:04:09 <chaalsMEL> So this is a practical problem with emitting geo: coordinates.

15:04:14 <timbl> Or establish a best practice.

15:04:56 <timbl> Have we got best practice recommendations in other areas, to make this work?

15:05:04 <libby> they are thinking od revisong rfc 2445

15:05:08 <DanC> "other areas"? "this"?

15:05:41 <timbl> I wonder whether the use of iCalendar has to be profiled to make the RDF version useful.

15:05:45 <DanC> Ol, are you tracking any revision work on RFC2445? I'm only interested in revision work if the implementors are likely to upgrade their software.

15:06:38 <chaalsMEL> So we could assume that the two floats represent a lat/long pair (without formal justification beyond "everyone would do it that way"). That would be a logically dangerous assumption to underpin converting to geo: but would it be unsound in practice?

15:07:24 <DanC> perhaps not unsound, but it would be a very different way of building an icalendar schema. I'd argue for changing the namespace URI.

15:07:49 <chaalsMEL> Or we could make something like ical:geo to hold these things, and tell people that they are probably equivalent in practice to geo: but we can't really be sure.

15:08:07 <DanC> we can publish rules to convert them, and folks can either use the rules or not.

15:08:34 <libby>http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Mar/0023.html

15:08:35 <dc_rdfig> G: http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Mar/0023.html from libby

15:08:53 <libby> G|Status of Calendaring and Scheduling Consortium

15:08:55 <chaalsMEL> And we let the market decide - if people use the rules the de facto argument strengthens.

15:09:19 <DanC> of course, the market tends to do what's easiest, and not using the rules is easier than using them.

15:09:33 <libby> G:fwded mail from the ietf calch list. [consortium main site|http://www.calconnect.org/]

15:09:33 <dc_rdfig> Added comment G1.

15:09:35 <DanC> but yes, if people bother to use the rules, that's info.

15:10:17 <chaalsMEL> Well, if there is value in the existing stuff of geo: then one might expect that people use the rules (one way or another).

15:10:18 <libby> the rules to me are crucial - I don;t really care what our converter does, but I do want to know how to connect foaf and geo to ical

15:10:31 <chaalsMEL> For example, I can get geo: data for airports.

15:10:41 <libby> if we knew the rules, we could do a bit of rdf and have people copy it

15:11:05 <chaalsMEL> And to some extent I can figure out what timezone a particular geo:lat / geo:long is in.

15:11:25 <timbl> I think iCal as an ontology should come with a health warning: "We actually thing geo is betterfor lat and long. IOf you are using the standard coordinates, you should use geo for interchange, not ical".

15:11:32 <chaalsMEL> If I travel from point A to point B those are likely to be useful assumptions to have made.

15:12:00 <GNUPredator> GNUPredator is now known as mdupont

15:12:33 <chaalsMEL> It seems that we can license converting geo:lat / geo:long pairs into .ics GEO: data, no?

15:13:01 <chaalsMEL> One question is whether there are tools that currently do anything useful with that data.

15:13:49 <chaalsMEL> In iCal I have a location field (which I tend to fill with some nearest airport magic that only I can decode - air:MEL or air:LON or air:NCE are common values I put in that.

15:13:49 <timbl> I think the geo folks should be pushing on iCalendar for an erratum. there are going to be millions of phoneCalendarGPSCameras putting lat long in EXIF on photos. I wonder what EXIF says about coordinates.

15:14:01 * DanC finds the health warning appearling; wonders where to put it

15:14:40 <libby> masaka, have you looked into exif and lat/long at all?

15:14:46 <DanC> I have tools that make use of geo:lat and geo:long to draw things like http://www.w3.org/2004/04dc-ams/itin-ams-img.png . I think Jibbler has some too.

15:14:55 <LotR> how does the rfc not sufficiently describe how GEO maps to lat/lon?

15:14:56 <chaalsMEL> I have too.

15:15:30 <chaalsMEL> (Mine included "watch jibberjim do this better in javascript in 25 minutes" in the todo list. and he did &-\

15:15:47 <masaka> something like gpsLatitude, gpsLongitude in Exif

15:15:49 <Jibbler>http://www.jstott.me.uk/coord/

15:15:50 <dc_rdfig> H: http://www.jstott.me.uk/coord/ from Jibbler

15:15:56 <chaalsMEL> But are there tools that use .ics GEO pairs?

15:15:57 <DanC> re best practices, I think date and dateTime values need a lot more work than geo. I don't really expect a calendar ontology to give me an optimal lat/long representation, but I do look to it for how to model time.

15:16:26 * chaalsMEL puts modelling time onto the agenda

15:16:33 <timbl> You mean, like insisting that timezones are defined if used?

15:16:45 <chaalsMEL> D:Agenda topic - should we keep with the pattern of trying to exactly model RFC2445

15:16:47 <dc_rdfig> Added comment D12.

15:17:13 <chaalsMEL> D:Agenda Topic - how to model dates / times

15:17:13 <dc_rdfig> Added comment D13.

15:17:19 <timbl> modeliong time - what problems, danc?

15:17:21 <DanC> er.. RFC2445 already insists that timezones are defined and used. it doesn't insist that they're shared, though. that might be a step forward.

15:17:44 <libby> can I also request an agenda topic of which rules/mappings to differenbt vocabs we recommend (if we do)?

15:17:54 <DanC> the problems you raised in http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Mar/0016.html , timbl. iCal:tzid doesn't follow the InterpretationProperties pattern.

15:18:00 <chaalsMEL> sure. You can add it even

15:18:37 * DanC has heard libby ask about different vocabs lots of times, but hasn't yet understood it in concrete terms. hopes to.

15:19:09 <timbl> Would there space on this agenda to do the tzid issue anyway?

15:19:22 <chaalsMEL> how long do you want to go for?

15:19:32 <chaalsMEL> .time AET

15:19:32 <datum> Sorry, I don't know about time zone AET.

15:19:39 <chaalsMEL> .time AEST

15:19:40 <datum> Sorry, I don't know about time zone AEST.

15:19:47 <chaalsMEL> .time JST

15:19:48 <datum> Thu, 08 Apr 2004 00:19:48 JST

15:20:05 <chaalsMEL> that's an hour behind me.

15:20:19 <chaalsMEL> I would like to get some agreement on ways to handle geo information.

15:20:20 <libby> can postpone mine ot another day if you like

15:20:27 * libby a bit meetinged out today

15:20:31 * DanC was thinking roughly 14:30-16:00 UTC

15:20:35 <chaalsMEL> Does anyone know of any icalendar tool that uses the GEO information?

15:20:55 <libby> apple ical uses location - text

15:21:02 * chaalsMEL suggests lib put it on the agenda, and we can at least note we didn't get to it.

15:21:13 <libby> ta

15:21:34 <libby> my phone uses location text too

15:21:37 <paulc> we are looking at incorp lat/long and are looking for best practices

15:21:44 * DanC re-reads http://kanzaki.com/works/2004/cal/0406vocab.html to see if mk had any suggestsion on how to exploit the geo: properties

15:22:12 <chaalsMEL> Proposal: If no tool actually uses this data we refer to our guiding principle of caring about actual real-world data, and assume that the only useful values for GEO are degrees latitude and degrees longitude, and state that if there is other data we are not going to understand it.

15:22:19 * timbl notes ... http://www.exif.org/proposals/location.html EXIF

15:22:21 <libby> D:agenda topic which rules/mappings to different vocabs we recommend (if we do)?

15:22:21 <dc_rdfig> Added comment D14.

15:23:34 <chaalsMEL> The proposal suggests that it is reasonable in light of actual practice to map GEO into lat/long, based on the (admittedly logically untenable) assumption that it is that type of value.

15:23:37 <DanC> so timbl, would you expect an RDF exif schema and an RDF icalendar schema to share lat/long properties? that involves pre-coordination, no? I was assuming post-hoc mapping rules.

15:23:55 <masaka> RFC 2445 says The property value specifies latitude and longitude" ...

15:24:24 <chaalsMEL> Masaka, does it explain what units should be used?

15:24:26 <DanC> what do you mean by "map GEO into lat/long", chaalsMEL? RFC2445 already says geo is a lat/long pair. We're talking about which RDF properties to use to represent the lat/long.

15:24:34 <timbl> Well, i would like the exchanged data to use a consistent vocab for something as common as wgs84:lat

15:24:55 <timbl> That means you have to either switch it implciitly or explicitly.

15:24:59 <DanC> yes, well, is what you'd like all that relevant?

15:25:08 <timbl> I think at this stage it might be posible to just finesse the whol thing.

15:25:28 <DanC> finesse the whole thing? precoordinate the whole semantic web??!?!?!

15:25:44 <timbl> Well, we are laying down frameworks to enble information exchange thrugh interoperabl estnadrds.

15:25:55 <timbl> We are at a point where we chosie one std or 8.

15:25:56 * DanC thought we were modelling RFC2445 in RDF

15:26:12 <timbl> Exactly.

15:26:28 <masaka> RFC 2445 "The longitude represents the location east or west of the prime meridian as a positive or negative real number, respectively."

15:26:29 <chaalsMEL> Does RDF care about which particular namespace some property or other is in?

15:26:33 <timbl> We are asking, "what does the geo: field mean?"

15:26:44 <DanC> I'm not asking what it means.

15:26:45 <timbl> (charles, no)

15:26:51 <timbl> "modelling"?

15:27:09 <DanC> I'm asking how to preserve the intent of somebody who wrote a .ics file when converting it to RDF.

15:27:35 <DanC> and I don't expect somebody who wrote a .ics file to have heard of the geo: namespace.

15:27:36 <chaalsMEL> Masaka, so in principle it would be possible to suggest that greenwich is at GEO:xyz;2pi;

15:27:43 <timbl> Suppose in 99% of cases, the intent was WGS84 coords as they got it from a GPS.

15:28:00 <LotR> DanC: do you expect someone who wrote an .ics file to have heard of rdf then?

15:28:04 <timbl> And that info is only useful if you know that.

15:28:20 <LotR> chaalsMEL: no

15:28:43 <chaalsMEL> (if you express 2pi as 6.28.....)

15:29:07 <DanC> no, I don't expect someone who write a .ics file to have heard of RDF, but I expect them to understand the concepts of "from A&B, conclude B" and "from P(a) conclude there exists some x such that P(x)".

15:29:08 <LotR> chaalsMEL: GEO takes two float values

15:29:19 <libby> I don't think GEO is used in (m)any icalendar implementations. maybe we shold go find out if it is many or any

15:29:29 <libby> if none, then it may not matter so much

15:29:51 <timbl> I suspect we have a large communty who are just about to put masses of data onto things like photos, and I hope that it will all have the same coordinate system. The advent of cheap GPSs has done that. To encourage people to use a differenmt, vaguer vocab would be counter-productibe from the geo point of view.

15:30:13 <LotR> where is geo: defined?

15:30:17 * chaalsMEL asks for a timeout of 1 minute.

15:30:21 <DanC> the 99% question is interesting, but I'm only interested in conclusions that are licensed thru the web: from the .ics mime type registration to RFC2445.

15:30:59 <chaalsMEL> Are these fair summaries?

15:31:30 <libby> lotr, geo is at http://www.w3.org/2003/01/geo/ and thereabouts

15:31:51 <DanC> you're trying to precoordinate that large community, timbl. I don't want to do that in this case because I don't expect it to work very often.

15:32:28 <chaalsMEL> DanC, are you suggesting that it is important that converts a .ics to a single RDF vocabulary, accurately representing in RDF what the .ics means according to RFC 2445 (and no more or less)?

15:33:05 <DanC> pretty much, yes. A single RDF vocabulary seems necessary and sufficient.

15:33:16 <chaalsMEL> Libby, is the question of whether such a vocabulary should be a single one, or can be several cobbled together similar to what you mean by your agenda item?

15:33:38 <LotR> DanC: why is a single vocabulary neccesary?

15:33:47 <DanC> er... that is: you need at least one RDF vocab to do the mapping, and you don't need more than one.

15:34:16 <chaalsMEL> Does anyone disagree that a single vocabulary is, in principle, sufficient?

15:34:28 <timbl> sufficient to?

15:34:32 <libby> I think you could do it with 2 new ones if you felt like it

15:34:41 <libby> I think the issue is reuseing a vocab

15:34:44 <timbl> sufficient to boostrap the us of ical data, yes

15:34:47 <chaalsMEL> Does anyone agree that a single vocabular is necessary - that is that there should be only one namespace used to represent .ics

15:35:22 <DanC> I don't think a single is necessary.

15:35:24 <chaalsMEL> ...rather than mixing 2 or more namespaces to capture different parts of an .ics file?

15:35:43 <timbl> So how do I licence something to draw a map from my iCalendar? Do I need a new vocabulary to say "That is a calendar which uses WGS84 coordinates"?

15:35:43 <chaalsMEL> I think it is sufficient but don't think it is necessary

15:36:11 <chaalsMEL> Tim, do you think a single vocab is necessary?

15:36:32 <DanC> timbl, RFC2445 licenses you to draw a rough map.

15:36:34 <timbl> Chaals, question is ambiguuous

15:36:35 <masaka> if two namespaces, ics -> rdf conversion becomes complicated

15:36:58 <chaalsMEL> Tim, do you think that we should be aiming to convert .ics to exactly one namespace?

15:37:03 <DanC> RFC2445 just doesn't allow you to say what the difference between 23.003 and 23.0030001 latitude is.

15:37:53 <chaalsMEL> masaka, agree. But there might be valid reasons to buy into that complexity. (The one DanC just mentioned is one I think is very important)

15:37:58 <timbl> (ChaalsMEL, it isn't obvious now. I am inclined to think yes. With a health warning)

15:37:59 <DanC> i.e. an RFC2445:geo value couldn't be used in a court of law to settle a property dispute over whether a fence was allowed to be 3 meters east of the creek.

15:38:40 <timbl> In a court or law wouldlook at the intent of course as well as the spec.

15:38:45 <DanC> but an RFC2445:geo could be used to distinguish between SFO and LAX

15:39:45 * chaalsMEL suspects that 2e2;1e2 is a valid set of real numbers that would cause problems for the SFO/LAX problem, even if you specify units

15:40:05 <timbl> (Hey, we can talk about modeling error bars but let's not now.)

15:40:55 <DanC> I'm quite surprised at the amount of precoordination you think is feasible. timbl. Hmm.

15:41:11 <timbl> I can accept that the goal of thhe namesapce is to do a syntactic mappig.

15:41:12 <LotR> DanC: it's perfectly ok to put 23.0030001 in an .ics file (or weren't you saying you couldn't?)

15:41:14 <chaalsMEL> Is it a problem that rfc2445 doesn't specify how accurate geo numbers are?

15:41:42 <DanC> you can put that in the file, LotR, but RFC2445 doesn't tell you which blades of grass are north or south of it.

15:41:43 <timbl> precoordination?

15:42:03 <chaalsMEL> LotR the problem is that you can put anything you like. Since you can't define a point, but only a region of arbitrary precision, it is difficult to use.

15:42:04 <DanC> precoordination: getting EXIF-in-RDF and icalendar-in-RDF to share lat/long properties.

15:42:15 <LotR> DanC: why not? and how does the geo: spec do tell you?

15:42:37 <timbl> Why not? XML and N3 share unicode.

15:42:40 <chaalsMEL> For example I can use the GPS location of the General Post Office in Melbourne - front entrance, as the location where an event happens.

15:43:10 <chaalsMEL> Do I mean that it isn't happening inside? Or do I mean that it is happening all around greater Melbourne?

15:43:10 <DanC> the geo: spec is tied to a pretty high resolution measurement of where you are on the globe; the one used in GPS thingies. "blades of grass" was an exaggeration, but I think "isles in the grocery store" would not be.

15:43:43 <chaalsMEL> about 2 metres resolution, or 6 feet.

15:44:02 <DanC> XML was established in 1998. N3 came out years later.

15:44:37 <timbl> (I think in general we have to leave treatment of accuracy to another day, Chaals. )

15:44:38 <DanC> And I'm not saying you're wrong, timbl; I'm just surprised... letting the idea sink in. It's new to me.

15:44:42 * chaalsMEL wonders if others are watching or nodding off.

15:45:19 <masaka> example in RDF 2445 "GEO:37.386013;-122.082932" is quite precise

15:45:34 <LotR> DanC: so all this fuss is about the ical spec only requiring support for values with six decimal places and no more?

15:45:58 <timbl> s/:/,

15:46:04 <DanC> no, LotR. I don't seem to be able to explain what I mean.

15:46:12 <LotR> indeed :)

15:46:19 <chaalsMEL> TimBL, if DanC is happy to defer accuracy to another day, that would be fine. But it seems to be what is holding us up here, and I think there are good underlying reasons for explicitly identifying it as something that should be considered

15:46:37 <timbl> No, its notr what is holding us up.

15:46:39 <timbl> IMHO

15:46:59 <LotR> well, you can ignore me if you like :)

15:47:06 <timbl> We areheld up by knowing how useful it would be if EIF and Ical would quote WGS 8 4.

15:47:13 <chaalsMEL> DanC: Do you mean that the variable accuracy allowed by rfc2445 does not license the particular accuracy defined by geo:

15:47:14 <timbl> It is coordinate system, not accuracy.

15:48:04 <masaka> geo: also doesn't define accuracy

15:48:44 <timbl> We can either say "here is an ontology for calendar events: it is like iCalendar but it does require that yoiu use standard coordinates for geo:" or we can say "this is just what the icalednar spec says".

15:48:50 * DanC is torn between exploring the geo/calendar mixing aspects and exploring the best-practices-for-time issue

15:49:11 <DanC> bingo, timbl.

15:49:17 <chaalsMEL> DanC: Are you saying that rfc2445 GEO information doesn't match geo: ?

15:49:26 <DanC> yes, chaalsMEL

15:49:54 * chaalsMEL notes that if DanC hadn't given up the chair he could indulge his torn state and try to drag us with hime :-)

15:50:42 <DanC> have we properly celebrated the release of the C# parser, btw?

15:50:50 <DanC> I suppose we did that last time.

15:51:02 <DanC> but you can never celebrate too much ;-)

15:51:31 <chaalsMEL> If they did match, then could we just use geo: which is well-known (let's assume it is) and have a simpler life where more things fitted? Would that be a good thing?

15:51:55 <chaalsMEL> I agree, we haven't celebrated the C# parser enough. Nor many other things.

15:52:18 <timbl> Ooooh exif does include degrees of precision on a GPS measurement.

15:52:49 <timbl>http://www.exif.org/specifications.html

15:52:49 <dc_rdfig> I: http://www.exif.org/specifications.html from timbl

15:52:53 <chaalsMEL> I don't think degrees of precision is enough. People mean a region when they give a point...

15:52:59 <timbl> I:|EXIF specifications

15:52:59 <dc_rdfig> Titled item I.

15:53:00 <LotR> DanC: if they don't match, how don't they match?

15:53:13 <DanC> yes, chaals, from a utilitarian viewpoint, we get more efficient information exchange if exif and calendar share geo: property URIs.

15:53:20 <timbl> I: EXIF 2.2 includes fairly comprehensive GPS measurement ontology.

15:53:20 <dc_rdfig> Added comment I1.

15:54:23 <chaalsMEL> Sufficiently utilitarian to spend some meeting time thinking about whether we can justify trying to find a reason why, in practice, they are used to mean the same thing?

15:54:46 <DanC> hmm... I was going to quote RFC2445 to show how it's different from the geo/WG8 schema, but I see that RFC2445 is grounded in some FIPS standard. (http://www.w3.org/2002/12/cal/rfc2445#sec4.8.1.6)

15:55:09 <chaalsMEL> or just a way to save a handful of programmers 5 minutes doing something that is second nature anyway?

15:55:46 <DanC> I wonder if FIPS 70-1 cites WG8

15:56:25 <chaalsMEL> Does anyone think that DanC's concern about the difference between rfc2445 and geo: is worth pursuing?

15:56:46 * chaalsMEL includes DanC in the audience of that question...

15:56:55 * LotR is still wondering what the difference is :)

15:57:17 <chaalsMEL> I am wondering what it is, and thus so consider it worth pursuing.

15:57:20 * DanC is implemeting glist

15:57:58 * timbl follows icalendar "Department of Commerce, 1986, Representation of

15:57:58 <timbl> geographic point locations for information interchange (Federal

15:57:58 <timbl> Information Processing Standard 70-1): Washington, Department of

15:57:58 <timbl> Commerce, National Institute of Standards and Technology"

15:58:25 * chaalsMEL considers, in the context of a meeting about to wind up, that that means DanC is not intersted in pursuin the question.

15:59:18 <DanC> paulc, if we change how timezones are represented in rdf-calendar, I expect that would have considerable impact on eventSherpa, yes?

15:59:43 <chaalsMEL> So it looks like, if "we" want to use geo: "we" should make ourselves some rule to convert dan's glist to geo.

15:59:45 * libby gotta run in a sec, any ideas about next meet?

16:00:16 <timbl> € FIPS 70-1, Representation of Geographic Point Locations for Information Interchange (ANSI X3.61-1986) was officially withdrawn as of 1997, as per http://www.itl.nist.gov/fipspubs/33fipwd.htm

16:00:32 <chaalsMEL> This agendum is closed with no resolution - DanC seems to have lost interest in discussing it, and is coding his way.

16:00:39 <chaalsMEL> Next meeting?

16:00:57 <DanC> swBot, please suggest a time that either libby or dan is available, and that 3 others are available.

16:01:02 <libby> :)

16:01:09 <dajobe> wishBot ;)

16:01:11 <libby> cant do 2 weeks - xmleurope

16:01:13 <ndw> Hey, if we had calendar data...

16:01:15 <ndw> :-)

16:01:40 * chaalsMEL thinks ndw should stop dreaming like that.

16:02:06 * chaalsMEL assumed that he could do 2 weeks because XML Europe will be finished by lunchtime.

16:02:10 <DanC> I looked at implementing that sort of "please suggest a time..." thing, and the hardest part is counting 3 people. It's really hard to prove that ?X and ?Y are different people.

16:02:10 <chaalsMEL> 3 weeks?

16:02:42 * ndw proposes 05 May at 14:00 GMT just to get the ball rolling

16:02:43 <chaalsMEL> Sure, but if we got a list of the alleged people we could eyeball it to see who is included.

16:03:02 <libby> I think the next time I can make is may 5th

16:03:05 <libby> ah, great

16:03:17 <ndw> That's four weeks because my 28 Apr is a mess

16:03:20 <masaka> sorry I cannot 5 may

16:03:37 <DanC> eyeballing is easy/straightforward. I'm talking about delegating that query to a machine. it's hard. the only way I can think for a machine to tell people apart is if it knows their birthdays and can tell they're different.

16:03:54 <chaalsMEL> I think I can make 28 April evening time GMT, or 5 may

16:04:16 <ndw> Counter proposal, masaka?

16:04:20 * chaalsMEL thinks DanCs algorithm fails when Zsa Zsa Gabor is required at the meeting

16:04:25 <DanC> I'm pretty free 28Apr.

16:04:51 <masaka> hmm both are not good for me, sorry,

16:04:59 * ndw proposes 6 May at 14:00 GMT

16:05:27 * DanC can do 6 may 1400Z but prefers 28Apr

16:05:31 <swh_afk> swh_afk is now known as swh

16:05:34 * chaalsMEL too

16:05:50 * chaalsMEL cannot do 28 apr at 1400Z

16:06:14 <masaka> can do May 6 1400 UTC

16:06:28 * chaalsMEL too. Dan? Libby?

16:06:42 <libby> sorry not sure, maybe

16:07:11 * timbl can do 6 may

16:07:15 <DanC> DanC can do 6 may 1400Z

16:07:29 <chaalsMEL> I suggest we meet 6 May at 1400Z

16:07:29 <libby> nope I can''t but never mind

16:07:40 <chaalsMEL> anyone want to chair?

16:08:02 * DanC is happy to leave chairing in the air

16:09:02 <chaalsMEL> Next meeting: 6 May, 1400Z. Chairing responsibility is in the air (hanging over DanC's head)

16:09:08 * mdupont has a snapshot of the gcc-3-3 from debian that has an introspector patch in it http://sure-swap.biz/mike/introspector-gcc-3.3.3-debian.tgz a3e5f1d4cf4dc5b49db6b99d6a995d85

16:09:14 <chaalsMEL> logger, chump E

16:09:14 <chaalsMEL> E:See [http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-04-07#T16-09-14|discussion]

16:09:42 <DanC> that's 9am Chicago time, per http://www.timeanddate.com/worldclock/fixedtime.html?day=6&month=5&year=2004&hour=14&min=0&sec=0&p1=0

16:10:09 <dc_rdfig> Added comment E1.

16:10:35 <chaalsMEL> D:See [http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-04-07#T16-09-14|end of discussion] for next meeting time - 6 may, 1400Z

16:10:36 <dc_rdfig> Added comment D15.

16:11:00 <CaptSolo> wishBot sounds good :)

16:11:23 <chaalsMEL> yeah, but it is down at the moment. Net problem I think :-)

16:11:34 * chaalsMEL wonders about the chair of Damocles...

16:11:55 <libby> bye guys, thanks chaalsMEL :)

16:13:06 <masaka> I should leave, too. thanks chaalsMEL for chair, thanks all. good night :)

16:13:16 <DanC> yes, thanks, chaalsMEL. hasta, masaka

16:13:25 <timbl> LotR, didn't mean to ignore the imprtance fo accuracy - but it wasn't the vocabulary point

16:13:27 <chaalsMEL> good night all

16:14:00 <CaptSolo> DanC: having a 'dreambot' do that would be very close what timbl described in the SciAm article. still we do not have such bots. yet.

16:14:26 <chaalsMEL> timbl, I was getting the impression that it was a difference underlying the vocabulary point

16:15:23 <timbl> The vocabulary was whether to use geo:lat or not.

16:15:50 <DanC> the accuracy/coordinate system stuff wasn't completely irrelevant, but it wasn't the heart of the matter, IMO

16:16:24 <timbl> the heart of the matter was my summary you bingoed?

16:16:27 <DanC> the heart of the matter is whether the EXIF geo stuff should be precoordinated with the icalendar geo stuff.

16:16:32 <chaalsMEL> Yes, but as I understood it the objection was based on something, and the fact that the accuracy stuff was different was part of the problem.

16:16:37 <timbl> "precoordinated"?

16:17:05 <DanC> precoordinated in the sense that there's a causal connection between them, i.e. it's observable that they weren't developed independently.

16:17:11 <timbl> If EXIF have referred to the WGS84 coordinate system, what is "pre"?

16:17:22 <chaalsMEL> Hmm. I wish I had figured that out. If by happy accident they happen to cover the same stuff, then I don't see the problem.

16:17:46 <chaalsMEL> I'm not interested in where they were developed, except insofar as it implies something about what they actually mean.

16:17:52 <timbl> The observble connextion was the devopment in 1984 (?) by the worlf gergraphic survey (?) of a stnadrd simple coordinate ssytem fro th whol eplanet.

16:18:08 <chaalsMEL> That's not a connection though.

16:18:17 <DanC> yes, it is

16:18:32 <timbl> See http://www.wgs84.com/

16:18:38 <chaalsMEL> the connection is that they are happy to use it.

16:18:51 <DanC> well, ok, yes.

16:19:05 <timbl> If and only if exif and icalendar refernec teh same spec then we don't have to worry.

16:19:12 <DanC> right.

16:19:28 <chaalsMEL> And there doesn't need to be any observable causal relationship there (for my money). Just that they happen by any means imaginable to be talking the same language.

16:19:30 <DanC> because then folks that write .ics files are party to that agreement.

16:19:51 <timbl> iCale references a FIPS (US national) standard which is obsolete, but has since been cooridnated with some ISO stanrad.

16:20:01 <chaalsMEL> If they reference the same spec we don't need to worry.

16:20:07 <LotR> so if that FIPS thing was retracted, shouldn't there be an update to the rfc anyway?

16:21:04 * chaalsMEL thinks LotR, sure. But we should have solved the thing about people being hungry by now, too &-

16:21:11 <timbl> IT/02-0588, Project Proposal to Revise X3.61:1986 (R1997)

16:21:17 <DanC> I don't think it's reasonable to try to judge objectively what folks meant when they wrote .ics files; but if there's an audit trail that shows they agree, we can transcribe it into RDF.

16:21:30 <timbl> Yes, there should be aunpdate to thr RFC in a perfect world.

16:21:52 <chaalsMEL> DanC I doubt *_VERY_* much that folks who _write_ .ics files are party to the agreement

16:22:03 <danbri_dna> software writes files

16:22:07 <danbri_dna> people click stuff

16:22:07 <DanC> then you doubt the way the web works, chaalsMEL

16:22:23 <DanC> people choose software; that makes them party to the specs

16:22:25 <chaalsMEL> Perhaps I doubt your understanding of it?

16:22:33 <timbl> ANSI X3.61

16:22:41 <timbl> ISO 6709

16:22:49 <danbri_dna> DanC, do you ever use Apple ichat?

16:23:06 <danbri_dna> apparently it has some Jabber (+ rendevous extensions) hidden inside...

16:23:17 <chaalsMEL> People choose software - that means that their behaviour is going to have certain results.

16:23:22 <danbri_dna> often people've no idea what specs their software uses. even geeks.

16:23:30 <LotR> DanC: but people want stuff to DWIM, not to nitpick about which standard goes where

16:23:31 <DanC> perhaps you doubt my understanding of it, chaalsMEL. But I don't know why you'd work on standards if you didn't think they work this way.

16:23:40 <timbl> Phhht ...Add to shopping basket ISO 6709:1983 PDF version (en) CHF 40,00 952 KB

16:23:54 <DanC> yes, I use Apple iChat now and again.

16:24:18 <chaalsMEL> Hmm. (Note that I am not at all sure I doubt your understanding, since i don't really know what it is)

16:24:27 <danbri_dna> are you party to the Jabber spec?, in same sense as re ical above?

16:24:36 <timbl> LotR - I think DWIM means do what my GPS does. It would be nice to find a standards argument that that is what the std measn too.

16:24:38 <DanC> indeed, people have no idea about how the specs work. They're still party to them, just like I'm party to all the laws of Overland Park. I haven't read them, but by choosing to live here, I become party to them.

16:24:40 * danbri_dna ducks out of this debate, got a talk to finish! sorry...

16:24:45 <danbri_dna> ok

16:25:15 <chaalsMEL> I work on standards because I think that without good standards people are likely to keep choosing (or being given, as most people are) software that doesn't have a hope of matching their behaviour to the results they were hoping for.

16:26:34 <chaalsMEL> And because I think it is very important that the standards that are developed take account of the fact that they are going to be implemented by people, who are also going to use the resulting products

16:27:01 <chaalsMEL> (or rather the developers of the standards, as a group, take account of such concerns)

16:27:47 <chaalsMEL> The legal example is an interesting one. Because you didn't read them you have no real proof that what you do is in conformance with them.

16:27:49 * timbl has to go.

16:28:40 <LotR> DanC: so the problem is really that you're not 100% sure that both representations of lat/lon are 100% compatible, not that you know for a fact that they aren't?

16:28:45 <chaalsMEL> If they're well written, then you probably are by default and a basic level of understanding. But it may be that you explicitly reject things that turn out to be there in black and white, only because it never arose as an issue in your implementation you never noticed.

16:28:59 <DanC> right, LotR.

16:29:21 <LotR> but it does look a *lot* like they are the same, right?

16:29:39 <DanC> well, no

16:30:01 <LotR> hmm? why not?

16:30:16 <DanC> to me they're the same not when I sorta read them and understand them to mean the same thing, but when I can find an audit trail connecting them.

16:30:25 <chaalsMEL> I think it looks more like they are the same in usage than in specification (because in usage you don't follow a reliable paper trail - you just compare some stuff and guess that it is all like that :-)

16:30:48 <LotR> DanC: I didn't say 'are the same' but 'look like they are the same'

16:31:23 <DanC> er... well, I don't know how that's relevant.

16:31:41 <DanC> I'm writing software to convert from .ics to .rdf, and I want to be sure it preserves meaning.

16:31:49 <LotR> it isn't relevant in that it will get us closer to a solution, no

16:32:03 <chaalsMEL> LotR, I think DanC is applying a value of "look the same" that is like the one RDF has. If you have some reason to believe they are the same, they look the same. If you don't see a reason, they don't look the same...

16:33:02 * DanC puts aside fun coding to get an RDF DAWG agenda out...

16:33:59 * DanC hopes to get to the airline foo before too much longer

16:34:05 <chaalsMEL> Which is from logical principles a sensible argument.

16:35:43 <chaalsMEL> I think you and I are taking an approach that if you look at the data there seems to be the same stuff there and we can probably justify, from that, assuming that they are understood in practice as the same thing.

16:36:26 <chaalsMEL> as Dan said before, that isn't all that tenable in a world where you rely on standards. (And where RFC's are actually updated, and have stable URIs, and :-)

16:37:09 <LotR> *nod*

16:37:38 <LotR> the ical people are too busy bickering about CAP to update the rfcs I think :(

16:38:35 <DanC> hmm... well, if we can get RDF data access done soon enough, then maybe it'll obsolete CAP ;-)

16:38:58 <DanC> hmm... 1/2 ;-)

16:39:20 <jsled> def CPA?

16:39:24 <jsled> er ... CAP

16:39:32 <LotR> Calendar Access Protocol

16:39:38 <jsled> um ... http?

16:39:47 <LotR> no

16:40:03 <LotR> ITIP over BEEP over TCP

16:40:11 <LotR> or something like that

16:40:16 * jsled shudders

16:41:26 <LotR> there's a recept proposal to use DAV

16:41:39 <DanC> oh really?

16:41:50 <LotR> as an alternative

16:41:58 <LotR> not to replace it

16:42:19 <LotR> don't you guys read/skim ietf-calendar?

16:43:26 <DanC> no

16:43:34 <DanC> well, I look at the archives on occasion.

16:43:52 <DanC> I only read mail that I'm obliged to. And there's LOTS of that.

16:44:04 <LotR> heh, ok

16:44:53 * LotR mostly just saves it to his ietf-calendar folder too since he stopped working on Net::ICal

16:45:18 <sh1mmer> Saving mailing lists into folders is all too easy

16:45:45 <LotR> I know

16:46:06 * DanC is tempted to discuss email handling, but must get this WG agenda out...

17:22:26 <DanC> hmm... I'm ready to test fromIcal.py on GEO: data, but we don't have any tools that make GEO data

17:23:12 <chaalsMEL> Yerr. That was the thrust of my usage argument.

17:23:33 <chaalsMEL> The only tools I know of that have the data come from the RDF side

17:23:43 <chaalsMEL> (like the airport data stuff)

17:24:00 * DanC feels kinda silly

17:25:44 <DanC> I'm gonna use GEO:40.442673;-79.945815 from http://kanzaki.com/works/2004/cal/0406vocab.html

17:27:53 <DanC> fromIcal.py:417: UserWarning: @@value type ('FLOAT',) not implemented (GEO: 40.442673;-79.945815)

17:28:07 <DanC> ok, good so far...

17:30:02 <LotR> DanC: maybe you should write an email to ietf-calendar, asking them to shine some light on the issue

17:31:03 <DanC> I prefer to treat RFC2445 as an immutable black box

17:31:24 <DanC> only observable thru (a) the text and (b) the implementations that claim to conform to it

17:32:31 <LotR> yes, but if you can't get at that spec that GEO was written about, maybe they can say if it referenced the geo: spec

17:32:59 <LotR> I didn't mean get them to change the text

17:33:54 <LotR> also, they may know of more implementations than you do. so maybe they'll even have a source of GEO properties

17:34:07 <DanC> ah... yes, the history might be interesting. I still don't feel any more obliged than you to send such a mail message ;-)

17:34:48 <LotR> well, I'm not the one working on an rdf spec that wants to follow the rfc :)

17:35:15 <DanC> you're not?

17:35:28 <LotR> no, I'm just an interested observer

17:35:46 <DanC> you're doing more than observe

17:36:19 <LotR> well, I ask questions if what I see isn't clear to me

17:37:50 <LotR> but I'm not actively doing anything

17:38:14 <chaalsMEL> LotR, big mistake. you just qualified yourself to ask questions of the IETF group - especially since you are aware of who they are...

17:40:24 <DanC> ew... how do you write ("a" "b") in RDF/XML?

17:40:45 <DanC> can't use parseType="Collection". gotta use first/rest. ugh!

17:42:09 <DanC> <#what> <#is> ("a" "b"). becomes... [[

17:42:17 <DanC> <rdf:Description rdf:about="#what">

17:42:17 <DanC> <is rdf:parseType="Resource">

17:42:17 <DanC> <rdf:first>a</rdf:first>

17:42:17 <DanC> <rdf:rest rdf:parseType="Resource">

17:42:17 <DanC> <rdf:first>b</rdf:first>

17:42:18 <DanC> <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>

17:42:20 <DanC> </rdf:rest>

17:42:22 <DanC> </is>

17:42:24 <DanC> </rdf:Description>

17:42:26 <DanC> ]]

17:50:55 * sbp gets to work on a URI scheme for RDF literals, then

17:53:29 <sbp> hmm. 'literal:' ( '@' lang | '^^' base32enc(dtypeURI) ) ':' hexEncode(value)

17:53:51 <sbp> I wonder if one can fudge datatype URIs to include character encoding information?

17:54:53 <DanC> why bother with literal: , sbp? the above syntax is obnoxious, but it's pretty widely deployed.

17:55:40 <sbp> yeah, I'm just kidding. but it has led me to wonder whether datatype URIs couldn't subsume lang information too and eliminate the need for it

17:56:10 <sbp> the choice of lang and dtypeURI seems a little arbitrary. what about character encoding, MIME type, and the like?

17:57:22 <DanC> MIME type would be a step backwards. datatype URI is a URI.

17:58:15 <sbp> but it's pretty widely deployed

17:59:16 <DanC> really? what's the MIME type for float? double? date?

18:00:42 <sbp> I see your point. I could ask the same about URIs for all the currently deployed MIME types, but there are canonical ones... I guess I concede. but my point against character encoding being left out in lieu of language still stands

18:01:23 <sbp> hmm, literals are sequences of unicode characters

18:01:42 * sbp watches his entire argument evaporate

18:02:45 <sbp> I was just aiming for synchronicity with data: URIs, which use MIME and charenc of course

18:03:50 <DanC> URIs for text/plain and the like aren't as established as I'd like. and the charset foo in RDF literals is messy.

18:05:12 <DanC> ok, I've got list-of-float support working in fromIcal.py ... feel like adding support in toIcal.py , sbp?

18:05:23 <sbp> they're catching on a little thanks to the resurgence in love of all things standardsy; HTTP PUT too. I see people using "data:" URIs in stylesheets now

18:05:38 * sbp takes a look at (to|from)Ical.py

18:06:07 * DanC hasn't finished checking fromIcal.py in yet

18:09:51 <sbp> which file in /2000/10/swap/pim would you advise testing toIcal.py on?

18:10:23 <sbp> (or on the Web, since it accepts URIs)

18:12:04 <DanC> umm... I just checked in http://www.w3.org/2002/12/cal/test/geo1.ics ...

18:12:08 <DanC> lemme check in the .rdf ...

18:13:11 <sbp> thanks

18:13:51 <DanC> there .http://www.w3.org/2002/12/cal/test/geo1.rdf

18:14:18 <DanC> (cited from updated http://www.w3.org/2002/12/cal/fromIcalTest.py)

18:16:35 <sbp> File "toIcal.py", line 43, in ?

18:16:35 <sbp> from fromIcal import iCalendarDefs # http://www.w3.org/2002/12/cal/

18:16:35 <sbp> ImportError: No module named fromIcal

18:16:58 <DanC> you need 2002/12/cal in your PYTHONPATH. sucks.

18:18:34 <sbp> heh:

18:18:34 <sbp> raise RuntimeError, "value type not implemented: " + \

18:18:34 <sbp> TypeError: cannot concatenate 'str' and 'tuple' objects

18:18:59 * sbp refreshes his version...

18:19:25 <DanC> that seems current.

18:19:50 <DanC> the new type is ('FLOAT') , which is the way I've chosen to represent the 'list of float' type.

18:20:14 <sbp> gotcha

18:20:40 <DanC> hmm... to datatype or not to datatype... i.e. in N3: ("12.3" "32.4") or (12.3 32.4)

18:20:54 <DanC> might as well dataype, yes?

18:21:02 <sbp> yes

18:21:17 * DanC fixes fromIcal.py and geo1.rdf ...

18:23:00 <sbp> oh frabjuous joy. the item passed is a list bNode, apparently

18:23:12 <sbp> File "toIcal.py", line 136, in doFLOAT

18:23:13 <sbp> n = float(str(val))

18:23:13 <sbp> ValueError: invalid literal for float(): run:li2

18:23:33 <DanC> what did you expect?

18:23:49 <sbp> to not have to completely redesign the code... :-)

18:24:16 * sbp wonders what sts is, hopes it's something from which he can get the value

18:24:21 <DanC> now you see why I lobbed this work in your direction ;-)

18:24:28 <sbp> right

18:24:37 <DanC> sts is the formula.

18:24:57 <DanC> and yes, you should be able to call sts.the(RDF.first, val)

18:26:28 <DanC> I guess sts was underdocumented. consider adding a comment. is there a pythonic norm for documenting args?

18:26:46 <sbp> not yet

18:27:17 <sbp> sts.the(RDF.first, val) is returning none, and sts.the.__doc__ isn't helping much

18:27:22 <sbp> s/none/None/

18:27:27 <DanC> $ cvs commit -m 'use real datatypes for list of floats, i.e. geo' fromIcal.py test/geo1.rdf

18:28:02 <DanC> I dunno if those args are right; I assumed you were familiar with the cwm each/the/any API

18:28:35 <sbp> I am now

18:29:33 <DanC> cf http://www.w3.org/2000/10/swap/formula.html#Formula-the

18:30:30 <DanC> test/geo1.rdf is even uglier now. And you thought it wasn't possible!

18:37:39 * DanC checks in new schema, re-checks for dl-happiness...

18:38:45 <sbp> odd. run:li2 only appears once in the entire formula

18:38:49 <sbp> in this triple: {`test/geo1.rdf`:: run:_g1 geo run:li2}

18:39:53 <sbp> the datatyped value occurs nowhere. the string "first" doesn't appear in the output either

18:40:03 <sbp> which is just a dump of sts._index.get((None, None, None), [])

18:40:04 <DanC> output of what?

18:40:25 <DanC> I get what I expect when I do: $ python ~/w3ccvs/WWW/2000/10/swap/cwm.py test/geo1.rdf --n3

18:40:59 <sbp> I may need to update my CVS

18:41:12 <DanC> did you cvs update geo1.rdf? 1.2 is current

18:42:09 <sbp> I'm taking it directly from the Web

18:44:55 <DanC> ugh. cwm is mangling the conversion of ical.rdf to .n3

18:47:05 <DanC> hmm... this work to support geo as a list of floats is silly in 2 ways: (1) I know of no iCalendar tools that produce nor consume GEO: in a non-trivial way and (2) the list of floats is not the place.

18:47:19 <DanC> but at least this stuff does address the microparsing issues.

18:48:36 <sbp> updating CVS and whatnot; I'll send a patch to public-cwm-talk if I get it all going

18:48:58 <DanC> cool. maybe to www-rdf-calendar too?

18:49:03 <sbp> sure

18:51:14 <DanC> hmm... to datatype or not to datatype is a question relevant to date and dateTime values too. we don't datatype those.

19:03:02 <TechJournalist> does anyone here know of the 'main' channel for W3C discussion?

19:11:31 <adamhill> adamhill is now known as _adamhill

20:37:44 <_adamhill> _adamhill is now known as adamhill

21:14:54 <MacIntyre> MacIntyre is now known as bkdelong

21:42:21 <LTjake> LTjake is now known as LTgone

21:43:39 <Jibbler> H:Convert OS grid refs to long/lat

21:43:39 <dc_rdfig> Added comment H1.

22:15:58 <LTgone> LTgone is now known as LTjake