Chatlog 2009-05-26

From SPARQL Working Group
Revision as of 02:23, 29 May 2009 by Lfeigenb (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

<LeeF> Present: LeeF, Axel, Eric, ivanh, andy, iv_an_ru, kasei, alex, kjetil, simon, john-l, steve, lukewm, bijan, pgearon, Prateek
13:58:40 <trackbot> Meeting: SPARQL Working Group Teleconference
13:58:40 <trackbot>  Date: 26 May 2009
14:02:00 <LeeF> Chair: AxelPolleres
14:02:20 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-05-26
14:02:36 <AxelPolleres2> AxelPolleres2 has joined #sparql
14:02:45 <LeeF> LukeWM, can you scribe today?
14:02:53 <LeeF> You are the highest person on the scribe list who is here right now :)
14:03:15 <LukeWM> sure
14:03:20 <LeeF> thanks
14:03:28 <LeeF> Scribenick: LukeWM
<LeeF> topic: past minutes
14:05:23 <LukeWM> Axel: main focus is talking about update
14:05:40 <LukeWM> Axel: first of all lets approve the minutes from last time & F2F
14:05:54 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-19
14:06:07 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-19
14:06:20 <LeeF> PROPOSED: Approve minutes of F2F1, Day1, Day2
14:06:21 <LeeF> http://www.w3.org/2009/sparql/meeting/2009-05-06
14:06:22 <LukeWM> AxelPolleres2: lets also do the ones from the F2F meeting
14:06:24 <LeeF> http://www.w3.org/2009/sparql/meeting/2009-05-07
14:06:45 <LeeF> RESOLVED: Approve F2F minutes at  http://www.w3.org/2009/sparql/meeting/2009-05-06 and  http://www.w3.org/2009/sparql/meeting/2009-05-07
14:06:57 <LukeWM> AxelPolleres2: OK, next meeting will be tuesday
14:07:20 <LukeWM> AxelPolleres2: next on the scribe list is Chimezie
<LeeF> topic: liaisons
14:07:56 <LukeWM> Axel: now Liason's.  Bijan, anything from Owl?
14:08:12 <LukeWM> bijan: rdftext is ongoing
14:08:30 <AxelPolleres2> q?
14:08:45 <LukeWM> ... owl is going to vote tomorrow, so it would be good to know about anything now.
14:08:56 <bijan> Because of the semantic equivalence between typed rdf:text literals and plain RDF literals in datatype interpretations, the rdf:text datatype is "implicitly defined" by the set of all plain RDF literals, and each plain RDF literal can be understood as an idiosyncratic lexical form for the corresponding typed rdf:text literal. In order not to introduce syntactic redundancy in RDF graphs, typed rdf:text literals must not occur explicitly in published RDF content
14:09:18 <AxelPolleres2> http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec
14:09:19 <LukeWM> eric: the form is "quote" bob "quote" en
14:09:35 <LukeWM> eric: the challenge is mixing 2 specs
14:10:04 <AndyS> One thing still missing : need to say that BGP matching exposes rdf forms, not ^^rdf:text.  
14:10:18 <LukeWM> bijan: if you have an rdf api to e.g. jena, required behaviour is to expose it as a plain literal
14:10:29 <LukeWM> ... can expose it as a typed literal but not required
14:10:42 <LukeWM> ericP: we're on the same page - the form in RDF is a plain literal
14:10:53 <LukeWM> AndyS: you must get back the rdf forms
14:11:02 <ericP> q+ to say doubt that BGPs need to be mentioned
14:11:47 <LukeWM> AxelPolleres2: Asks andy a question
14:11:57 <LukeWM> AndyS: graph is not the right word.
14:12:21 <LukeWM> bijan: Andy, is there something you'd like to include
14:12:30 <LukeWM> AndyS: yes
14:12:45 <LukeWM> bijan: you prefer that to Sparql saying something about it
14:13:06 <LukeWM> AndyS: then you don't end up with a dependency.
14:13:23 <LukeWM> AndyS: Sparql working group can't do every extension.
14:13:39 <LukeWM> AndyS: otherwise everything will come back to SPARQL WG
14:13:45 <AxelPolleres2> q?
14:13:55 <LukeWM> bijan: so, we should include Filter functions etc?
14:14:16 <AxelPolleres2> ack ericP
14:14:16 <Zakim> ericP, you wanted to say doubt that BGPs need to be mentioned
14:14:22 <LukeWM> AndyS: section in Sparql spec tells how to bolt in other entailment regimes
14:15:16 <AxelPolleres2> http://www.w3.org/TR/rdf-sparql-query/#bgpExtend talks about well-formed graphs, not well-formed scoping graphs.
14:15:20 <LukeWM> eric: if there is no special entailment, then we don't need a specific reference to SPARQL.
14:15:43 <LukeWM> AndyS: the case I'm thinking of is SPARQL owl
14:16:16 <LukeWM> AxelPolleres2: I agree we should cover this later, and get back on topic
14:16:28 <LukeWM> AxelPolleres2: anything else from other working groups?
14:16:38 <AndyS_> AndyS_ has joined #sparql
14:17:14 <LukeWM> ivanh: we're still trying to get the right chair for RDB2RDF
14:17:30 <AlexPassant> btw, nothing from the SocialWeb XG - might be interesting contact points later when it comes to authentication in SPARUL
14:17:45 <ericP> q+ to provide some background
<LeeF> topic: F2F #2 at TPAC in November?
14:18:04 <LukeWM> AxelPolleres2: should we hold the next face to face in conjunction with the t-pac in california
14:18:17 <LukeWM> ericP: there are reasons to have it at the hotel instead of e.g. HP
14:19:02 <LukeWM> ericP: Advantage of HP is that we can do a split face to face, advantage of t-pac is running into other folks.
14:19:07 <AxelPolleres2> q?
14:19:12 <LukeWM> ericP: can do 1 day and 1 day at t-pac
14:19:59 <ivanh> I can probably come
14:20:01 <ericP> +1
14:20:02 <LukeWM> AxelPolleres2: Who can come?
14:20:04 <AndyS> Too early to be sure.
14:20:06 <pgearon> +1
14:20:08 <AxelPolleres2> +1 
14:20:09 <SimonS> +1
14:20:10 <Prateek> Too early to be sure
14:20:12 <AlexPassant> probably not
14:20:14 <SteveH> probably not
14:20:15 <kasei> I can probably attend, but not totally certain at this point.
14:20:16 <bijan> Probably not physically
14:20:17 <john-l> Probably not.
14:20:23 <LeeF> +1
14:20:35 <iv_an_ru> probably via phone only
14:20:37 <LukeWM> AxelPolleres2: who can do a 2 site meeting.
14:20:40 <SteveH> depends what the sites were
14:20:40 <bijan> Depends on the site :)
14:21:06 <AlexPassant> 2 sites might be ok - depending on the site as well
14:21:18 <LukeWM> AndyS: I thought the point of TPAC was to meet other groups
14:21:27 <LukeWM> ... so video conference is more irrelevant
14:21:44 <LukeWM> LeeF: I hope it's half own work and half working out coordination parts
14:21:59 <LukeWM> AxelPolleres2: Maybe at that point more people will have joined the group
14:22:22 <LukeWM> ericP: what was the conclusion
14:22:32 <LukeWM> AxelPolleres2: to do with time difference
14:22:39 <LukeWM> ericP: so we do meet at TPAC
14:22:56 <LukeWM> AndyS: 6 people can go, maybe
14:23:23 <AndyS> Are there more on the WBS?
14:23:26 <LukeWM> ericP: Attend 2 days at TPAC?
14:23:39 <LukeWM> LeeF: Let's figure this out in the next few weeks.
14:23:58 <ericP> RESOLVED: plan A is to meet two days at TPAC, though plan A is at risk
14:24:04 <LukeWM> AxelPolleres2: can those who were unsure try to find out.
<LeeF> topic: Update
14:24:36 <LukeWM> AxelPolleres2: Let's talk about update, we already have use cases.
14:24:38 <AxelPolleres2> http://www.w3.org/2009/sparql/wiki/Category:UpdateUseCases
14:25:14 <LukeWM> AxelPolleres2: lets go through quickly. First data integration
14:25:15 <AxelPolleres2> http://www.w3.org/2009/sparql/wiki/DataIntegration
14:25:49 <LukeWM> AlexPassant: each time a new data is created we send a ping to the triple store
14:26:07 <LukeWM> AlexPassant: fetching from ping the semantic web and using LOAD as well.
14:27:16 <LukeWM> AlexPassant: needs to load and create graphs...
14:27:30 <LukeWM> AlexPassant: are they load, additive or replacing
14:27:31 <AndyS> q+
14:27:43 <LukeWM> AlexPassant:  the first is replace, second additive, correct
14:27:46 <LukeWM> AlexPassant: yes
14:28:07 <LukeWM> AndyS: Need to load graphs into store with the name they have in the wild, right?
14:28:10 <LukeWM> AlexPassant: yes
14:28:20 <AxelPolleres2> q?
14:28:24 <LukeWM> AndyS: doing this seems common, so it needs to be natural to do
14:28:26 <SteveH> we do load X into X equivalent a lot too
14:28:27 <AndyS> ack me
14:28:44 <AlexPassant> http://www.w3.org/2009/sparql/wiki/PersonalTagging
14:29:00 <AndyS> Looks to me like a replace as well.
14:29:03 <ericP> q-
14:29:07 <LukeWM> AlexPassant: using insert into graphs and uploading them from the web 
14:29:35 <AxelPolleres2> q?
14:29:51 <LukeWM> AxelPolleres2: Syntax is mix of scripting?
14:30:01 <LukeWM> AxelPolleres2: there is a mix of php etc.
14:30:21 <LukeWM> AxelPolleres2: the php was just so you can llook at the sparql query
14:30:32 <LukeWM> s/AxelPolleres2/AlexPassant /
14:30:53 <LukeWM> AxelPolleres2:  there is no query part involved either?
14:31:02 <LukeWM> AlexPassant: no
14:31:03 <AxelPolleres2> q?
14:31:19 <AxelPolleres2> http://www.w3.org/2009/sparql/wiki/DocUpdateTracking
14:31:29 <LukeWM> AxelPolleres2: next use case is doc update tracking
14:31:40 <LukeWM> pgearon: this has come up a few times with mulgara
14:32:12 <LukeWM> pgearon: need to be able to do queries and construct new blanknodes for every binding
14:32:34 <LukeWM> pgearon:  creates a template structure that starts out empty and contains a load of blank nodes
14:32:51 <AxelPolleres2> q?
14:33:03 <LukeWM> pgearon: people who use mulgara do alot of updates that create blank nodes on the fly
14:33:10 <LukeWM> AxelPolleres2:  it is querying, right?
14:33:32 <LukeWM> pgearon: it's in TQL
14:34:10 <LukeWM> pgearon: and sparql update syntax
14:34:36 <LukeWM> pgearon: uses OPTIONAL/filter !bound to do the equivalent of MINUS
14:34:51 <LukeWM> AxelPolleres2: this is the same as a blanknode in a construct?
14:34:52 <SteveH> that's not what CONSTRUCT does
14:34:56 <SteveH> oh, sorry
14:34:58 <LukeWM> pgearon: yes
14:35:01 <SteveH> yes, it is
14:35:14 <AxelPolleres2> q?
14:35:21 <LukeWM> pgearon: looking at insert, construct and this just about covers doing that.
14:35:24 <AndyS> Unfortunately, need both cases of bnodes.
14:35:39 <LukeWM> AxelPolleres2: any more questions?  Lets go to editing FOAF
14:36:03 <SteveH> LukeWM: talking about http://www.w3.org/2009/sparql/wiki/EditingFoafData
14:36:04 <SimonS> http://www.w3.org/2009/sparql/wiki/EditingFoafData
14:36:12 <SteveH> LukeWM: 2 usecases
14:36:26 <SteveH> LukeWM: 1) delete some triples based around a WHERE, to change name
14:36:35 <SteveH> LukeWM: bare minimun
14:36:36 <AxelPolleres2> (thanks steve)
14:36:49 <SteveH> LukeWM: 2nd usecase, more complicated, changing some details from address
14:36:58 <SteveH> LukeWM: has to delete sub-tree hanging of address
14:37:11 <SteveH> LukeWM: done it with some fancy syntax, like property path syntax
14:37:19 <SteveH> LukeWM: .+ matches any predicate
14:37:29 <SteveH> LukeWM: usecase for prop paths in update
14:38:49 <AxelPolleres2> "replace" values by delete all/insert
14:38:56 <AxelPolleres2> q?
14:39:33 <SteveH> LukeWM: intended to be recursive
14:39:45 <LukeWM> AxelPolleres2: you would delete all addresses, and replace with just the one, right?
14:39:54 <AxelPolleres2> delete subtrees!
14:39:55 <SteveH> LukeWM: real code just goes a couple of hops, but would like to delete entire tree
14:40:06 <SteveH> LukeWM: seems like it could get complicated
14:40:15 <iv_an_ru> hm, what's constructed is deleted, recursive delete requires recursive query and that's all.
14:40:21 <SteveH> LukeWM: could have other trees that depend on this one
14:41:24 <LukeWM> SimonS: you could shoot yourself in the foot with this
14:41:28 <AxelPolleres2> q?
14:41:32 <LukeWM> AxelPolleres2: the semantics is clear though, right
14:41:40 <LukeWM> SimonS: yes, semantics are clear
14:41:44 <AxelPolleres2> http://www.w3.org/2009/sparql/wiki/ResourceTopicPortals
14:41:50 <kjetil> Zakim, unmute me
14:41:50 <Zakim> kjetil should no longer be muted
14:42:00 <LukeWM> AxelPolleres2: on to the last use case, Resoure Topic Portals
14:42:19 <LukeWM> kjetil: we used sparql update with ARQ
14:43:03 <LukeWM> kjetil: we have a java coder using queries and he wasn't a semantic web enthusiast, hence he's interesting
14:43:36 <LukeWM> kjetil: second query uses where clause where you bind the variables
14:43:50 <SteveH> q+ to ask about "Insert new concept"
14:43:58 <LukeWM> kjetil: there is also a map editing, where all URIs in system had to be changed
14:44:21 <LukeWM> kjetil: final query moves data between graphs.
14:44:51 <LukeWM> kjetil: could simplify the queries probably.  But we have 2 cases of where clause to bind variables.
14:45:09 <LukeWM> AxelPolleres2: what do you suggest for the last one, they should be easier?
14:45:17 <LeeF> From where I stand as someone surprisingly disinterested in the 'update' part of our work, I hear requirements for both "constant" data loading/replacing and for "query-based" data mutation
14:45:30 <LukeWM> kjetil: to do it in a simpler way would be interesting, but should be weighed against other stuff.
14:45:34 <SteveH> it's not a trivial move
14:45:40 <SteveH> q?
14:45:49 <LukeWM> kjetil: I don't know if it would be that common to want to move stuff between graphs.
14:46:12 <LukeWM> SteveH: based on my limited example of sparql update, only the last one needs a where
14:46:21 <LukeWM> SteveH: perhaps someone else can correct me on that?
14:46:56 <AndyS> q+ to comment on the DELETE P WHERE P form.
14:47:01 <LukeWM> kjetil: In the merge 2 concepts section, the predicate and object are taken out...
14:47:25 <pgearon> LeeF, that exactly covers our user requirements (constant updates and query-based updates)
14:47:27 <LukeWM> AxelPolleres2: Basically DELETE is the same as a WHERE, in one case
14:47:32 <LukeWM> SteveH: I might be wrong
14:47:45 <LukeWM> AndyS: I think SteveH is right in intent.
14:47:57 <LukeWM> AndyS: If you have unbound variables in the pattern, it's like a CONSTRUCT
14:48:22 <LukeWM> ...you get into repetition, it's common and ugly.
14:48:25 <AxelPolleres2> andyS: repition is ugly.
14:48:45 <AxelPolleres2> q?
14:48:48 <AndyS> ack me
14:48:48 <Zakim> AndyS, you wanted to comment on the DELETE P WHERE P form.
14:48:52 <SteveH> ack me
14:48:52 <Zakim> SteveH, you wanted to ask about "Insert new concept"
14:48:55 <SimonS> q+
14:48:58 <LukeWM> SteveH: I didn't realise DELETE worked like CONSTRUCT
14:49:05 <AndyS> q+
14:49:36 <LukeWM> SimonS: I thought WHERE would be the matching part but delete would be like the construct pattern.  Is that true?
14:49:39 <ericP> that's how i read it
14:50:28 <SteveH> -1 to convenience forms like that
14:50:29 <LukeWM> AndyS: that was the intention.  If you have to extract the sub pattern, it's pretty ugly.
14:50:36 <SteveH> DELETE { * } maybe
14:50:45 <LeeF> convenience forms the 2nd time around :-)
14:50:49 <SimonS> ack me
14:51:03 <SteveH> q?
14:51:03 <AndyS> DELETE * WHERE P
14:51:04 <LukeWM> AxelPolleres2: there are use cases for both complex, with needed WHERE clause, as well as more lightweight ones.
14:51:07 <LeeF> the first time around should require lots of pain - if people use it despite the pain, then you can be confident it's important :-D
14:51:21 <LeeF> c.f. optional/!bound
14:51:26 <AndyS> c.f. CONSTRUCT * (which has issues with nested GRAPH but solvable
14:51:28 <LukeWM> AxelPolleres2: AndyS suggested a phased approach in the mail.
14:51:31 <iv_an_ru> A side note: what I like in current SPARUL is that it constructs all items to delete and or insert before starting changes (say, by making temporary dictionaries).
14:51:32 <iv_an_ru>  At the same time, in many cases it can easily be optimized to insert or delete in a loop, as soon as next binding is found
14:51:39 <LukeWM> s/the mail/a mail/
14:51:42 <kjetil> Zakim, mute me
14:51:42 <Zakim> kjetil should now be muted
14:51:44 <SteveH> AndyS, yes, it's a bit messy with GRAPH present
14:51:51 <LukeWM> AxelPolleres2: The second thing is PUT, DELETE and POST - simpler
14:52:07 <LukeWM> AxelPolleres2: It seemed that only the first use cases were covered, but not the others.
14:52:30 <LukeWM> AndyS: It was a very large problem-space so we need to split it.
14:52:42 <SteveH> I'm not sure that starting with a single graph will actually be simpler
14:52:47 <LukeWM> AndyS: we don't want to not do the whole thing, we just need to get some focus
14:53:04 <LukeWM> AxelPolleres2: So the 1st phase wouldn't cover all the use cases
14:53:20 <iv_an_ru> SteveH, +1
14:53:28 <LukeWM> AndyS: not Alex's, certainly, because we'd have to load data into a graph store with a particular name
14:53:38 <LukeWM> AndyS: how big a chunk of work to we bite off?
14:53:55 <SteveH> I would got for PUT, POST first
14:54:08 <LukeWM> AxelPolleres2: I want to get a sense of whether we do a 2 phased approach or not
14:54:17 <AlexPassant> would like LOAD (or some feature with a similar behavior) to be in the first phase
14:54:20 <LukeWM> ericP: all my use cases are for UPDATE on the graph store
14:54:30 <LukeWM> AndyS: whole graph operations?  Is that what you mean?
14:54:32 <LeeF> I'm less interested in PUT, POST then in a mutation language, personally, but somewhat low priority personally for me as well
14:54:52 <LukeWM> ericP: I can't answer until next week.  I need to get my head around how awkward things are.
14:54:52 <SteveH> With CONSTRUCT and PUT you can do a lot
14:55:01 <SteveH> abeit inefficiently
14:55:12 <AndyS> PUT?  That's replace?
14:55:15 <SteveH> yes
14:55:21 <AndyS> ack
14:55:23 <LukeWM> LeeF: I'm (personally) more interested in doing everything, like using patterns etc, rather than RESTful stuff
14:55:41 <iv_an_ru> I'd say, LOAD is especially useful when one may selectively DELETE the garbage from the LOADed mess.
14:55:46 <LeeF> SteveH, I hadn't considered that - is there an example of that anywhere?
14:56:04 <kjetil> q+
14:56:14 <AndyS> q-
14:56:36 <LukeWM> SteveH: if we have PUT, which in HTTP is a replace operation and CONSTRUCT, we can do a lot of modifications.
14:56:42 <LukeWM> AxelPolleres2: PUT was replacing
14:56:52 <LukeWM> SteveH: according to HTTP standard, yes
14:56:54 <pgearon> +q
14:57:02 <AndyS> so the division is changes of a graph and changes of a graph store (whole graph)
14:57:05 <AndyS> ??
14:57:08 <LukeWM> SteveH: POST is additive
14:57:15 <AxelPolleres2> q?
14:57:26 <LukeWM> SteveH: not trying to replace INSERT DELETE
14:57:27 <kjetil> ack me
14:57:48 <LeeF> Wonders if someone understands this enough to summarize the options in email?
14:57:48 <LukeWM> kjetil: main problem is we'd have to have an HTTP server and we don't have that
14:58:18 <LukeWM> kjetil: WHERE clause is mandatory
14:58:35 <SteveH> +1 to deffering WHERE
14:58:40 <LukeWM> kjetil: DELETE WHERE is mandatory but not INSERT WHERE
14:59:04 <LukeWM> pgearon: I liked the semantics of HTTP put but
14:59:14 <AndyS> WHERE is in INSERT and DELETE : not in INSERT DATA and DELETE DATA.
14:59:34 <LukeWM> pgearon: it could be abused to just do a delete, which would be subverting the semantics
14:59:46 <LukeWM> AxelPolleres2: This is a question of priority
15:00:17 <LeeF> +1 to AxelPolleres2 summarizing
15:00:19 <LeeF> :)
15:00:29 <SteveH> q?
15:00:30 <kjetil> Zakim, mute me
15:00:30 <Zakim> kjetil should now be muted
15:00:31 <ericP> q+ to make sure i understand where SPARUL sits
15:00:38 <LukeWM> AxelPolleres2: Let me try to summarize this, and continue with further discussion later
15:00:45 <AxelPolleres2> ACTION: Axel to summarize priorization issues on update
15:00:45 <trackbot> Created ACTION-33 - Summarize priorization issues on update [on Axel Polleres - due 2009-06-02].
15:00:50 <LukeWM> AxelPolleres2: anyone else want a closing word on this?
15:01:07 <iv_an_ru> When I wrote spec for "my" SPARUL, I did not know that Andy had written similar thing right at the same time. And the only difference between two independently written spec was INSERT IN vs. INSERT INTO spelling. That resembles King Jame's Bible, so that's word of truth ;)
15:01:12 <AndyS> ack pgearon
15:01:20 <ericP> ack me
15:01:26 <Zakim> ericP, you wanted to make sure i understand where SPARUL sits
15:01:35 <LukeWM> AxelPolleres2: What I got out was this:  do we have additive, editing and replacing for insert
15:01:53 <Zakim> -kjetil
15:02:03 <LukeWM> AxelPolleres2: I understand SPARUL as everything, but protocol level stuff is a subset
15:02:25 <LukeWM> AxelPolleres2: do we want just protocol or protocol+language
15:02:27 <AndyS> Submission did not cover protocol - no common agreement
15:02:47 <AndyS> or just language.
15:02:47 <SteveH> +1 PUT and DELETE is not enough
15:02:53 <pgearon> +1 on update language
15:02:59 <SteveH> but standardising it would be good, given that it's common
15:03:03 <Zakim> -iv_an_ru
15:03:18 <LukeWM> ericP: there is still demand for an update language - people will ask for it if we just give then PUT and DELETE
15:03:31 <iv_an_ru> (ups, somtehing wrong with phone)
15:03:42 <LukeWM> AxelPolleres2: does anyone want just PUT and DELETE?
15:03:56 <AxelPolleres2> Conclusions of today: 
15:04:06 <AxelPolleres2> 1) more than PUT DELETE needed
15:04:18 <LukeWM> AxelPolleres2: should we have both?
15:04:26 <LukeWM> SteveH: I think we need both.
15:04:32 <AxelPolleres2> 2) sitll writing down PUT DELETE would be nice (?)
15:04:46 <LukeWM> ericP: Doesn't it just fall out of HTTP?
15:05:05 <LukeWM> SteveH: so many people already implement it, it would be a shame not to have it.
15:05:17 <SimonS> +1 to AxelsPolleres2's 2)
15:05:22 <LukeWM> AxelPolleres2: lets get this to a mail discussion
15:05:46 <LukeWM> ericP: Steve, we'll do this on the phone later and then have a mail discussion.
15:06:09 <LukeWM> AxelPolleres2: lets adjourn
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000450