Chatlog 2008-07-16

See original RRSAgent log and preview nicely formatted version.

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

00:00:00 <bmotik> PRESENT: rob (muted), uli (muted), IanH, bmotik (muted), alan_ruttenberg, bcuencagrau (muted), Peter_Patel-Schneider, bijan (muted), Ivan, Zhe (muted), ratnesh, Achille, JeffP, Achille, ivan, Zhe, bijan, bmotik, uli, IanH, ratnesh, rob, pfps, sandro, ewallace, m_schnei, baojie
17:02:01 <IanH> IanH has changed the topic to: http://www.w3.org/2007/OWL/wiki/Teleconference.2008.07.16/Agenda
17:02:26 <IanH> ScribeNick: bmotik
17:05:16 <bmotik> alan_ruttenberg: No agenda amendments
17:05:48 <bmotik> PROPOSED: Accept previous minutes (9 July)
17:05:50 <pfps> they have all the requisite parts - their veracity I can't determine
17:05:24 <rob> looked reasonable to me
17:05:27 <IanH> Minutes look good to me
17:06:03 <bmotik> RESOLVED: Accept previous minutes (9 July)
17:06:11 <bmotik> Topic: 3F2F
17:06:28 <bmotik> alan_ruttenberg: Please register whether you'll be or not at 3F2F
17:06:39 <bmotik> alan_ruttenberg: Please give us feedback about the agenda
17:07:06 <bmotik> Topic: Action item status
17:07:59 <bmotik> alan_ruttenberg: I can't invest more time into ACTION-159 , so let's drop it
17:08:17 <bmotik> alan_ruttenberg: I produced input for ACTION-166
17:08:28 <bmotik> pfps: I don't see any rationale to using two files in the write-up
17:08:48 <bmotik> alan_ruttenberg: We are discussing here the completion of the action, not the contents
17:08:56 <bmotik> pfps: I consider the action finished
17:09:08 <bmotik> Topic: Due and overdue actions
17:09:38 <bmotik> alan_ruttenberg: Jie has initiated discussion about ACTION-150
17:10:04 <bmotik> ivan: Someone from our side should check owl:internationalizedString
17:10:33 <bmotik> alan_ruttenberg: Michael, what is the status of the OWL-Full semantics?
17:10:42 <m_schnei> OWL Full: http://www.w3.org/2007/OWL/wiki/FullDraft
17:10:48 <bmotik> m_schnei: There is a draft
17:10:59 <bmotik> m_schnei: It is half-finished
17:11:12 <bmotik> alan_ruttenberg: Where do we stand? How far are we from the working draft?
17:11:31 <bmotik> m_schnei: I have already added most of the semantic conditions.
17:11:42 <bmotik> m_schnei: There is some editorial work and some open issues.
17:11:49 <bmotik> m_schnei: The import question is open.
17:12:11 <bmotik> alan_ruttenberg: Can you produce a single document by the F2F?
17:12:31 <bmotik> m_schnei: The present document can't be turned into a working draft by the F2F -- not enough time.
17:12:51 <bmotik> alan_ruttenberg: It would be great to have  a document ready for review by 3F3F.
17:12:56 <bmotik> m_schnei: I hope so.
17:13:18 <bmotik> alan_ruttenberg: ACTION-157: I have a response from Judy Brewer
17:13:41 <bmotik> alan_ruttenberg: ACTION-157 gets postponed
17:13:59 <bmotik> bijan: I could take it around to Robert Stevens
17:14:10 <ivan> bijan++
17:14:14 <bmotik> alan_ruttenberg: That would be very good
17:14:31 <bmotik> alan_ruttenberg: Please add an action for that
17:14:44 <bijan> ACTION on Bijan to test our documents for accessibility with Robert Stevens
17:14:44 <trackbot> Sorry, couldn't find user - on
17:14:52 <bijan> ACTION: Bijan to test our documents for accessibility with Robert Stevens
17:14:52 <trackbot> Created ACTION-168 - Test our documents for accessibility with Robert Stevens [on Bijan Parsia - due 2008-07-23].
17:14:53 <bmotik> alan_ruttenberg: Uli, what is the status on the top/bottom roles?
17:14:57 <bmotik> uli: The action is done
17:15:09 <bijan> He's supposed to send email about it
17:15:33 <bmotik> bmotik: I have already added these roles to the document
17:15:41 <bmotik> alan_ruttenberg: Just send an e-mail documenting it
17:16:03 <bmotik> Topic: Proposals to resolve issues
17:17:22 <bmotik> PROPOSED: Close ISSUE-31 as withdrawn
17:17:28 <ewallace> +1
17:17:29 <m_schnei> +1 (FZI)
17:17:30 <alan_ruttenberg> +1
17:17:32 <bijan> +1
17:17:33 <pfps> +inf
17:17:34 <bmotik> bmotik: +1
17:17:34 <ivan> +1
17:17:35 <IanH_> +1
17:17:35 <bijan> +1
17:17:36 <Zhe> +1
17:17:38 <uli> +1 
17:17:39 <Achille> +1
17:17:40 <bcuencagrau> +1
17:17:46 <bmotik> RESOLVED: Close ISSUE-31 as withdrawn
17:18:15 <bmotik> Topic: Proposals to resovle issues
17:18:59 <bmotik> alan_ruttenberg: Ian, could you tell us how to resolve ISSUE-67?
17:19:54 <bmotik> ianh: We already decided to use owl:Axiom instead of rdf:Statement
17:20:15 <bmotik> ianh: There has been no discussion for a long time, so it seems to me that the issue has been resolved.
17:20:31 <bmotik> m_schnei: My statement that "there is no problem" referred to something else
17:21:02 <bmotik> m_schnei: This is a question that I can't decide and I asked people at FZI
17:21:12 <bmotik> m_schnei: RDF people dislike reification
17:21:39 <bmotik> m_schnei: Feedback from FZI: There was noone in favor of reification; a few people said "either way"; a few people were against
17:21:52 <bmotik> m_schnei: My proposal is to use a shadow vocabulary
17:22:22 <bmotik> ianh: I don't have a problem with that
17:22:45 <bmotik> ianh: I don't think it is reasonable to object to resolving issues by arguments of the sort "I don't quite like it...because?"
17:22:57 <bmotik> ianh: Shadow vocabulary seems fine
17:23:51 <bmotik> alan_ruttenberg: Bijan, have you got a general comment?
17:24:01 <bmotik> bparsia: I wanted to ask Michael about his polling methodology
17:24:20 <bmotik> bparsia: We introduced vocabulary for property punning which gives additional functionality
17:24:35 <bmotik> bparsia: We now need to introduce new vocabulary for no new functionality
17:24:58 <bmotik> Zhe: I wanted to ask whether the base triples should be included into serialization?
17:25:11 <bmotik> alan_ruttenberg: This is a separate issue; should go on the Issues list
17:25:35 <bmotik> alan_ruttenberg: I don't think it is good to rule out the RDF shorthand
17:26:07 <bmotik> ianh: Let's just use the shadow vocabulary and be done with it.
17:26:15 <bmotik> ianh: Is there any reason not to do that?
17:26:53 <bmotik> PROPOSED: Close ISSUE-67 by introducing new shadow vocabulary
17:26:59 <ewallace> +1
17:27:00 <IanH_> +1
17:27:01 <bmotik> bmotik: +1
17:27:03 <JeffP> +0
17:27:05 <alan_ruttenberg> -0
17:27:06 <Achille> 0
17:27:20 <uli> 0
17:27:21 <ratnesh> 0
17:27:24 <pfps> 0
17:27:24 <ivan> 0
17:27:26 <Zhe> 0
17:27:30 <bijan> -0.00001
17:27:32 <bcuencagrau> +1
17:27:33 <m_schnei> +1 (FZI)
17:27:45 <bijan> I don't like it, but I'm broken on this so don't care :)
17:27:46 <m_schnei> sorry, my line broke down
17:27:54 <bmotik> RESOLVED: Close ISSUE-67 by introducing new shadow vocabulary
17:28:13 <bmotik> bmotik: We'll add owl:subject, owl:object, and owl:predicate
17:28:32 <bmotik> bmotik: I'll change the spec accordingly
17:28:58 <bmotik> Topic: The state of OWL-R and OWL-R DL/Full unification
17:30:12 <bmotik> alan_ruttenberg: There is a proposal from Boris
17:30:36 <bmotik> m_schnei: There is a proposal from Boris, but I don't think I understand it
17:30:55 <bmotik> m_schnei: As far as I understand, all the triple rules will remain
17:31:04 <bmotik> m_schnei: Is this still true?
17:31:06 <bmotik> bmotik: yes
17:31:27 <bmotik> m_schnei: How do I understand on the OWL-R DL side?
17:31:42 <bmotik> m_schnei: Until now, there were two parallel specification of two langauges.
17:31:57 <bmotik> m_schnei: These two languages had not much in common
17:32:46 <bmotik> m_schnei: Is it that we'd need to parse the triples, check the syntax, and if that's accepted, then one goes to the semantics document?
17:33:47 <bmotik> bmotik: currently, we have two languages which are different
17:33:55 <bmotik> bmotik: this is undesirable
17:34:18 <bmotik> bmotik: the ideal situation would be to define the profiles in exactly the same way
17:34:29 <bmotik> bmotik: that is, as syntactic fragments of OWL 2
17:35:11 <bmotik> bmotik: an RDF graph falls within any of the fragments if it corresponfs to an ontology in the functional syntax according to the RDF mapping
17:35:25 <bmotik> bmotik: the rules in OWL-R could be used directly in an implementation
17:35:35 <bmotik> bmotik: no need to look at the OWl Full semantics
17:35:48 <bmotik> bmotik: then, we would unify the language
17:35:59 <bmotik> bmotik: Ivan has raised some objections
17:36:13 <bmotik> bmotik: what if a graph does not fall within OWL-R
17:36:28 <bmotik> bmotik: in my opinion, the user should be warned
17:36:40 <bmotik> bmotik: but still the rules could be fired
17:36:57 <bmotik> bmotik: but not with the guarantees that you would have within OWL-R
17:37:31 <bmotik> m_schnei: I have no objection to this
17:37:31 <bmotik> bmotik: an implementation could also apply the rules to ontologies that do not fall within OWL-R
17:37:50 <bmotik> m_schnei: The question for me is what is the DL semantics of ...
17:38:04 <bmotik> m_schnei: The current rule set has subproperty chains
17:38:21 <bmotik> m_schnei: You need to support subproperty chains
17:38:35 <bmotik> bmotik: we do support subproperty chains
17:38:39 <bmotik> bmotik: I thing you are wrong
17:38:49 <bmotik> m_schnei: I'll check
17:39:19 <bmotik> bmotik: OWL-R DL mimicks everything that is in OWL-R Full
17:39:42 <bmotik> bmotik: both OWL-R DL and OWL-R Full have been guided to allow for rule-based implementations
17:39:58 <bmotik> bmotik: the intention was the same for both
17:40:19 <bmotik> bmotik: they both should support the same, and if not it is a bug
17:40:49 <bmotik> alan_ruttenberg: Could Zhe or Ivan say something?
17:40:58 <bmotik> ivan: I'll try to summarize the discussion
17:41:18 <bmotik> ivan: I understand the whole mechanism that Boris has descirbed
17:41:28 <bmotik> ivan: The problem is the marketing side, rather than the technical side
17:41:55 <bmotik> ivan: If we do this way, then RDF users and implementors use a clear possibility to reference something that is clearly standardized
17:42:49 <bmotik> ivan: The problem is that there are "almost" OWL-DL graphs, that can be managed by the rules
17:43:26 <bmotik> ivan: I don't care whether you call this a "Profile"; however, we need a clear reference
17:43:33 <alan_ruttenberg> two statements worth verification : "these are two very different languages" "there are no issues with the list vocabulary and the rules"
17:43:42 <bmotik> bmotik: it is a fair summary
17:44:03 <bmotik> Zhe: I don't have too much new stuff to say
17:44:11 <bmotik> Zhe: I'm happy with the spec as it is
17:44:30 <bmotik> Zhe: But I can see that the unification might be good
17:44:52 <bmotik> Zhe: I tend to agree that we need some name from a markeeting perspective
17:45:14 <Achille> +1 for ivan
17:45:23 <bmotik> alan_ruttenberg: Michael said that these are two different langauges; Zhe, is this your sentiment as well?
17:45:31 <bmotik> Zhe: I don't see them as totally different languages
17:45:56 <bmotik> ianh: I was quite surprised ot hear Ivan come up with the marketing argument
17:46:14 <bmotik> ianh: The current situation actually seems pretty bad from an RDF implementation point of view
17:46:32 <bmotik> ianh: I would imagine that many of the existing implementations basically try to implement as much of OWL Full
17:46:36 <m_schnei> I remember that I originally saw two *very* different languages, having different language constructs, but this might have changed over time
17:46:46 <bmotik> ianh: These implementations would become invalid OWL_R/RDF implementations
17:46:56 <pfps> +1 to Ian's comment
17:47:03 <bmotik> ianh: You would not be allowed to add additional rules, as you would become unsound
17:47:34 <bmotik> ianh: If we went with the current proposal, all existing rule-based implementations could say that they are valid OWL-R implementations
17:47:43 <bmotik> ianh: This seems a big advantage for the DL community
17:48:00 <bmotik> ianh: The name that people have for describing their system is "OWL-R".
17:48:07 <bmotik> ianh: What is OWL-R? It is a fragment of OWL-Full.
17:48:23 <bmotik> ianh: I think that people prefer the current situation because they don't understand all the consequences of the current spec.
17:48:43 <bmotik> ivan: The vendos usually something as PDFS++, OWL-Prime...
17:48:54 <bmotik> ivan: All of the implementors implement subset of the current OWL-R.
17:49:13 <bmotik> ivan: The message I got from people is that they'd like to say whatever they implemented is a standard
17:49:56 <bmotik> ivan: The problem is that there would be several OWL-R graphs that OWL-R implementations would not accept
17:50:26 <bmotik> ianh: Ivan, you said that most people implement a subset of these rules; but then, they are not OWL-R reasoners
17:50:33 <bmotik> ivan: Yes, but they want a standard
17:50:46 <bmotik> ianh: Most people implemented a superset, but then, they are not a standard
17:51:10 <m_schnei> since owl R has sub property chains, i very much doubt that any triple rule implementation is a superset of owl r
17:51:14 <bmotik> ianh: Implementors usually want to implement more
17:51:30 <bmotik> ianh: If we changed their spec, this would prevent people from implementing more
17:51:52 <bmotik> alan_ruttenberg: Suppose you add a rule to OWL-R that is unsound w.r.t. OWL Full
17:52:37 <Zhe> which rule?
17:52:07 <bmotik> alan_ruttenberg: Would that be considered OWL-R conformant?
17:52:24 <bmotik> alan_ruttenberg: The current spec is permissive in the sense that anything would be OWL-R comformant
17:53:26 <bmotik> ianh: You would add as many rules as you like
17:53:44 <bmotik> bparsia: I am not as convinced by the marketing argument
17:54:06 <bmotik> bparsia: It is imporant to focus on a subset where we can really understand what the functionality is
17:54:28 <bmotik> bparsia: We should allow people to do extensions
17:54:55 <bmotik> bparsia: It is important for the users to understand what each construct means in terms of the language
17:55:28 <bmotik> bcuencagrau: If we do this as proposed currently, you need to support at least the specified rules
17:55:54 <bmotik> bcuencagrau: You could add as much as you want, you would not any semantic guarantees, but you can add it it the users really need it
17:56:33 <bmotik> ivan: I don't understand how this all issue of extensions came into the discussions.
17:57:05 <bmotik> ivan: According to the planned spec, there will be a set of rules, and if I just implement this set of rules and apply it to the set of graphs, then I implement not exactly OWL-R but a bit more
17:57:06 <bijan> More than OWL-R is an extension yes?
17:57:10 <bmotik> ivan: This is what bothers me
17:57:23 <bmotik> ivan: I'd like to be able to say to the world what exaxctly I'm implementing
17:57:25 <bijan> We have a nice syntactic criterion...you handle what's in by the parser
17:57:47 <bmotik> ivan: I would like to signal the fact that I'm accepting more than OWL-R graphs
17:58:17 <bmotik> m_schnei: If a reasoner produces inferences that are not entailed by the languages, then the reasoner is unsoud
17:58:28 <bmotik> m_schnei: If a reasoner produces more than OWL-R, then the reasoner is unsound
17:58:37 <IanH_> NOT TRUE -- because this only happens for graphs that are *outside* the syntactic fragment
17:59:02 <IanH_> Such reasoners are SOUND for OWL-R
17:58:57 <bmotik> alan_ruttenberg: We should resume the discussion next week
17:59:12 <bmotik> Topic: Normative datatypes
18:00:04 <pfps> see http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0306.html
18:00:35 <bmotik> bmotik: proposal for datatypes
18:00:49 <bmotik> bmotik: we would have numbers^+
18:01:04 <bmotik> bmotik: which contains the reals plus +inf, -inf, etc.
18:01:27 <bmotik> bmotik: then we would have the `numbers', which would contain the reals
18:02:51 <bmotik> bmotik: implementers discretion as to how many decimal digits to be supported
18:02:27 <pfps> I think that Boris means "minimally conforming" as in the XML Schema spec
18:01:37 <bmotik> bmotik: scribe lost
18:02:48 <pfps> This is all in the message, so I don't think that Bernardo needs to scribe everything.
18:02:59 <bijan> There's an email about all this
18:03:28 <IanH_> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0306.html
18:04:25 <bmotik> alan_ruttenberg: Evan, you had some question about the floats?
18:04:37 <bmotik> alan_ruttenberg: Could you comment on that?
18:04:49 <bmotik> evan: Are computational effects going to cause problems?
18:05:09 <bmotik> evan: Will be get ropunding problems?
18:05:59 <alan_ruttenberg> 1) Can you use float constants to specify real facets?
18:06:10 <rob> "0.1"^^xsd.float != "0.1"^^xsd:decimal
18:06:24 <alan_ruttenberg> 2) Any reason not to have base64binary with octet value space?
18:06:32 <bmotik> bmotik: every constant will have a precise interpretation
18:06:44 <bmotik> bmotik: floats will be interpreted as in the IEEE spec
18:07:13 <bmotik> alan_ruttenberg: You could use a float contant to specify a facet on owl:real?
18:07:18 <bmotik> bmotik: Yes, no problem.
18:07:47 <bmotik> bmotik: every constant just maps to one value
18:07:51 <bmotik> alan_ruttenberg: You couldn't get more precision by using extra digits?
18:08:00 <bmotik> bmotik: No, there is no problem.
18:08:20 <bmotik> bmotik: we could have it as a synonym
18:08:30 <bmotik> bmotik: value spaces will be synonyms
18:08:30 <bmotik> bmotik: value spaces will be synonyms
18:08:44 <bmotik> bmotik: I didn't include it for redundancy
18:09:04 <bmotik> Zhe: In your proposal, would the value spaces of xsd:float and xsd:double be disjoint?
18:09:08 <bmotik> bmotik: no
18:09:35 <bmotik> bmotik: that is Jena's problem
18:09:36 <alan_ruttenberg> in that case they map to same value
18:10:14 <ewallace> value comparison was exactly my issue
18:12:19 <alan_ruttenberg> comparison of .1d, .1f has different result in real space then when promoting to double
18:09:45 <bmotik> bmotik: you are comparing a double with a float
18:10:00 <bmotik> bmotik: that could be implemented correctly
18:10:31 <bmotik> bmotik: the problem is not in the disjointness
18:11:11 <bmotik> bmotik: java would map 0.1 float into a 32bit representation
18:11:27 <bmotik> bmotik: it would map 0.1 double into a different number
18:11:51 <bmotik> bmotik: it doesn't seem to be a SPARQL problem
18:12:03 <bmotik> bmotik: probably it is an RDF problem
18:13:31 <bmotik> alan_ruttenberg: I think that there might be a point on the comparison of numbers
18:14:13 <bmotik> alan_ruttenberg: I believe that rounding of a float to a double and then comparing it to a double is not going to give you the same thing as compariong values in the value space
18:14:54 <bmotik> alan_ruttenberg: We are promoting to owl:number, so implementations can't use IEEE semantics
18:15:19 <bmotik> achille: We should stay compatible with XML Schema
18:15:44 <bmotik> achille: Why are we departing from XML Schema?
18:16:02 <bmotik> uli: I hear all these concerns about compatibility.
18:16:24 <bmotik> uli: I'm sure that we'll be compatible with XML Schema; in fact, we won't be able to tell the difference
18:16:55 <bmotik> bmotik: XML Schema has benn designed for different purpuse
18:17:06 <bmotik> bmotik: in OWL you can quantify over values
18:17:31 <bmotik> bmotik: in XML Schema it is pointless whether a value space is continuous or not
18:17:47 <bmotik> bmotik: in OWL we need to define behavior of data ranges during reasoning
18:17:45 <Achille> but they also care about comparisons
18:17:58 <bmotik> bmotik: and hence go beyond XML Schema
18:18:31 <bmotik> bmotik: in OWL you can distinguish whether the value space is discreet or continuos
18:18:32 <bmotik> alan_ruttenberg: We are almost out of time
18:18:51 <bmotik> alan_ruttenberg: We should see which areas of the proposal are uncontentious
18:19:01 <bmotik> ivan: I had two points
18:19:24 <bmotik> bmotik: I don't know
18:19:25 <alan_ruttenberg> it does say that
18:19:27 <pfps> in XML schema double and float have disjoint values spaces
18:19:37 <rob> they are colored differently, but defined mathematically
18:19:45 <alan_ruttenberg> but they say that implementations can do cross comparisons
18:19:46 <bmotik> ivan: Have you checked what XML Schema says about value spaces?
18:20:30 <bmotik> bparsia: 1.0 spec says that the value spaces are disjoint. 1.1 says that implementations can interpret this as they want
18:20:35 <alan_ruttenberg> SPARQL would be incomplete wrt to OWL. no surprise
18:20:36 <ivan> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0223.html
18:21:04 <bmotik> ivan: The guys who looked at the internationalize string datatype described an alternative.
18:21:34 <bmotik> ivan: Essentially, one wants ot define a whole family of datatypes by saying that each datatype would be identified by a different URI.
18:21:40 <bmotik> ivan: what is the relationship?
18:21:42 <bijan> That doesn't seem workable
18:22:33 <bmotik> Achille: I still think that XML Shema is a standard. There is clearly the need for comparing datatypes from different registries.
18:23:00 <bmotik> Achille: Applications might be broken if we depart on this
18:23:18 <Zhe> +1 to Achille
18:23:26 <bmotik> bparsia: I've been on both sides of the disjointness issue
18:23:53 <bmotik> bparsia: Reasoners differ on this
18:23:57 <alan_ruttenberg> ditto xfunction, xquery
18:24:06 <rob> all Cerebra's users were sensitive to it
18:24:07 <bmotik> bparsia: It seems to me that people are not sensitive to this
18:24:12 <rob> it was reported as a bug several times
18:24:17 <alan_ruttenberg> We can cite this email stream
18:24:30 <bmotik> bparsia: I was shocked that the XML Schema guys thought there was no problem in making them disjoint
18:24:54 <bmotik> bparsia: I've switched from disjointness to believeing that people don't care that much about disjointness
18:25:05 <bmotik> bparsia: We'll have to make a pick, and we'll have to pick something
18:25:05 <Achille> We have people we have implemented it in IBM stack
18:25:19 <pfps> I seem to remember that the disjointness in XML Schema Datatypes 1.0 was in response to an email message that I sent pointing out that, at the time, the XML Schema documents clearly stated that xsd:float and xsd:integer did *not* have disjoint value spaces.
18:25:33 <Achille> I will like to talk to them about their position on this issue
18:26:10 <pfps> That's not an implementation *restriction*!
18:25:32 <bmotik> alan_ruttenberg: I'll try to test agreement
18:25:44 <bmotik> alan_ruttenberg: owl:number(Plus) seems like a good idea
18:25:59 <bmotik> alan_ruttenberg: I've heard questions from implementors regarding rationals
18:26:10 <bmotik> alan_ruttenberg: The restrictions on integers seem uncontroversial
18:26:18 <bmotik> alan_ruttenberg: Dittoxsd:decimal
18:26:26 <bmotik> alan_ruttenberg: Floats seem controversial
18:26:37 <bmotik> alan_ruttenberg: We need coordination regarding strings
18:27:07 <bmotik> alan_ruttenberg: The empty language tag seem to address some of the problems of previous proposals
18:27:22 <bmotik> alan: boolean, hexDecimal seem OK
18:27:31 <bmotik> alan_ruttenberg: Date/time need more discussion
18:27:43 <bmotik> alan_ruttenberg: It seems to me that we've made quite a lot of progress
18:28:05 <bmotik> alan_ruttenberg: There are not as many open issues
18:28:07 <bmotik> Topic: Other business
18:28:32 <bmotik> alan_ruttenberg: Should we have a meeting next week?
18:28:38 <bmotik> alan_ruttenberg: Ian and I think yes.
18:28:30 <pfps> +1 to meet next week