Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-05-26
From SPARQL Working Group
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