Warning:
This wiki has been archived and is now read-only.
Chatlog 2012-02-01
From RDF Working Group Wiki
See panel, original RRSAgent log or preview nicely formatted version.
Please justify/explain non-obvious edits to this page, in your "edit summary" text.
16:01:57 <RRSAgent> RRSAgent has joined #rdf-wg 16:01:57 <RRSAgent> logging to http://www.w3.org/2012/02/01-rdf-wg-irc 16:01:59 <trackbot> RRSAgent, make logs world 16:01:59 <Zakim> Zakim has joined #rdf-wg 16:02:01 <trackbot> Zakim, this will be 73394 16:02:01 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start 2 minutes ago 16:02:02 <trackbot> Meeting: RDF Working Group Teleconference 16:02:02 <trackbot> Date: 01 February 2012 16:02:11 <ivan> zakim, who is on the phone? 16:02:15 <Zakim> SW_RDFWG()11:00AM has not yet started, ivan 16:02:19 <Zakim> On IRC I see RRSAgent, MacTed, AlexHall, gavinc, Arnaud, AZ, pfps, swh, AndyS, LeeF, mischat, ivan, SteveH, danbri, mdmdm, manu1, davidwood, yvesr, NickH, trackbot, manu, sandro, 16:02:22 <Zakim> ... ericP 16:02:23 <ivan> zakim, dial ivan-voip 16:02:28 <Zakim> ok, ivan; the call is being made 16:02:31 <Souri> Souri has joined #RDF-WG 16:02:57 <MacTed> Zakim, this is 73394 16:02:58 <Zakim> ok, MacTed; that matches SW_RDFWG()11:00AM 16:02:59 <MacTed> Zakim, who's here? 16:02:59 <Zakim> On the phone I see Peter_Patel-Schneider, davidwood, AZ, OpenLink_Software, ??P11, AlexHall, Arnaud, gavinc, Ivan, sandro, ??P16, Souri 16:03:02 <Zakim> On IRC I see Souri, Zakim, RRSAgent, MacTed, AlexHall, gavinc, Arnaud, AZ, pfps, swh, AndyS, LeeF, mischat, ivan, SteveH, danbri, mdmdm, manu1, davidwood, yvesr, NickH, trackbot, 16:03:04 <Zakim> ... manu, sandro, ericP 16:03:11 <MacTed> Zakim, OpenLink_Software is temporarily me 16:03:12 <AndyS> zakim, ??P11 is me 16:03:12 <swh> Zakim, ??P16 is me 16:03:13 <MacTed> Zakim, mute me 16:03:14 <Zakim> +MacTed; got it 16:03:18 <Zakim> +AndyS; got it 16:03:20 <Zakim> +swh; got it 16:03:22 <Zakim> MacTed should now be muted 16:03:42 <AlexHall> scribe: alexhall 16:03:47 <davidwood> PROPOSED to accept the minutes of the 25 Jan telecon: 16:03:47 <davidwood> http://www.w3.org/2011/rdf-wg/meeting/2012-01-25 16:03:51 <AlexHall> topic: admin 16:04:02 <davidwood> Action item review: 16:04:02 <trackbot> Sorry, couldn't find user - item 16:04:02 <davidwood> http://www.w3.org/2011/rdf-wg/track/actions/pendingreview 16:04:02 <davidwood> http://www.w3.org/2011/rdf-wg/track/actions/open 16:04:10 <AlexHall> davidwood: no objections, minutes accepted 16:04:21 <AlexHall> RESOLVED to accept the minutes of the 25 Jan telecon 16:04:40 <MacTed> Zakim, unmute me 16:04:40 <Zakim> MacTed should no longer be muted 16:04:44 <Zakim> +LeeF 16:04:53 <Zakim> +PatH 16:05:15 <AlexHall> davidwood: action item reviews 16:05:18 <MacTed> s/RESOLVED to accept/RESOLVED: accept/ 16:05:34 <patH> patH has joined #rdf-wg 16:06:04 <AlexHall> davidwood: eric completed his review of XML Schema changes, andy commented, can mark it done 16:06:28 <zwu2> zwu2 has joined #rdf-wg 16:06:28 <AlexHall> davidwood: past-due action items 16:06:34 <zwu2> zakim, code? 16:06:34 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), zwu2 16:06:52 <AlexHall> patH: will work on action 120 16:07:14 <Zakim> +zwu2 16:07:28 <zwu2> zakim, mute me 16:07:28 <Zakim> zwu2 should now be muted 16:07:37 <AlexHall> davidwood: let's talk about issue 79, what is the value of a datatyped literals whose datatype IRI is not a datatype? 16:07:41 <davidwood> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html 16:07:44 <Zakim> +EricP 16:08:20 <AlexHall> davidwood: cygri mentioned that he's satisfied with changes made to the wording of the spec to address this, per message on the mailing list 16:09:26 <AlexHall> patH: prefer the original wording, but this is OK 16:09:48 <AlexHall> davidwood: objections to closing issue 79? 16:09:49 <sandro> issue-79? 16:09:49 <trackbot> ISSUE-79 -- What is the value of a literal whose datatype IRI is not a datatype? -- pending review 16:09:49 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/79 16:09:57 <AlexHall> patH: editorial, not substantive 16:10:05 <davidwood> RESOLVED: to close ISSUE-79 http://www.w3.org/2011/rdf-wg/track/issues/79 16:10:37 <davidwood> Topic: Revisit XML Schema Datatypes in RDF and OWL? 16:11:07 <davidwood> XML Schema Datatypes in RDF and OWL is a W3C Working Group Note dated 14 March 2006: 16:11:07 <davidwood> http://www.w3.org/TR/swbp-xsch-datatypes/ 16:11:15 <AlexHall> davidwood: cygri brought up that we might need to revisit 2006 wg note on XSD datatypes in RDF and OWL 16:11:18 <ivan> q+ 16:11:23 <davidwood> ack ivan 16:11:26 <Zakim> +??P34 16:11:44 <AlexHall> ivan: don't consider that a very high-priority issue 16:12:01 <NickH> zakim, ??P34 is me 16:12:01 <Zakim> +NickH; got it 16:12:04 <AlexHall> ... wonder if anybody out there actually used the mechanism for defining new XSD datatypes in RDF 16:12:07 <NickH> Zakim, mute me 16:12:07 <Zakim> NickH should now be muted 16:12:12 <gavinc> ivan, TQ uses it 16:12:15 <MacTed> Zakim, mute me 16:12:15 <Zakim> MacTed should now be muted 16:12:26 <AlexHall> davidwood: think some XML-heads in large enterprise might have used it 16:12:53 <swh> Some talis people use it, but arguably incorrectly 16:12:54 <gavinc> ivan, used when importing XML schema into RDF 16:13:04 <MacTed> Zakim, unmute me 16:13:04 <Zakim> MacTed should no longer be muted 16:14:15 <AlexHall> macted: can't think of any use off the top of my head, but gut is that yes it has been used 16:14:56 <gavinc> q+ Section 4: http://www.w3.org/TR/swbp-xsch-datatypes/#section-duration needs to change 16:15:08 <gavinc> q+ to talk about Section 4: http://www.w3.org/TR/swbp-xsch-datatypes/#section-duration needs to change 16:15:32 <AlexHall> ericP: scenario where we need to update the note is that the mechanism for defining literals changed, most likely it's backwards compatible and doesn't need revision 16:15:44 <davidwood> ack gavinc 16:15:44 <Zakim> gavinc, you wanted to talk about Section 4: http://www.w3.org/TR/swbp-xsch-datatypes/#section-duration needs to change 16:15:55 <AlexHall> patH: willing to look at it from semantics perspective 16:16:40 <AlexHall> gavinc: note mentions that duration doesn't have a well-defined value space, should at least revise that part 16:17:05 <AlexHall> davidwood: think we have an obligation to keep docs up to date, will email jeremy 16:17:19 <AlexHall> action: davidwood to ask jeremey to review XSD in RDF and OWL note 16:17:19 <trackbot> Created ACTION-139 - Ask jeremey to review XSD in RDF and OWL note [on David Wood - due 2012-02-08]. 16:17:26 <mischat> mischat has joined #rdf-wg 16:17:27 <gavinc> Zakim, mute me 16:17:27 <Zakim> gavinc should now be muted 16:17:36 <AlexHall> action: patH to review XSD in RDF and OWL from semantics perspective 16:17:36 <trackbot> Created ACTION-140 - Review XSD in RDF and OWL from semantics perspective [on Patrick Hayes - due 2012-02-08]. 16:17:20 <davidwood> Topic: RDF and Time 16:18:24 <AlexHall> davidwood: while pat is here, would like to talk about RDF and time to try and move forward with named graphs 16:18:43 <AlexHall> ... pat made point on mailing list that there is no notion of time sensitivity in RDF at all 16:19:10 <AlexHall> ... surprised me that named graphs are so closely related to time variability 16:19:26 <sandro> q+ 16:19:50 <AlexHall> ... thought that RDF graphs always expressed a snapshot of the world at the time they were written 16:20:16 <AlexHall> patH: if you think of RDF that way, it doesn't fit with the semantics 16:20:44 <Zakim> -Arnaud 16:20:45 <AlexHall> ... facts in RDF are not time-relative, 2 + 2 = 4 for all of eternity 16:21:04 <sandro> pat: RDF is a "timeless" framework, where facts are always true 16:21:14 <AlexHall> ... if you want to talk about time, you have to explicitly put them in the ontology 16:21:20 <Zakim> +Arnaud 16:21:37 <sandro> pat: from Aristotle forward, that's how mathematicians have liked to think of it. 16:21:55 <sandro> pat: or you have have a time-embedded framework, with an implicit "now". 16:21:58 <ericP> pat: in time-embedded, if you say the same thing at different times, it means different things 16:22:02 <AlexHall> ... you can also think of facts as time-embedded, saying the same thing at two different times can mean two things 16:22:15 <sandro> pat: in the second case, the inference rules change. 16:22:15 <ericP> ... so you have to incorporate that context into the semantics 16:22:28 <AlexHall> ... it's natural to think that way, but it complicates the logic when time is implicit in the graph 16:22:52 <sandro> pat: so the question is whether RDF is timeless or time-embedded. It's not possible to prevent people from using it in a time-embedded way because that's how people think of this. 16:22:58 <AlexHall> ... impossible to prevent people from using RDF in a time-embedded way 16:22:59 <sandro> q- 16:23:42 <sandro> eric: Do have to say, "as of this date, our understanding is, this protein has these properties..." 16:24:35 <AlexHall> patH: scale is important; if data is expected to change over the course of the time that the data is used, then you need to account for time 16:24:54 <sandro> eric: So they differ in degree -- time range of things changing -- not actually in kind. 16:25:12 <AlexHall> patH: e.g. weather report for this week vs. geologic time scales 16:25:38 <sandro> ted: One might expect that HTTP caching and expiration mechanism could be used to help with this. 16:26:23 <Arnaud> given that time sensitivity is really dependent on the type of data you're dealing with isn't that better left to the application? 16:26:33 <AlexHall> patH: expect that this conversation is going to arrive at the point where we have to acknowledge that people use RDF in a time-embedded way 16:27:01 <sandro> davidwood: Our charter gives us use cases that need this to be address to solve them.... 16:27:49 <AlexHall> david: Find this to be the heart of the problem, that named graphs are very closely tied to provenance which is how time sensitivity is addressed 16:28:25 <AlexHall> patH: one approach is to say that the modelers are always going to have to account for time in their data 16:28:49 <AlexHall> ... but modelers aren't going to do that because it's hard and unnatural 16:28:54 <sandro> q+ 16:29:01 <davidwood> ack sandro 16:29:07 <AlexHall> david: also affects versioning and merging of graphs created at different times 16:29:48 <AlexHall> patH: true, time information has to be captured to effectively merge datasets where time is implicit 16:29:57 <patH> peter, I never saw you as a tosser. 16:30:23 <AlexHall> sandro: can add a simple triple into the dataset, "the time right now is X" 16:31:00 <AlexHall> ... use this triple to add extra checks to see that merged graphs were at the same time 16:31:33 <AlexHall> patH: the point is, lots of applications aren't currently doing this check and would be broken 16:31:36 <sandro> pat: context logics, sub-intervals 16:31:48 <gavinc> +q to ask Who is asking us to fix this? 16:32:01 <AlexHall> david: these rules would be very complicated. i might choose to believe data that's an hour old and not a week old. 16:32:04 <ericP> q+ to give a use case: should i prescribe drug X for disease Y given old evidence that it helped and newer (but less-reviewed) evidence that it hurts 16:32:22 <davidwood> ack gavinc 16:32:23 <Zakim> gavinc, you wanted to ask Who is asking us to fix this? 16:32:27 <AlexHall> patH: context logics have tried to account for this by adding time intervals, etc. 16:32:32 <davidwood> ack ericp 16:32:32 <Zakim> ericP, you wanted to give a use case: should i prescribe drug X for disease Y given old evidence that it helped and newer (but less-reviewed) evidence that it hurts 16:33:16 <patH> eric, that is a different issue i think. 16:33:18 <AlexHall> ericP: the way we usually solve this is with SPARQL -- put thresholds in the query, get all information to make a human decision 16:33:35 <Souri> Is it too naive to consider use of the fourth component (graph?) to define the context (time, space, ...): <ctxt1> { :John a :TeenAger } <ctxt2> { :John a :Octogenarian} <ctxt3>{ <ctxt1> :when 1937 . <ctxt2> :when 2007} <ctxt4> {<ctxt3> :creationYear 2012} 16:34:17 <mischat> mischat has joined #rdf-wg 16:34:19 <AlexHall> ... state of the art for this is to put relevant information in front of a human to make final decision 16:34:19 <patH> souri, i think that is the only feasible ideas to standardize, but might be too restrictive. 16:34:39 <AlexHall> does this scale at all? 16:34:39 <patH> +q 16:35:40 <AlexHall> gavin: out of all of us, who is trying to work on a system that is approaching this from a time-implicit way? 16:36:15 <AlexHall> sandro: asked govt people about this, they use dc:temporal with a time range, required to be in any dataset 16:36:16 <davidwood> ack patH 16:36:20 <zwu2> I know a use case that requires associate creation timestamp with every triple 16:37:00 <gavinc> Zakim, mute me 16:37:00 <Zakim> gavinc should now be muted 16:37:02 <AlexHall> patH: saw another use case where they had an OWL ontology, described for each property its likely time persistence (short/long/medium-lived) 16:37:25 <AlexHall> ... allows for pretty complicated modeling (about weather in this case) 16:38:14 <AlexHall> ... going back to eric's use case, you really do have to have a human for this, it's too complex. lots of use cases are simpler, e.g. weather forecasts 16:38:43 <AlexHall> ... think we can at least give advice to implementers about how to handle these simpler use cases 16:38:45 <Zakim> -Arnaud 16:39:17 <AndyS> zakim, who is on the phone? 16:39:17 <Zakim> On the phone I see Peter_Patel-Schneider, davidwood, AZ, MacTed, AndyS, AlexHall, gavinc (muted), Ivan, sandro, swh, Souri, LeeF, PatH, zwu2 (muted), EricP, NickH (muted) 16:39:20 <AlexHall> david: think implementers would say it's too much cost for not much benefit 16:39:43 <AlexHall> sandro: would love to have steve's input, they harvest lots of time-sensitive data 16:40:00 <LeeF> swh, are you here? 16:40:05 <LeeF> SteveH, are you here? 16:40:08 <AlexHall> eric: think they incorporate a timestamp into the graph tag 16:40:33 <AlexHall> ... use metadata to track the graphs 16:40:58 <swh> LeeF, yeah, Im here, was AFK breifly 16:40:59 <AlexHall> pat: this is the 4th approach so far this call. lots of different possibilities 16:42:41 <AlexHall> steveH: we do incorporate a timestamp into the graph IRI, add a statement inside the graph to record this timestamp 16:43:23 <AlexHall> ... if something is true across time, then it will appear in multiple graphs for as long as it's true 16:43:41 <AlexHall> eric: is the triple predictable? could it already be in the graph? 16:43:54 <gavinc> Ding ding! Graph IRI varies with date, same way that WARC solved this as well. 16:44:09 <MacTed> self-description is important... 16:44:13 <AlexHall> steve: we don't allow this, we would filter out that predicate 16:44:17 <MacTed> "follow your nose" falls down without it 16:44:36 <AlexHall> patH: how do you distinguish things that are time-dependent vs. what isn't? 16:45:06 <AlexHall> steve: we don't mix different approaches in one system. either a system is time-dependent or it isn't 16:45:15 <davidwood> q? 16:45:41 <AlexHall> david: eric mentioned grabbing data from a particular time range and present to the user for a choice. do you do this? 16:45:44 <MacTed> "the graph IRI", "inside the graph" refer to Gsnap? Gtext? Gbox? hurrah for overloaded terms! 16:46:00 <AlexHall> steve: we just grab the most recent value, maybe show the most recent time it was true. 16:46:05 <gavinc> well, time 16:46:54 <AlexHall> david: would like to talk about gavin's point that time is encoded in the data with graph IRIs. 16:47:02 <Zakim> +Arnaud 16:47:14 <AlexHall> sandro: would UUID's also work? you don't actually get time from the timestamp? 16:47:50 <AlexHall> s/from the timestamp/from the timestamped IRI/ 16:48:14 <AlexHall> steve: we mostly use the timestamp for human readability, UUID would be OK 16:49:05 <Souri> time-delimited truth 16:49:16 <AlexHall> david: think this discussion has been valuable. we know that people are encoding time data in RDF for stuff that's true for a time. we know people are using this in the field. we know not every fact expressed in RDF is eternally true 16:49:43 <patH> the real issue is, is the time-stamp part of the rdf data or not? 16:49:53 <AlexHall> ... where does that leave us in relation to e.g. time-varying IRIs? 16:50:39 <AlexHall> sandro: sounds like steve's approach is what i labeled as TRIG/equality, think that's a reasonable straw-man starting point 16:50:47 <patH> and is it in each triple or just in an entire graph? 16:50:51 <ericP> q+ to point out that we can let people migrate from eternal to snapped 16:50:55 <gavinc> Not really no ;) 16:51:09 <patH> :-) 16:51:34 <AlexHall> ... vs TRIG/REST which would put the time-varying nature of the retrieval more into the core 16:51:38 <patH> q+ 16:52:17 <AlexHall> ... TRIG/equality makes the relation between a graph IRI and its triples time-invarying, think this is a safer approach 16:52:46 <AlexHall> ... steve, after you read in a graph and associate an IRI with it, do you ever modify it? 16:53:01 <gavinc> "Assign an IRI that is globally unique for its period of intended use." 16:53:09 <AlexHall> steve: no, it stays constant 16:53:34 <sandro> q? 16:54:07 <AlexHall> ted: that's the danger of putting timestamps into IRIs, blurs the line between opaque IRIs and the urge for humans to ascribe meaning to the IRIs 16:54:15 <davidwood> ack ericP 16:54:15 <Zakim> ericP, you wanted to point out that we can let people migrate from eternal to snapped 16:54:44 <AlexHall> (universal agreement that you shouldn't be parsing a timestamp from an IRI, it should be explicit in triples) 16:55:23 <AlexHall> eric: could get pushback from people who just want to do simple time-invariant modeling if we make it more complicated to account for time variance. 16:56:17 <AlexHall> ... we should make it easy for people to start with the easy case (invariant) and optionally adding in time variance 16:57:35 <AlexHall> david: this tells me that all graphs are potentially time-variant 16:57:45 <davidwood> ack PatH 16:58:20 <AndyS> The graph (value) does not vary in RDF's ideal view of the world.. The value in the g-box changes. 16:58:25 <AlexHall> patH: no -- if we're talking about geologic time spans, we don't expect to RDF data to survive this 16:58:35 <MacTed> q+ 16:58:57 <sandro> Yeah. How the heck are people supposed to publish the weather in RDF? It's the first example in AWWW. 16:59:27 <AlexHall> ... if the publisher of the data expects the data to be time-varying, that has to be accounted for 16:59:42 <sandro> ted: Until the moment things change, you may think what you're saying is going to be true for all time. 17:00:14 <AlexHall> ... macted: time variance can't necessarily be predicted, unexpected change happens all the time in science, e.g. 17:00:21 <sandro> pat: All data is subject to being wrong, yes. But that's not the same as tomorrow's weather is going to be different from today's. 17:00:35 <swh> database people have been dealing with this for decades - it's fine 17:00:49 <pfps> I agree with swh - strongly - there is nothing new here 17:00:55 <sandro> q+ 17:01:02 <Zakim> -Souri 17:01:04 <ivan> ack MacTed 17:01:59 <AlexHall> macted: if data that was thought to be immutable suddenly becomes mutable, that is a bigger problem than data that was thought to be mutable actually being immutable 17:02:05 <sandro> q+ to say there seems to be confusion about what's mutable. (1) what's true changes, (2) the state of resources MIGHT change or be frozen, (3) g-snaps never change. 17:02:49 <AlexHall> patH: that's true, but we shouldn't force all data to be mutable in the data model 17:02:56 <davidwood> ack sandro 17:03:17 <Zakim> sandro, you wanted to say there seems to be confusion about what's mutable. (1) what's true changes, (2) the state of resources MIGHT change or be frozen, (3) g-snaps never 17:03:20 <Zakim> ... change. 17:03:34 <swh> publishing weather, dc:date… next? 17:03:38 <swh> q+ 17:04:11 <davidwood> ack swh 17:04:30 <AlexHall> sandro: think we should focus on how do you publish the weather in RDF. it's the prototypical example, have no idea right now of how to do that, if we can do that then maybe it can be extended to other problems. 17:04:34 <patH> q+ 17:04:57 <davidwood> ack patH 17:05:03 <NickH> +1 to swh 17:05:16 <AlexHall> steveH: i think we're overthinking this. database people have been handling this problem just fine for decades, using timestamp fields in tables 17:05:34 <sandro> swh, any idea why data.gov.uk chose to use dc:temporal instead of dc:date ? 17:05:51 <AlexHall> patH: i agree, don't think it's hard, it's a question of how to do it? 17:06:28 <swh> sandro, no idea, dc:date is possibly not the right choice, was just a strawman 17:06:31 <davidwood> "every triple is sacred" 17:06:43 <AlexHall> ... don't want to have to timestamp every triple that can possibly be time-varying 17:07:04 <AndyS> different domain of discourse 17:07:32 <AlexHall> ... could modify the semantics if we decided a standard way of timestamping a graph. then people could understand one another. 17:08:13 <AlexHall> ivan: essentially defining a timestamp vocabulary 17:08:33 <AlexHall> patH: yes, and a convention for adding a timestamp triple to a graph 17:09:21 <davidwood> q? 17:09:34 <sandro> ted: lack of this triple has to be taken as there-with-a-bnode --- all the RDF data out there is implicitely time dependent. 17:09:45 <AlexHall> ???: what to do with all the existing data out there? 17:10:00 <AlexHall> ... it won't have this triple, but might be time dependent 17:10:00 <sandro> s/???/ted/ 17:10:26 <AlexHall> patH: think we can work out the details of this over email 17:11:15 <AlexHall> david: if we were to do this and modify the semantics in a way with minimal impact to deployed data, would this buy us anything in the named graph discussion? 17:11:24 <AlexHall> patH: i think it would, yes 17:11:49 <AlexHall> davidwood: can you formulate a proposal for a strawpoll? 17:12:08 <AlexHall> patH: yes, maybe in the next week or so 17:12:31 <davidwood> Alex, please assign an action to Pat 17:12:42 <AlexHall> ivan: not sure what you mean by this. are all triples quads where the fourth entry is a timestamp? 17:13:53 <AlexHall> ... what does it mean that the timestamp vocabulary has a semantics? does it extend the model theory semantics? or is it just described in plain english? 17:13:54 <sandro> ivan: We have the word semantics used in the semantic web with many different semantics. :-) 17:14:14 <AlexHall> pat: model theory 17:14:46 <AlexHall> ivan: this worries me. afraid that adding this to the model theory would make it too complicated. 17:15:03 <AlexHall> pat: don't think that describing it in english makes it any easier 17:16:49 <AlexHall> action: patH to propose a vocabulary and semantics for adding timestamps to RDF graphs 17:16:49 <trackbot> Created ACTION-141 - Propose a vocabulary and semantics for adding timestamps to RDF graphs [on Patrick Hayes - due 2012-02-08]. 17:17:53 <Zakim> -gavinc 17:18:04 <AlexHall> davidwood: out of time. i think if pat can make a proposal, and if it has minimal impact on existing data, then i think we have a good way forward 17:18:13 <sandro> we don't have a named graphs deadlock -- we have no cogent proposals on which to deadlock. 17:18:19 <AlexHall> ... adjourned. # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000231