06:50:00 RRSAgent has joined #owl 06:50:00 logging to http://www.w3.org/2008/10/24-owl-irc 06:50:18 zakim, this will be owl wg 06:50:18 I do not see a conference matching that name scheduled within the next hour, wallace 06:50:33 zakim, this will be owl 06:50:33 ok, wallace; I see SW_OWL(F2F)2:30AM scheduled to start 20 minutes ago 06:51:14 ScribeNick: wallace 07:03:46 MarkusK_ has joined #owl 07:04:57 bernardo has joined #owl 07:05:33 bmotik has joined #owl 07:05:34 ivan has joined #owl 07:06:02 zakim, dial Riviera_B 07:06:02 ok, ivan; the call is being made 07:06:03 SW_OWL(F2F)2:30AM has now started 07:06:03 +Riviera_B 07:06:39 zakim, drop Riveiera_B 07:06:39 sorry, ivan, I do not see a party named 'Riveiera_B' 07:06:52 zakim, who is there? 07:06:52 I don't understand your question, ivan. 07:07:04 pfps has joined #owl 07:07:14 zakim, dial Riviera_B 07:07:14 ok, ivan; the call is being made 07:07:16 +Riviera_B.a 07:07:31 -Riviera_B 07:07:40 -Riviera_B.a 07:07:41 SW_OWL(F2F)2:30AM has ended 07:07:42 Attendees were Riviera_B, Riviera_B.a 07:07:54 zakim, dial Riviera_B 07:07:54 ok, ivan; the call is being made 07:07:54 IanH has joined #owl 07:07:55 SW_OWL(F2F)2:30AM has now started 07:07:56 +Riviera_B 07:08:17 zakim, who is on the phone? 07:08:17 On the phone I see Riviera_B 07:08:21 zakim, who is here? 07:08:21 On the phone I see Riviera_B 07:08:23 On IRC I see IanH, pfps, ivan, bmotik, bernardo, MarkusK_, RRSAgent, Zakim, wallace, sandro, Zhe, trackbot 07:12:24 subtopic: XSD data types 07:12:34 Rinke has joined #owl 07:12:35 issue 138 07:13:04 pfps: talked with Henry Thompson of XML schema wg 07:13:17 ... and there is no problem 07:13:34 pfps: we will be using as identity the single timeline 07:13:39 Christine has joined #owl 07:13:51 ... not the seven value rep. 07:14:03 ... our identity is their equality 07:14:17 ... The only thing we might consider is a note to 07:14:38 ... implementers that you should keep the timezone info there 07:15:23 boris: need to preserve the info needed for structural equivalence 07:15:50 pfps: this means that we can use the new dataTime with required timezone 07:16:04 ... they are meeting next week to resolve all their issue 07:16:34 ... we will thus know the name for this restricted type next week 07:16:52 q? 07:17:08 pfps: they are going for their second last call soon, before publishing moratorium 07:17:21 q? 07:17:30 pfps: they have high hopes to have implementations ready soon 07:17:34 sandro has joined #owl 07:17:40 ivan: my only fear about this is 07:17:59 ... we cannot refer to something that it too far away from the state where we are 07:18:20 Boris: Tools working with dateTime should preserve the structural integrity of literals, but we may not want to make too strong a statement there -- we may not want to require "01"^^xs:int not be rewritten "1"^^xs:int. 07:18:29 ... by the time we get to Rec, we must refer to things that are at least candidate Rec. 07:19:18 Sandro: We should probably keep an AT RISK warning on xs:dateTime just in case that WG slips their schedule too much. 07:19:27 pfps: we can close it, but we will still need to change the name 07:20:42 PROPOSED: Close issue 138 with an editors' note stating that we will use XSD name when they determine what it is; also note that this is at risk -- we may need to pick a new name if they don't make it to CR on time. 07:20:58 +1 (ALU) 07:20:59 1 07:21:05 +1 (Oxford) 07:21:06 +1 07:21:08 +1 07:21:19 0 07:21:27 +Zhe 07:21:30 +1 07:21:38 +1 07:21:39 +1 07:21:45 ewallace: +1 07:21:51 +1 07:22:12 +1 07:22:16 RESOLVED: Close issue 138 with an editors' note stating that we will use XSD name when they determine what it is; also note that this is at risk -- we may need to pick a new name if they don't make it to CR on time. 07:22:47 schneid has joined #owl 07:23:45 ... however, the rdf construct for this does not impinge on their purview on this thus they wont complain 07:24:14 ivan: Is there any specific concern that we should take into account? 07:24:46 sandro: the RDF core working group was unhappy with creating internationalized strings at the time 07:25:13 pfps: I don't think there will be a problem with this. 07:26:37 sandro: (so basically, any awkwardness of rdf:text is due to a design circa 2002 that we can't do much about.) 07:27:24 Achille has joined #owl 07:27:53 Topic: New Issues Affecting Core Documents 07:28:21 subtopic: Issue-147 Add UnionOf and IntersectionOf on Data Ranges 07:28:57 boris: we have unionOf, intersectionOf on classes but we dont have for datarange 07:30:51 boris: we can get some of these for dataranges through other means 07:31:10 boris: the point is you could say range of a property is string or integer 07:31:30 boris: they are useful (e.g., <15 or >65) for age giving preferential treatment 07:31:33 ... from a reasoning point of view things don't change very much 07:31:46 ... rdf already has it 07:32:09 ivan: it gives more rdf graphs also expressible in DL 07:32:16 boris: these are already in Full - because dataranges are classes and thus can participate in union/intersection 07:32:52 boris: reasoners have to have the facilities for this (from union/intersection for classes) 07:32:57 boris: profiles can't have union of data ranges, even if it were possible I wouldn't go there 07:33:04 PRESENT: Ian, Boris, Pfps, Bernardo, Sandro, MarkusK, schneid, Achille, bijan, wallace, Christine, Rinke, Ivan 07:33:12 ... this is something we would only add to the general language 07:33:16 Zakim, who is on the call? 07:33:16 On the phone I see Riviera_B, Zhe 07:33:18 Q? 07:33:22 REMOTE: Zhe 07:33:35 m_schnei: no technical issues with the RDF-Based Semantics, because datatypes / data ranges are classes in RDF 07:33:57 bijan: its a late addition. I generally like expressivity. There aren't any users demanding this yet. 07:34:16 ... I think that its true that we know how to build prepositional reasoners 07:34:39 ... my asserting that linear equations is a minor addition 07:34:48 m_schnei: intersections and unions of datatypes do not lead out of the class of all data values, so no problem with OWL Full 07:34:59 ... All I want to know is if we have a uniform principal here 07:35:05 m_schnei: nothing would need to change in the RDF-Based Semantics 07:35:12 RRSAgent, make records public 07:35:16 boris: you can handle this at the level of tableaux 07:35:39 christine: for a user point of view it is useful, I could provide e.g.s immediately 07:36:11 schneid: there was discussion a while ago on a public list where there was a request for exactly this feature 07:36:32 achille: Can we support it by supporting union in XSD itself? 07:36:47 bijan: no XSD reasoner can do what we need to do with it. 07:37:05 ... you get a choice of an XSD infoset but it won't do reasoning by cases 07:37:29 ianh: everybodies happy with it. It seems a no brainer to add it. 07:37:47 bijan: we should document the thing about not reusing XSD 07:38:04 ... I will put a comment on the issue page. 07:38:26 ivan: I don't have any real issue with the proposal, but there should be a point when 07:39:13 ... we say "feature stop". When will we say "that's it guys" ? 07:39:37 ivan: it's not my intention to block this one. 07:40:46 subtopic: issue 148 07:41:21 boris: we were trying to issue top data property in hermit and notice a problem that 07:41:25 bijan has joined #owl 07:41:33 ... could arrive address issue 147 07:42:12 boris: you could fix the set of datatypes 07:42:48 boris: assume we don't introduce union now 07:43:13 ... but we already have top data property so now users can define their own 07:44:47 schneid: from a full point of view 148 doesn't depend on 147 07:45:10 +q 07:45:10 ivan: for symmetry purposes don't we have something similar for top object property 07:45:28 boris: no, because it is not on a concrete domain 07:45:32 boris: if you have a union of all datatypes and make that the range of topDataProperty, then you "fix" the set of datatypes 07:45:34 m_schnei: 148 does not depend on 147, since OWL Full allows unions of data types anyway 07:45:35 PROPOSED: q? 07:45:46 q? 07:45:53 ack bernardo 07:45:59 bernardo: its about theorem 1, which is independent from the datatype theory 07:46:06 boris: if a later WG adds other datatypes, this then becomes inconsistent, so additions to the language can retroactively make existing ontologies inconsistent 07:46:29 -q 07:46:37 ... if you use a top data property you can talk about datatypes globally 07:47:14 bijan: but in my tutorials I will be clear not to use these for modelling 07:47:23 boris: this seems bad, but union seems useful - the problem can be avoided by restricting the use of topDataProperty 07:47:54 ianh: there is a philosophical point were the domain for datatypes is fixed 07:48:08 q? 07:48:10 boris: the restriction is to only allow topDataProperty as a superproperty of other axioms 07:48:39 markus: if you have "extra" values, then the example is always inconsistent 07:49:19 boris: you have to be very careful because you could "exhaust" the rest of the data domain, and then you get to see these extra values 07:49:44 bijan: to speak in favor of this: this is a more minimal restriction 07:49:59 ianh: we are pretty much on the same page 07:51:13 boris: theorem 1 doesn't apply to OWL Full 07:51:55 schneid: this problem is already in OWL Full 07:53:18 ianh: we have two proposals that are linked 07:54:45 PROPOSED: Close issue 148 by introducing a global restriction on the use of topDataProperty so that it can only be used as a superproperty for other data properties 07:54:49 +1 07:54:53 +1 (ALU) 07:54:55 +1 07:54:56 +1 07:54:57 +1 07:54:58 +1 07:55:00 1 07:55:01 +1 (Manchester or Oxford) 07:55:01 +1 (ORACLE) 07:55:03 ewallace: +1 07:55:04 +1 (uvsq) 07:55:05 +1 (Oxford) 07:55:06 +1 07:55:29 RESOLVED: Close issue 148 by introducing a global restriction on the use of topDataProperty so that it can only be used as a superproperty for other data properties 07:55:55 PROPOSED: Close issue 147 by introducing UnionOf and IntersectionOf on Data Ranges 07:55:58 +1 (ALU) 07:56:00 +1 07:56:03 +1 07:56:05 +1 (Manchester) 07:56:05 +1 (uvsq) 07:56:08 +1 07:56:08 ewallace: +1 07:56:10 1 07:56:10 +1 (Oxford) 07:56:11 +1 (ORACLE) 07:56:15 +1 (IBM) 07:56:17 +1 07:56:42 +1 07:56:46 again :-) 07:56:56 RESOLVED: Close issue 147 by introducing UnionOf and IntersectionOf on Data Ranges 07:57:36 I just click +1 07:58:25 subtopic: issue 144 07:58:45 zakim, who is here? 07:58:45 On the phone I see Riviera_B, Zhe 07:58:46 On IRC I see bijan, Achille, schneid, sandro, Christine, Rinke, IanH, pfps, ivan, bmotik, bernardo, MarkusK_, RRSAgent, Zakim, wallace, Zhe, trackbot 07:58:54 zhe: my position has not changed yet 07:59:00 q? 07:59:10 ... oracle wants this base triple in annotation serialization 07:59:11 zakim, who is here? 07:59:11 On the phone I see Riviera_B, Zhe 07:59:12 On IRC I see bijan, Achille, schneid, sandro, Christine, Rinke, IanH, pfps, ivan, bmotik, bernardo, MarkusK_, RRSAgent, Zakim, wallace, Zhe, trackbot 07:59:43 schneid: my position has also not changed 07:59:55 ... I think the base triple needs to be in the mapping 08:00:36 ... this causes copies of axioms in the functional syntax (one with and one without annotation) 08:00:37 I can only hear fragmented voice from Michael 08:00:46 RRSAgent, pointer? 08:00:46 See http://www.w3.org/2008/10/24-owl-irc#T08-00-46 08:00:52 ... if we have rdf graph with assertions 08:01:48 ... every tool has to reconstruct these base triples 08:02:34 schneid: we should ask ourselves how would we build a ref impl for this 08:02:55 boris: I would like to make this decision somehow coherent 08:03:03 FabGandon has joined #owl 08:03:14 ... our story should be that the reified triples don't mean anything 08:03:42 ... a reified version shouldn't have any consequences 08:04:19 scheid: everyone has to upgrade 08:05:30 boris: if we don't have a clear story about what these reified triples mean, it opens the door to further problems 08:06:12 boris: this introduces a gap from the rdf base semantics and the OWL 2 RDF RL semantics 08:07:03 ivan: what he is saying is that the mapping would ultimately put the reified triple 08:07:25 boris : the proposal is to get rid of table 417 from the RDF base semantics 08:08:10 Bijan: can we list all the downsides? 08:08:46 Boris: you can't have an ontology which contains an axiom which is annotated and another which is not annotated. 08:08:47 boris: the downside is you can't have an ontology that has an axiom that is annotated and one that is not annotated 08:08:57 Bijan: And we bloat the size of the ontology. 08:10:08 schneid: But this is unavoidable anyway. Given an RDF graph built in collaboration with several authors. This has to mapped and reverse mapped. So the mapping tool has the same problem, with a parallel mapping of the same axiom differently annotated. 08:10:21 Boris: Well, no, we could map them to a different blank node. 08:10:35 Ian: Sure, but it's okay, since we all agree. 08:10:53 ianh: are we ready to close the issue 08:10:54 BlazN has joined #OWL 08:11:28 PROPOSED: Close issue 144 by agreeing that the serialisation of annotated axioms will include the base triple 08:12:13 PROPOSED: Close issue 144 by agreeing that the serialisation of annotated axioms will include the base triple and removing table 4.17 from the RDF-Based semantics 08:12:13 +1 08:12:16 +1 08:12:17 +1 (ORACLE. so worth getting up early in the morning :)) 08:12:18 +1 08:12:19 0 08:12:20 +1 08:12:24 wallace: +1 08:12:26 +1 08:12:27 +1 08:12:28 1 08:12:30 +1 (Oxford) 08:12:45 +1 08:12:54 +1 (for me either :)) 08:12:56 +1 08:13:09 RESOLVED: Close issue 144 by agreeing that the serialisation of annotated axioms will include the base triple and removing table 4.17 from the RDF-Based semantics 08:14:57 scribenick: MarkusK_ 08:15:28 subtopic: issue 149 08:15:50 ivan: there are two issues here 08:16:00 ... boris filed them as one 08:16:29 ... the issue I found was that the functional syntax includes a number of built-in entities such as owl:thing, nothing, top*Property 08:16:46 ... these are not present in the OWL RL rule set 08:17:20 ... in addition, some additional rules are needed o axiomatise those constructs in OWL RL 08:17:25 q? 08:17:31 s / o / to / 08:17:49 ivan: then there is another part uncovered in the discussion and addded by boris 08:18:09 ... some of the required rules might generate a high number of additional triples in the store 08:18:10 zakim, who is here? 08:18:10 On the phone I see Riviera_B, Zhe 08:18:12 On IRC I see BlazN, FabGandon, Achille, schneid, sandro, Christine, Rinke, IanH, pfps, ivan, bmotik, bernardo, MarkusK_, RRSAgent, Zakim, Zhe, trackbot 08:18:23 ... we had a long discussion whether this is good or bad from a user's viewpoint 08:18:41 ... would an average user care about the top properties and classes or not? 08:18:56 ... boris had goodexamples where it seemd useful but hte price might still be too large 08:19:03 ian: any suggestions for resolving this? 08:19:03 q+ 08:19:10 q? 08:19:15 ivan: I would like to hear the oppinion of implementors 08:19:19 ack zhe 08:19:41 zhe: I am not in favour of adding all those triples for top properties and objects 08:20:13 ... these rules are not needed to figure out that certain sub-class and sub-property axioms hold 08:20:17 present-= Wallace 08:20:21 present-= Bijan 08:20:42 zhe: in my oppinion, the rule set needs not to be complete in this respect 08:21:20 boris: precisely because it is indeed easy to find out whether something is an instance of owl:thing 08:21:30 ... implementations can have smart optimisations for dealing with them 08:21:43 ... it would not be required to literally materialise all the triples for those cases 08:22:03 ... and such optimisations will be required anyway for good implementations of OWL RL 08:23:00 q? 08:23:01 schneid: there are other entailments that I would not want to materialise, and there seem to be many applications where one would not want to materialise everything with forward-chaining 08:23:07 ... this is a mess even in RDFS 08:23:25 boris: indeed, you cnanot even implement RDFS in this way. 08:23:26 q? 08:23:39 pfps: Theorem 1 would be broken when not having the additional rules 08:24:06 ivan: I agree with all of these considerations 08:24:10 q? 08:24:26 ... but it would be required to clarify some of those editorially in the document for OLW RL 08:24:31 s /OLW/OWL/ 08:25:28 ... specific comments should be added regarding the implementation, in particular for existing environments where SPARQL is used for querying 08:25:56 q? 08:26:02 ... such implementations would require modifications of the SPARQL querying to work for OWL RL when not materialising everything 08:26:23 boris: I do not think that you need to change SPARQL engines to cope with OWL RL 08:26:38 ... reqritting the query in a small layer on to p if the store could suffice 08:26:48 s /reqritting/rewriting/ 08:27:41 boris: the rules we are discussing would go to Table 9, which are not relevant for Theorem 1 to hold anyway 08:28:33 ... Table 9 defines the semantics of subclassOf and subpropertyOf 08:28:57 ... the rules placing owl:thin/nothing and the top/bottom properties in the hierarchy would go there 08:29:34 ... The rules for saying that bottom class/bottom should be empty should go in a new table, not Table 9 08:29:39 q? 08:30:01 ... the only possibly probalmatic rule seems to be the rules stating that every individual is an instance of owl:thing 08:30:12 ivan: there might be gurther rules that are problematic 08:30:16 q+ 08:30:41 q? 08:30:58 michael: the rule that everything is in owl:thing is already a rule in RDFS 08:31:05 ack zhe 08:31:08 ivan: indeed, but it is not here yet 08:31:08 q? 08:31:34 zhe: Pefps mentioned that not having those rules would break Theorem 1. Can you explain? 08:32:24 example of the problem - 08:32:25 boris: yes, a simple entailment like that a particular instance is in owl_thing is not implied by OWL RL 08:32:34 - ontology - individual a is in class C 08:32:43 - query - is a in owl:Thing 08:32:57 - this is true in OWL (all forms) but doesn't follow from the OWL RL rules 08:33:08 - therefore Theorem 1 in Profiles is incorrect 08:33:16 q? 08:33:32 boris: you would want to reason with a statement like 08:33:35 ... SubClassOf( SomeValuesFrom( a:hasChild owl:Thing ) a:Parent ) 08:33:57 ... you cannot do that if you cannot infer that the child is necessarily in owl:thing 08:34:51 ian: a proposal for resolution could be to add the rules to the tables and insert a subsection explaining that complete materialisation of all triples is not a good implementation method 08:34:54 q? 08:35:31 ivan: yes, many entailment questions could be answered without looking up the triple store 08:35:52 ian: anyone not hapy with the current proposal? 08:36:07 zhe: I think I am okay with this 08:36:25 ... we already have to cope with some similar issues 08:36:57 ian: in a way it would then be good to have the additional explaining subsection in the document 08:37:18 boris: the second part of the issue was that axioms like SubClassOf( SomeValuesFrom( a:hasChild owl:Thing ) a:Parent ) are not currently allowed 08:37:39 ... this appears to be a simple bug, since owl:thing could well be allowed on the left-hand side of axioms 08:38:02 zhe: does this discussion also apply to the top property, or just to owl thing? 08:38:50 boris: top/bottom data property are currently not allowed, so they could be left out of the rule set 08:39:22 michael: can you explain again why the above example axiom is not allowed? 08:39:44 boris: because the grammar disallows owl:thing, a simple grammar bug (other class names would be allowed) 08:39:47 great 08:40:19 boris: the resolution includes only owl thing and owl nothing, but none of the top/bottom properties, which are not allowed in OWL RL 08:40:30 ivan: weren't there other constructs as well? 08:40:38 boris: I do not think so 08:41:41 ivan: declaration of annotation properties also needs to be in 08:41:54 PROPOSAL: Close Issue 149 by adding rules that axiomatise built-in entities (Thing, Nothing, etc) along with a new subsection that discusses how implementations could be optimised to deal with rules that potentially introduce large numbers of triples; AND fix the profile specification to allow the usage of SomeValuesFrom( R owl:Thing) on the left-hand side of the axioms. 08:41:59 boris: right but those are not problematic 08:42:15 +1 08:42:18 +1 08:42:19 +1 (ALU) 08:42:21 markus: +1 08:42:23 1 08:42:25 +1 08:42:27 +1 (Oxford) 08:42:29 +1 08:42:34 +1 08:42:41 +1 (Oracle) 08:42:53 +1 08:42:56 +1 08:43:09 RESOLVED: Close Issue 149 by adding rules that axiomatise built-in entities (Thing, Nothing, etc) along with a new subsection that discusses how implementations could be optimised to deal with rules that potentially introduce large numbers of triples; AND fix the profile specification to allow the usage of SomeValuesFrom( R owl:Thing) on the left-hand side of the axioms. 08:43:40 Coffee break 08:55:19 zakim, mute me 08:55:19 Zhe should now be muted 09:11:26 Rinke has joined #owl 09:17:27 scribe: bernardo 09:17:34 Issue 137 09:18:04 issue-137? 09:18:04 ISSUE-137 -- Table 4 in RDF mapping introduces incompatibility with OWL 1 -- OPEN 09:18:04 http://www.w3.org/2007/OWL/tracker/issues/137 09:18:23 alanr: first question concerns backwards compatibility 09:18:23 topic: ISSUE-137 -- Table 4 in RDF mapping introduces incompatibility with OWL 1 09:18:41 alanr: in OWL 1 validity is defined over the transitive closure over imports 09:20:17 q? 09:20:49 alanr: in Table 5 in the RDF mapping, There can be left over triples when using imports 09:21:15 alanr: second question concerns repairs 09:21:36 alanr: repairs in the presence of imports 09:21:50 alanr: there is a proposal I made 09:22:27 alanr: Peter had an alternative proposal that would allow you to import the missing triples using XML include 09:22:35 q? 09:22:51 bmotik: alan was referring to validity syntactically 09:23:25 bmotik: In the OWL 1 spec there is no reference to imports in connection to this issue 09:23:48 bmotik: in OWL 1 it is not clear whether you have to put all the imported ontologies to do the parsing 09:24:03 Boris: It seems to me that it's not clear in OWL 1 whether you need to do imports (smooshing them together) first or not. 09:24:04 bernardo has joined #owl 09:24:30 bmotik: it could be perfectly on a document to document basis 09:24:50 IanH: there is a debate whether there is a backwards compatibility issue 09:25:01 Ian: There's some debate about whether there's a Backward Compatibility concern for now, but aside from that, what would you want to do? 09:25:29 alanr: making the changes I suggest would make the language better, independently of backwards compatibility 09:25:55 alanr: by specifying an extra repair mechanism we can fix some situations 09:25:56 Alan: Right -- I think it would be better for the language to do what I want (take the imports-closure view). It lets us use RDF correctly as OWL DL. 09:26:07 alanr: there are two proposals 09:26:25 alanr: we should not depend on XML 09:26:35 fix 1 == some kind of include mechanism 09:26:55 alanr: two options: some kind of include mechanism and the other would be to remove some triples in the reverse RDF mapping 09:26:59 fix 2 == in the reverse dropping mapping, drop the rdfs class triples, since that leaves the "typing" to the OWL side of things. 09:28:39 alanr: in Table 5, see second line. Throw away all the rdf typing when there is a DL counterpart 09:29:02 bmotik: if we throw these away we are unsound 09:30:02 peter: suppose A imports B. Ontology A. We may end up with no triple that states that C, for example, is a class 09:30:15 bmotik: we may have problems defining the vocabulary 09:30:28 bmotik: Classes have to be declared 09:30:50 bmotik: otherwise we cannot distinguish classes from datatypes 09:31:46 bmotik: O1 imports O2 09:32:09 bmotik: in O2 we have C rdf:type rdfs:Class 09:33:14 bmotik: D someValuesFrom C, D onProperty P 09:33:56 If we throw the type of C, parsing fails 09:34:11 alanr: we can add a new ontology 09:34:21 O3, which is imported by O1 09:34:44 O3 saying C rdf:type owl:Class 09:35:09 bmotik: parsing would still fails 09:35:35 bmotik: because each ontology in the import closure should be an OWL ontology by itself 09:36:20 alanr: what if O1 and O3 import each other? 09:36:32 bmotik: it would still fail 09:36:48 bmotik: you would need an import between O2 and O3 09:37:00 bmotik: then what alan proposes would help 09:37:28 alanr: if this is the case, I am not getting the design, but I would object such design 09:38:34 peter: the triple C rdf:type rdf:Class is invalid OWL 2, because C should be an owl:Class 09:39:23 alanr has joined #owl 09:39:40 IanH: alan had a proposal to resolve and there was an objection that one of those did not work 09:40:01 alnr: yes, there was a misunderstanding and therefore I have another objection 09:40:45 bmotik: the second solution would work 09:41:00 bmotik: O1 imports O2 09:41:20 with O2 containing only C rdf:type rdf:Class 09:41:37 bmotik: we want to make O2 valid 09:42:05 bmotik: there is a third ontology O3 which is a repair 09:42:24 bmotik: where we would have C rdf:type owl:Class 09:42:35 bmotik: O2 is not an ontology is a document 09:42:44 bmotik: O3 is an actual ontology 09:42:52 alanr: I am happy with this 09:43:04 IanH: should this be a proposal to resolve? 09:43:19 peter: the remaining problem is to define the inclusion mechanism 09:43:26 q? 09:43:47 bmotik: in the structural spec the inclusions should not be represented 09:44:08 bmotik: O2 and O3 should be an ontology during parsing 09:44:19 bmotik: include should be something that happens in RDF 09:45:12 ivan: tools should keep track of the provenance of the triples 09:45:35 bmotik: this is something that only concerns the RDF 09:45:56 IanH: if we did this using XML include in RDF/XML 09:46:14 ivan: formally yes, but there is no RDF environment that supports this 09:46:49 mschneider: using an XML mechanism looks like a bit step 09:47:10 IanH: what if we define our own inclusion mechanism? 09:47:20 mschneider: is it worth it? 09:48:02 ivan: if we generate our own mechanism we would end up in an unconfortable situation 09:48:24 ivan: it is doable, but not easy 09:48:50 bmotik: sing XML includes we could say something like ``tools should support XML include'' 09:49:06 ivan: in practice it will not be supported 09:49:43 alanr: this is an OWL specific problem. There is no need in RDF to do an XML inclusion 09:49:51 alanr: it is more a processing change 09:49:57 alanr: it is a big win 09:50:49 mschneider: this is kind of a border case 09:51:15 mschneider: it doesn't seem worthy to add XML inclusion for filling a small gap 09:51:27 peter: an inclusion mechanism is a need in RDF 09:51:35 alanr: I disagree 09:52:14 alanr: it is not a corner case. It is a way to repair lots of RDF that so far was not valid OWL 09:52:39 alan: We're aiming to allow a lot of off-the-shelf RDF to be usable in OWL DL. This is something very useful. 09:52:40 bmotik: RDF does not handle the notion of a document 09:52:57 bmotik: otherwise it is unclear what I am reasoning on 09:53:51 alanr: our issue here is to have a mechanism to bring lots of RDF mechanism into the OWL world 09:54:09 ivan: my feeling is that your proposal needs more thinking 09:54:31 ivan: the consequences are unclear 09:56:32 mschneider: It is a big change late in the process 09:56:36 bijan has joined #owl 09:57:41 alanr: this has been going on for a while 09:58:13 mschneider: it will confuse people 09:59:02 alanr: my preference is that the declarations are checked over the import closure 09:59:12 alanr: Peter proposed another mechanism 09:59:29 alanr: I am happy with any mechanism that fixes the problem 10:00:01 IanH: Strawpol 10:01:29 ivan: today we could identify the problem 10:02:00 ivan: then the only solution that currently exists is a serialization-specific mechanism 10:02:16 ivan: this is an issue that RDF COre should handle 10:02:58 alanr: there is another proposal on the table 10:03:18 alanr: I think that the declarations should be evaluated over the imports closure 10:03:30 bmotik: alan's proposal is ill-defined 10:03:57 bmotik: it would require a big change in the mapping 10:04:24 ivan: I do not understand what is the problem with the declarations over the closure 10:04:39 bmotik: some of the documents in the closure may not be actual ontology 10:04:57 bmotik: some of the imported ontologies may be nothing 10:06:12 alanr: the only problem is that you down move the declarations down from the importing to the imported ontology 10:06:52 bmotik: Suppose O1 having C rdf:type rdfs:Class 10:07:00 and O2 and O3 import O1 10:07:25 bmotik: O2 has C rdf:type owl:Class 10:07:53 bmotik: O1 is not currently and OWL ontology because parsing it would break 10:08:36 ivan: it is not clear that they have to be ontologies by themselves 10:08:59 bmotik: this is how people do it 10:09:34 ivan: I am not convinced 10:09:52 ivan: imagine modularizing an ontology 10:10:05 ivan: what I care about is that the whole thing is an ontology 10:10:28 ivan: it is not necessary that each of the pieces is a consistent ontology by itself 10:11:39 alan gives example 10:12:51 peter: the ideal situation is that a document together with the stuff it imports is an actual OWL ontology 10:13:25 alan: this doesn't matter in practice 10:13:53 sandro: is there an engineering argument against alan's proposal? 10:14:12 IanH: we now have two proposals. 10:14:54 IanH: proposal is to change the specification to gather declarations over the imports closure (alan's proposal) 10:15:44 Achille has joined #owl 10:17:05 mschneider makes a summary of the proposals 10:18:05 ivan: I haven't heard anything convincing about the fact that each piece should be an ontology by itself 10:18:28 bmotik: when you are writing an editoe, you want to have a clear idea of what an ontology object is 10:19:13 bmotik: also, we can have ontologies stored in databases and we have to make sure that they are valid OWL 10:19:38 bmotik: in OWL 1 it was not clear how to parse an ontology 10:20:02 bmotik: we could end up importing something that is not an RDF file 10:20:55 bmotik: in an API you want to work with ontologies, not with arbitrary documents. All tools work like that 10:21:33 achille: it seems that the spec already forces you to look ar declarations in the import closure 10:22:08 IanH: we are only considering the imports, not the inverse of it 10:23:55 ivan: are you afraid of ``diamod-shaped'' import path? 10:24:03 bmotik: that is partly 10:25:23 bmotik: in the functional syntax it is possible to write documents that are not ontologies 10:27:00 +q 10:28:51 boris stands up and draws picture 10:29:15 q? 10:30:27 q? 10:30:38 ack bernardo 10:32:20 alanr: we could distinguish between OWL ontologies and documents and allow import to work also on documents and not only on ontologies 10:33:14 bmotik: in APIs the term ontology always has denoted something that is self consistent 10:33:28 bmotik: we need two logical relationships between documents 10:33:39 bmotik: one is imports which works on ontologies 10:34:00 Assumption => "Self consistent thing" is a single document 10:34:09 bmotik: then, another relationship between documents that works similarly to XML includes 10:35:17 IanH: we are doing some sort of ``repair'' 10:36:13 IanH: wouldn't it be possible to have this in the spec as a note to implementors? 10:36:36 Alan: Many people think of an "Ontology" as something that is expressed in multiple "Documents". Not just this "ontology"=="document" view. 10:37:16 bmotik: we need to agree on the meaning of the term ontology 10:37:51 bmotik: we shoueld say that an ontology is something that can be parsed correctly 10:38:59 bmotik: Proposal: having an explicit include relation that works on documents, not necessarily on ontologies 10:39:43 bmotik: another option would be to overload the meaning of imports 10:41:14 mschneider: I dont believe that the spec does not demand that an ontology in functional syntax is actually an ontology 10:41:41 Boris has made a proposal that owl:imports of an RDF graph that does not have an ontology header acts like include, in that the target graph is *not* an ontology, and that the target graph is RDF-merged with the importing document's graph to generate a new RDF graph that is then subject to the reverse mapping 10:42:40 alanr: we should make a distinction of names between ontology documents and other things 10:43:14 q? 10:43:35 bmotik: according to the structural spec, an ontology is currently something that contains axioms and that imports other ontologies 10:45:59 ivan: we are back to the same idea of inclusion 10:47:42 bernardo has joined #owl 10:47:47 MarkusK: I like this: Yes, an Ontology is an abstract thing, a set of axioms. 10:47:50 markus: agree with Boris - ontology is an abstract object (axioms+imports) - relationship to documents is then needed only for imports 10:48:21 alanr: I support Marku's point of view 10:48:47 alanr: I think of an ontology as the document plus everything it imports 10:51:14 ivan: what about the database example boris mentioned? 10:53:27 markus: what happens with document transformation? 10:54:05 bmotik: everything that complies with the structural spec must be an OWL ontology 10:55:02 markus: so "syntactic" imports, only supported in RDF syntaxes, are resolved first, and the result can then be transformed to other syntaxes 10:55:06 bmotik: yes 10:55:20 PROPOSED: Close Issue 137 by making owl:imports of an RDF graph that does not have an ontology header act like include, in that the target graph is *not* an ontology, and that the target graph is RDF-merged with the importing document's graph to generate a new RDF graph that is then subject to the reverse mapping. 10:55:23 +1 10:55:29 +1 10:55:32 +1 (ALU) 10:55:38 +1 10:55:41 0 10:55:45 0 10:55:49 +1 10:55:54 +1 10:56:03 1 10:56:13 +1 (IBM) 10:56:32 +1 (Science Commons) 10:56:55 Alan is impressed with Zhe's presence 10:57:03 0 10:57:15 0 10:57:19 RESOLVED: Close Issue 137 by making owl:imports of an RDF graph that does not have an ontology header act like include, in that the target graph is *not* an ontology, and that the target graph is RDF-merged with the importing document's graph to generate a new RDF graph that is then subject to the reverse mapping. 10:58:12 LUNCH BREAK 10:58:21 topic:Lunch 10:58:28 -Zhe 11:23:56 FabGandon has left #owl 11:54:28 Rinke has joined #owl 11:57:52 bijan has joined #owl 11:59:44 baojie has joined #owl 11:59:44 Achille has joined #owl 12:00:46 msmith has joined #owl 12:00:46 alanr has joined #owl 12:00:53 scribenick: Achille 12:01:14 zakim, code? 12:01:15 the conference code is 69594 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), ivan 12:01:33 zakim, who is here? 12:01:33 On the phone I see Riviera_B 12:01:33 test 12:01:34 On IRC I see alanr, msmith, Achille, baojie, bijan, Rinke, bernardo, schneid, sandro, Christine, pfps, ivan, bmotik, MarkusK_, RRSAgent, Zakim, Zhe, trackbot 12:02:05 +msmith 12:02:07 IanH has joined #owl 12:02:42 topic: extending annotation framework 12:02:52 +baojie 12:03:14 alan: issue arising from concern from interop with larger OWL community 12:03:20 alan: two proposals: 12:04:36 alan: 1) vocabulary : annotation subproperty, annotation domain and range 12:05:06 ... first level: support it in the syntax without any semantics 12:05:23 ... issue: divergence with OWL RL 12:05:34 2 nd level: give it some semantics in OWL 12:05:38 wallace has joined #owl 12:05:57 ... it will add a type to the owl dl world 12:06:24 ... let do it for legacy consideration. 12:06:44 ... and introduce new vocabulary 12:07:43 ivan: user of annotation property used them in a way that is not 100 % conformamt in OWL 12:08:06 ivan: for annotations, we can just let it the way it stand now 12:08:26 dlm has joined #owl 12:08:58 ivan: they use it in a way not mandated by OWL or RDF 12:09:56 alan: a better path:just say that annotation properties do not work as integraty constraints 12:10:45 alan: my proposal: annotation properties have the standard RDF semantics 12:11:15 boris: two prob about addiing semantis: 12:11:31 ... 1) what would be the real semantics? this is really difficult 12:12:26 ... 2) from the point of view of their semantics, why would you need a new construct? why not use metamodeling ? 12:13:06 ivan: not certain if i need to have any kind of semantics 12:13:52 ... i am happy that these annotations are not accessible to OWL DL. 12:14:54 alan: to answer boris, i would agree with you if there were no consideration for legacy stuff 12:15:20 alan: i need a way to have subproperty propagation. 12:15:20 +Zhe 12:15:42 Welcome back Zhe! 12:15:45 ... we can leave it to tools, but it seems better to have it in the spec for interop. purposes 12:15:58 thanks 12:16:06 zakim, mute me 12:16:06 Zhe should now be muted 12:17:21 micheal: from the OWL Full point of view, nohting changes 12:17:32 s/nohting/nothing/ 12:18:36 boris: I am not sure that this is just a legacy issue 12:19:30 ivan: it would be nice not to consider SKOS ontology outside OWL DL because of they use of annotation properties. 12:20:21 bijan: people might be tempted to use punning for annotation as a way around the problem 12:20:50 bijan: I don't think it is a great solution (it means a shadow annotation system) 12:21:14 ... we can either bless it or explicitly provide an alternative 12:22:17 christine: This is a case where people will likely go to OWL Full to satisfy their requirements 12:22:45 ... at the moment, there is no correct solution 12:23:51 pfps: we did not talk to SKOS about things for which we did not have a solution (like the current problem with annotations) 12:24:38 boris: meta-ontology is the proper solution 12:25:12 ... inappropriate to mix annotations with your domain of discourse. 12:25:46 ... 1 ontology about the domain and another about the annotations seems to be an appropriate solution 12:26:50 ... we should not adopt a solution that would rule out this approach of meta-ontology 12:27:35 markus: another issue: you can find if it is an object or data propery 12:28:00 alan: not clear if the right solution for annotation is 12:28:28 ... I do not think we rule out meta-ontology approach by giving semantics to annotations 12:29:53 ... 1) annotation property allowed if there is another axiom making them data property 12:30:25 ... 2) annotation properties could have such little semantics that they would not be problematic 12:31:05 .. . my proposal for annotation: sub property, domain, and range and the same semantics as in OWL DL 12:31:44 michael: if we go with alan's proposal, the consequences are not clear to me 12:32:03 ... and it seems that there might be a lot of unknown consequences 12:34:19 boris: how about annotation on annotations? 12:34:42 boris: how about annotations on axioms? 12:35:13 alan: I do not see any need for annotation of axioms because I only care about legacy issue 12:36:37 michael: annotations will be used to annotate anything and will not respect restrictions imposed by any spec. 12:37:22 boris: it is safer to avoid giving a semantics for annotations 12:37:51 ... we should have a clear statement like they have no semantics at all. 12:38:08 +q 12:38:23 alan: to michael, the legacy ontologies are not OWL DL since you could not have annotations on axioms 12:38:25 q? 12:38:59 alan: in case where users do not respect the rules, they will simply have invalid ontologies 12:40:31 alan: in SKOS, you can see that current practice does not respect the boundary that you describe 12:40:46 s/ you/ refers to boris 12:41:50 bijan: I prefer to give a little now (something like alan's proposal) and let the users migrate later 12:43:24 bernardo: I can see you point with compatibility issue, but people do not seem to care about the semantics of annotation so far 12:43:41 boris: it is not my business fixing SKOS 12:46:14 michael: I'm happy with subclass, domain and range, but giving semantics means that reasoners which currently just get rid of annotation would have to deal with them now 12:46:57 christine: not sure why we think that users would need range for annotation 12:47:13 ... they really want constraints not range 12:47:41 ... I do not understand why we need to choice between two bad solutions 12:48:32 alan: 1) to bernado, tools ignoring stuff does not mean that users also do 12:48:49 ... this attitude toward annotation hurts us 12:49:15 ... 2) to christine, I do not see it as a bad solution. It will bring more customer to OWL 12:49:53 ...3) I do not think that mandating annotations to be either object or data properties helps 12:50:18 bijan: yes, range on annotations are often intended as constraints 12:51:04 ... the biggest obstacle is that we do not even make it possible to specify them 12:51:59 ianh: I would agree with a weaker proposal as a first step 12:52:16 s/ianh/alan 12:52:40 ianh: what do people thing about a weaker version of alan's proposal? 12:54:13 dlm has joined #owl 12:54:25 ianh: the proposal: we will have subannotation, annotation range and domain, they will have no semantics in OWL DL, but the normal semantics in OWL Full 12:55:38 STRAWPOLL: WHo is happy with adding three types of axioms -- AnnotationDomain, AnnotationRange, SubAnnotationPropertyOf -- to OWL 2 DL; map them to the starndard RDF vocabulary; no semantics on the DL side 12:55:52 +1 12:55:53 +1 12:55:56 +1 12:55:56 +1 12:55:59 +1 12:55:59 +1 12:56:01 +1 12:56:05 1 12:56:06 +1 for Ivan 12:56:08 +x where x > 0 12:56:10 +1 12:56:15 0 12:56:16 0 12:56:22 0 12:56:23 +1 12:56:23 0 12:56:25 0 12:56:34 Zakim, who is on the call? 12:56:34 On the phone I see Riviera_B, msmith, baojie, Zhe (muted) 12:56:38 ivan_ has joined #owl 12:56:50 ianh: it looks like we have a potential solution 12:57:28 alan: is there any support for adding semantics to annotation range, domain and subannotation? 12:57:52 ianh: I will formally object for adding semantics for them 12:58:18 Bijan is lying on the fence 12:58:55 bijan: I'm 100% against adding semantics 13:01:02 christine: these are new constructs that could be very difficult to explain to users 13:01:52 alan: can we have some sort of conformance for tools in terms of preserving annotations? 13:02:32 what will be difficult is to explain "AnnotationDomain, AnnotationRange, SubAnnotationPropertyOf -- to OWL 2 DL; map them to the starndard RDF vocabulary; no semantics on the DL side" 13:03:01 alan: it is related to roundtripping. I want to encourage tools to maintain annotations 13:03:41 ianh: should we finish with this proposal? 13:04:55 boris: annotations are part of axioms. They are first c;lass citizens. The spec does not state that they are in anyway less important than other axioms 13:05:19 +1 to bijan, bernardo 13:05:54 bernardo: i predict that annotations will no longer be routinely ignored by tools 13:06:08 bmotik has joined #owl 13:06:16 PROPOSAL: We add three types of axioms -- AnnotationDomain, AnnotationRange, SubAnnotationPropertyOf -- to OWL 2 DL; map them to the starndard RDF vocabulary; no semantics on the DL side. 13:06:43 +x where x>=1 (AUL) 13:06:58 PROPOSAL: We add three types of axioms -- AnnotationDomain, AnnotationRange, SubAnnotationPropertyOf -- to OWL 2 DL; map them to the standard RDF vocabulary; no semantics on the DL side. 13:07:08 +1 (Manchester) before the wireless goes down 13:07:10 +1 13:07:15 +1 13:07:16 +x where x>=1 (ALU) 13:07:18 1 13:07:18 +1 13:07:20 +1 13:07:21 MarkusK_ has joined #owl 13:07:21 0 13:07:24 +1 13:07:26 bernardo has joined #owl 13:07:29 +1 (Science Commons) 13:07:31 +1 13:07:39 +1 (Oxford) 13:07:55 +0 13:08:00 0 (RPI) 13:08:19 RESOLVED: We add three types of axioms -- AnnotationDomain, AnnotationRange, SubAnnotationPropertyOf -- to OWL 2 DL; map them to the standard RDF vocabulary; no semantics on the DL side. 13:08:35 bmotik_ has joined #owl 13:10:45 ianh: we are can move to the discussion on if/when to move the document to last call 13:10:47 ACTION: bmotik2 to Implement the resolutions from the 4F2F 13:10:47 Created ACTION-238 - Implement the resolutions from the 4F2F [on Boris Motik - due 2008-10-31]. 13:10:57 topic: Proposal to move to last call 13:12:13 scribenick: bmotik2 13:12:19 scribenick: bmotik 13:13:01 ianh: How to approach this? 13:13:21 alanr: The goal here is to get people's views about the schedule to LC 13:13:27 s/to/towards 13:14:02 alanr: In my view, the core 5 documents are (modulo the resolutions) pretty much ready to go 13:14:25 alanr: This does make the assumption that the n-ary document would be fully self-contained 13:14:50 alanr: It would contain the RDF Mapping. It would depend only on the hooks in the core spec 13:15:20 alanr: I propose that we hand over to Sandro these documents at the end of November 13:15:25 zakim, who is here? 13:15:25 On the phone I see Riviera_B, msmith, baojie, Zhe (muted) 13:15:27 On IRC I see bmotik, bernardo, MarkusK_, ivan, dlm, wallace, IanH, alanr, msmith, Achille, baojie, bijan, Rinke, schneid, sandro, Christine, pfps, RRSAgent, Zakim, Zhe, trackbot 13:15:54 alanr: In Profiles, there is still some tension about whether the rules are an implementation mechanism or a language specification 13:16:07 alanr: THis should be clarified for the Profiles 13:16:35 sandro has joined #owl 13:17:04 bijan: We have two choices to address this. 13:17:15 bijan: We can (1) delay the LC 13:17:37 bijan: We can (2) go to LC and have a quick fix later if we change our minds 13:17:52 alanr: I'd like to get the ready documents out right away and focus on that 13:18:22 alanr: The Conformance is another document that should go to LC later 13:18:34 alanr: Adjusting the conformance statements might be some more work 13:18:50 alanr: We might spend a part of November reviewing the test cases 13:19:04 Christine has joined #owl 13:19:49 alanr: Ivan raised the question of whether by going with Profiles to LC separated we'd be sending a message to the community that the Profiles are somehow less important 13:19:56 alanr: I'd blog related to that 13:20:42 ivan: I think it would be a problem to go to LC with the first 5 problems without the Conformance 13:21:30 ivan: The document itself could go to LC and we would be able to review the test cases later 13:21:44 ivan: I don't see a problem with Profiles 13:22:01 ivan: I would not be shocked by going with the Profiles to LC 13:22:10 rinke: I agree with Ivan 13:22:37 christine: I think we are ready to go 13:22:56 ianh: How do you feel about Conformance and Profiles 13:23:01 christine: I don't know 13:23:10 ewallace: I agree with Ivan 13:23:36 bijan: I also think we could go with all of these documents 13:24:03 achille: OK for everything except for RDF- Based semantics and Conformance; I don't know for these 13:25:05 mschnei: Direct Semantics and RDF Mapping is OK, I believe the XML Syntax is also OK, RDF-Based Semantics needs some more work. I'd prefer not to go to LC before Christmas 13:25:57 q+ 13:25:59 MarkusK_: I am fine with the core 5. Profiles can go to LC and we can have a short cycle and come back to potential issues. Regarding Test Cases, I'd like to ask msmith about it 13:26:01 zaim, who is here? 13:26:24 q? 13:26:29 Ianh: Sandro, can you remind us of a publishing moratorium? 13:26:35 sandro: I don't think there is one 13:26:42 I will come to you in a moment Mike. 13:26:48 Ivan: I think there is one. I would not count on beyond the 15th of DEcember 13:26:59 bijan: And it doesn't lift after the 5th of JAnuary 13:27:09 s/JAnuary/January 13:27:38 sandro: I don't know the state of Test Cases, but I think it makes sense to treat Conformance with the others 13:27:52 sandro: I could go either way regarding the Profiles 13:28:00 ack bernardo 13:28:21 bernardo: If the auhtor of the RDF-Based Semantics says it is not ready, I agree with him 13:28:27 bernardo: The rest seems ready 13:29:04 bernardo: I am worried about an empty section in the Conformance document 13:29:16 pfps: I think we should push everything and we should push Michael as well 13:29:29 mschnei: We need an internal review again 13:29:34 ianh: Do we? 13:29:39 alanr: Would you like it? 13:29:53 mschnei: I believe we need another review 13:30:14 ivan: He says that there will be some changes now and those have to be properly reviewed 13:30:30 bijan: We need to check the changes, but we don't need a formal review process 13:30:42 ianh: This is what we decided in our review period 13:30:54 msmith: I'm comfortable with core 5 + profiles. On conformance and test, I'm ok going without the test cases, but am a little concerned that the test format, etc. has not been widely reviewed or exercised. Approving tests will help that. I will go with group view of Conf&Test 13:30:55 bmotik: We should just ship them 13:31:07 ack msmith 13:31:12 msmith: I am OK with the core 5 and the Profiles 13:31:36 msmith: I am fine with the Test document without some test cases, but I share Bernardo's concern with some sections be empty 13:31:57 msmith: If we move forward, the test format should be subject to change 13:32:26 ianh: I am happy with the first 5, I also think we should go with the Profiles, I am on the fence regarding Confomance 13:32:44 ianh: The test cases are missing to a certain extent 13:32:55 q+ 13:33:00 ianh: I could go with it if other want to 13:33:09 ivan: LC means that we don't have a design issue open 13:33:19 ivan: This is what we have in our case 13:33:39 sandro: The Conformance part is OK; it's the tests 13:33:50 q? 13:33:53 alanr: We might want to split Test and Conformance 13:34:06 schneid has joined #owl 13:34:08 bijan: If we were to split them, then tests should not be a REC document 13:34:43 bijan: msmith, could you get it ready by the end of November? 13:34:45 ack msmith 13:34:48 ack msmith 13:34:52 msmith: The end of November yeah 13:34:57 msmith: That should not be a problem 13:35:52 ivan: Why do we have to have the Conformance and Test Case in the format we have? 13:36:32 q? 13:36:46 ivan: Can we move the tests outside of the T&C document and just insert a pointer to the test suite into the Conformance document? 13:37:18 ianh: Can we at least decide about the first 5? 13:37:27 PROPOSED: Publish "Syntax", "Direct Semantics", "RDF-Based Semantics", "Mapping to RDF Graphs", and "XML Serialization" as LAST CALL Working Drafts, after already-agreed-upon changes have been made and some editial cleanup (and checked by previous reviewers) 13:37:29 mschnei: RDF-Based Semantics is not ready 13:39:07 q? 13:40:14 bijan: If we can't go with the 5, does this mean we'd delay LC? 13:40:18 ivan: Yes 13:40:24 ianh: What is not ready? 13:40:33 mschei: I am not sure whether it is OK 13:40:51 http://lists.w3.org/Archives/Member/chairs/2008AprJun/0066.html Publication moratoria for second half of 2008 (23 December - 1 Jan === no pubs) 13:40:59 ianh: Could we do it in the way it was suggested for Profiles? 13:41:12 alanr: What are our expectations for the review? 13:41:40 alanr: If we did go to LC, we shouldn't make it short because this will include the Christmas period 13:42:04 bijan: By doing it before Christmas, we would have a lonver LC period 13:42:33 q? 13:42:33 bijan: I favor a longer review period but also geting a move on it so that we have time for a new cycle 13:43:07 sandro: The idea that Profiles and the RDF-Based Semantics follow shortly shouldn't be too big a deal 13:43:33 bernardo: Is it not important that an RDF-Based Semantics will be going to LC in the near future? 13:43:54 bijan: We might release a working draft with the core 4 LC documents 13:43:59 pfps: I agree with Bijan 13:44:27 alanr: It is hard for me to see that the RDF community be offended by publishing the RDF-Based Semantics slightly later 13:44:57 mschnei: The core 4 documents came from a Member Submission, so this can be taken as an excuse 13:45:11 ianh: I'm hearing now a fairly general consensus 13:45:20 ivan: I will not lie in the road 13:45:22 PROPOSED: Publish "Syntax", "Direct Semantics", "Mapping to RDF Graphs", and "XML Serialization" as LAST CALL Working Drafts, after already-agreed-upon changes have been made and some editial cleanup (and checked by previous reviewers) 13:46:27 PROPOSED: Publish "Syntax", "Direct Semantics", "Mapping to RDF Graphs", and "XML Serialization" as LAST CALL Working Drafts, after already-agreed-upon changes have been made and some editial cleanup (and checked by previous reviewers). Target publication date December 1. 13:46:43 +1 13:46:46 1 13:46:46 +1 13:46:46 +1 13:46:55 +1 (ALU) 13:47:03 +1 (UvA) 13:47:08 +1 (W3C) 13:47:09 +1 (FZI) 13:47:16 +1 (ORACLE) 13:47:18 +1 (uvsq) 13:47:19 +1 (Manchester) 13:47:20 +1 (IBM) 13:47:20 +1 (Science Commons) 13:47:20 +1 (NIST) 13:47:21 +1 (C&P) 13:47:24 +1 (Oxford) 13:47:41 +1 (RPI) 13:47:53 +1 for baojie :) 13:47:55 RESOLVED: Publish "Syntax", "Direct Semantics", "Mapping to RDF Graphs", and "XML Serialization" as LAST CALL Working Drafts, after already-agreed-upon changes have been made and some editial cleanup (and checked by previous reviewers). Target publication date December 1. 13:47:58 zakim, who is on the phone? 13:47:58 On the phone I see Riviera_B, msmith, baojie, Zhe (muted) 13:49:06 PROPOSED: Publish a Working Draft for the "RDF-Based Semantics" simultaneously (December 1) 13:49:20 +1 (ALU) 13:49:23 1 (W3C) 13:49:24 +1 (FZI) 13:49:25 +1 (UvA) 13:49:26 +1 (ORACLE) 13:49:27 + (Science Commons) 13:49:29 +1 (RPI) 13:49:31 +1 (Oxford) 13:49:34 +1 (IBM) 13:49:36 +1 (W3C) 13:49:37 +1(uvsq) 13:49:43 +1 (Manchester) 13:49:54 +1 (C&P) 13:49:55 +1 (NIST) 13:50:01 +1 (Science Commons) 13:50:33 RESOLVED: Publish a Working Draft for the "RDF-Based Semantics" simultaneously (December 1) 13:50:57 sure 13:51:07 claps remotely 13:51:16 sandro: Huge Congratulations Everyone! 13:51:21 topic: break 13:51:39 -Zhe 13:51:50 -msmith 14:00:27 dlm has joined #owl 14:05:57 baojie has joined #owl 14:08:36 dlmcg1 has joined #owl 14:14:53 zakim, who is here? 14:14:53 On the phone I see Riviera_B, baojie 14:14:54 On IRC I see schneid, Christine, sandro, bernardo, MarkusK_, ivan, wallace, IanH, alanr, msmith, Achille, bijan, pfps, RRSAgent, Zakim, Zhe, trackbot 14:15:54 dlmcg1 has joined #owl 14:16:46 +msmith 14:16:51 About to start again. 14:17:18 scribenick: ivan 14:17:49 Rinke has joined #owl 14:17:55 baojie has joined #owl 14:18:12 IanH: it seemed that most people thought the profile was ready, but alan did not 14:18:21 alanr: and ivan wanted to know why 14:18:49 alanr: the datatype reasoning support is a problem, a rule is there to generate all distinct literals 14:18:57 ... it is not practical 14:19:05 ... we could discuss that in some notes 14:19:12 ... but it looks like a big hole 14:19:32 ... maybe we can discuss by reducing expressibility and make it more practical 14:19:53 ... it adds n^2 literals 14:20:15 +q 14:20:16 ... if you have a million labels it adds million^2 labeles 14:20:49 zakim, who is here? 14:20:49 On the phone I see Riviera_B, baojie, msmith 14:20:50 On IRC I see baojie, Rinke, dlmcg1, schneid, Christine, sandro, bernardo, MarkusK_, ivan, wallace, IanH, alanr, msmith, Achille, bijan, pfps, RRSAgent, Zakim, Zhe, trackbot 14:20:56 ... the general tention we have in the document between being logic specificity and implementation guideliness 14:20:56 ... i try toe present that to be more conformatable 14:20:56 q+ 14:21:04 q? 14:21:13 ... the target audience for this are those who are not sophisticated developers 14:21:29 ... and we already have the statement that this will be implemented literaly 14:21:47 ack bernardo 14:22:09 bernardo: the fact we have a langugage means that this language can be implementable nicely 14:22:22 ... but the rules do not necessarily means that people will implement there 14:22:29 +Zhe 14:22:38 q? 14:22:41 ... the guidelines tell you what kind of reasoning can be done\ 14:22:47 ... it can be implemented this way and it will be o.k. 14:22:58 .... if you find an implementation that is better that is fine 14:23:18 pfps: I do not see any problem with the current status 14:23:23 ... it is a specification how the language works 14:23:33 ... we do not have a proposed solution how to fix this 14:23:37 ... it is done! 14:23:55 sandro: somebody made a rif implementation of owl-rl 14:24:07 ... i would expect that would be blessed to some degree by either rif or the owl working group 14:24:16 ... david raynolds did that the last few weeks 14:24:28 ... he had problems with the datatypes 14:24:54 ... he made a rif file that can be loaded into a rif processor 14:25:09 q? 14:25:20 bijan: follow up on bernardo's point, those seem to be an obvious inefficiency 14:25:45 ... a naive reaonser will go into trouble 14:26:01 ... a backward chaining engine would not have a trouble as it stands 14:26:14 ... some forward chaining rules would not either 14:26:34 ... the implementors are at least as sophisticated as the ones who have done rdfs reasoners 14:26:53 .... the target base is sophisticated enough to take the spec and adapt it for themselves 14:27:27 michael: we had the same discussion this morning, it is always the same 14:27:28 q? 14:27:40 ... we can get a lot of stuff with these kinds of rules 14:27:54 ... it is not necessary to do that and it is not hard to implement 14:28:01 Resolution of ISSUE 149 is by adding rules that axiomatise built-in entities (Thing, Nothing, etc) along with a new subsection that discusses how implementations could be optimised to deal with rules that potentially introduce large numbers of triples 14:28:06 michael: The problem is always the same -- there are naive ways to apply the rules that will cause big problems, but there are also smarter ways to do it. 14:28:37 +q 14:28:53 q- 14:29:05 ivan: 2 practical experiences 14:29:32 ... I have a naive implementation, and yes it will have issues Alan describes 14:29:50 ... but if I had a million triples I wouldn't try to use it 14:30:10 trillion triple 14:30:23 ... I talked to Ontotext and Franz inc and they told me that they built into their query language 14:30:45 ... a whole separate part to handle literals 14:31:00 http://www.google.com/search?client=safari&rls=en&q=define%3Abillion&ie=UTF-8&oe=UTF-8 14:31:00 ... and they don't care too much about adding triples 14:31:13 ... So, I'm not convinced we have a problem. 14:31:18 There is disparity in def of billion 14:31:53 alanr: i hear what people saying, i think there is still an issue of presentation 14:32:03 ... it needs a little bit more time to deal with that 14:32:03 -q 14:33:23 alanr: i was not here for the issue of 149, what it needs is a bit more than that 14:33:52 bijan: first this does not sound like a last call blocker 14:33:59 q? 14:34:09 ... before we do that such a text if it is expanded may be overtaken by events 14:34:20 q? 14:34:35 ... i do not see why this should be in the document 14:34:57 alanr: if you recall one of the issues was that it cannot be read by the target audience 14:35:21 ... my confort zone was to help that audience, something that is helpful 14:35:35 q? 14:36:37 q+ 14:36:48 zakim, unmute me 14:36:48 Zhe was not muted, Zhe 14:36:51 bernardo: is alan o.k. if we add some text saying that if this is implemented in naive way that can be inefficient, but giving some pointers 14:36:59 alanr: fine 14:37:35 Zhe: i think alan and I and a few other people exchanged a bunch emails, i do not think there is a big problem with the document, and i am o.k. this to go to last call 14:37:59 ... previously i was thinking to make the the rule set fool proof so that anybody could do an efficient implementation 14:38:09 ... but i realized gradually that this is not possible 14:38:20 q? 14:38:25 ... so i realize that some more should be done, and those additional are not too bad 14:38:29 +1 Zhe 14:38:49 not extremely more smart, a /bit/ more smart already will bring you a lot further, I guess 14:38:51 ack Zhe 14:39:01 PROPOSE: Profile document goes to Las Call at the same time as the others (Dec 1) 14:39:06 s/Las/Last/ 14:39:08 It really depends on a lot of factors, e.g., data set, rule engine etc. 14:39:08 +1 (IBM) 14:39:12 1 (W3C) 14:39:13 +1 (Manchester) 14:39:13 +1 (FZI) 14:39:15 +1 (ALU) 14:39:18 +1 (UvA) 14:39:20 +1 (ORACLE) 14:39:21 +1 (RPI) 14:39:21 +1 (Oxford) 14:39:22 +1 (W3C) 14:39:24 +1 (uvsq) 14:39:33 0 (Science Commons) 14:39:34 +1 (C&P) 14:39:44 +1 (NIST) 14:39:58 RESOLUTION: Profile document goes to LasT Call at the same time as the others (Dec 1) 14:40:15 IanH: conformance and test cases then? 14:41:08 IanH: what is our feeling? 14:41:25 MarkusK_: we had some discussions and the problems are with the test cases 14:41:45 ... the general idea is that this should be a description of the test case framework and schemas rathre than listing the cases 14:42:03 ... it is also desirable to align with the rif group who is working on their schemas 14:42:05 q? 14:42:26 ... the proposal is that I would contact them to see what the final shape of the document should be, and finish that before the end of the year 14:42:38 IanH: would that be a dependency on rif 14:42:45 q? 14:42:55 MarkusK_: no it is just informal, they already use much of the scema part that we also use this 14:43:04 ... it should be easy to align that further 14:43:27 q? 14:43:29 sandro: just having more faith that the stuff is correct is good 14:43:40 bijan: are we ready to sollicit test cases? 14:43:55 ... i was hoping to ask the owled people for new tests 14:43:59 MarkusK_: yes 14:44:02 q? 14:44:10 bijan: if that ready than I think it is ready to go last call 14:44:44 IanH: can you formulate a proposal we can vote on? 14:45:01 MarkusK_: on submitting people should not send email, I will set up a form based site 14:45:14 sandro: not that the wiki format is separate from what we're publishing, so submitting is a different question. 14:45:19 ... we can have a site where people can submit things and taht it 14:45:38 MarkusK_: the changes we have to do and editorial things, there are no fundamental changes 14:46:13 sandro: we will change things (uris) that might break software 14:46:15 q? 14:46:15 We expect to change these things before end of Nov 14:46:19 ... that is not really good for last call 14:46:23 q+ 14:47:08 MarkusK_: it might still change before last call, but we can sollicit test cases 14:47:17 q? 14:47:27 ack msmith 14:48:08 msmith: agree with MarkusK_, i have already written some software to get tests from the site 14:48:17 Sandro: So after Last Call of Test Cases, I wouldn't want the test-case-format spec to change, although maybe that's too strict. 14:48:41 PROPOSAL: move the Conf. and test cases to Last Call with the other documents (Dec 1) 14:48:45 the software that I've written pulls test case ontologies and does profile identification / alidation 14:48:57 s/alidation/validation/ 14:50:22 PROPOSED: If no new issues are found with it, and with changes already discussed, and some more hammering out of the test case format, we'll publish "Conformance and Test Case" with the other documents (target Dec 1). 14:51:13 +1 (FZI) 14:51:14 +1 (oxford) 14:51:14 +1 (W3C) 14:51:18 +1 (RPI) 14:51:19 +1 (C&P) 14:51:19 +1 (ORACLE) 14:51:20 +1 (Science Commons) 14:51:21 +1 (UvA) 14:51:22 0 (IBM) 14:51:24 +1 (ALU) 14:51:27 +1 (uvsq) 14:51:32 +1 (Manchester) 14:51:37 +1 (NIST) 14:51:55 RESOLUTION: If no new issues are found with it, and with changes already discussed, and some more hammering out of the test case format, we'll publish "Conformance and Test Case" with the other documents (target Dec 1). 14:51:57 ACTION: Markus to align OWL test case suite with RIF efforts, and to make required editorial changes to test part of "Conformance and Test Cases" 14:51:57 Sorry, amibiguous username (more than one match) - Markus 14:51:57 Try using a different identifier, such as family name or username (eg. mkrtzsch, mstocker) 14:52:24 ACTION: mkrtzsch to align OWL test case suite with RIF efforts, and to make required editorial changes to test part of "Conformance and Test Cases" 14:52:24 Created ACTION-239 - Align OWL test case suite with RIF efforts, and to make required editorial changes to test part of \"Conformance and Test Cases\" [on Markus Krötzsch - due 2008-10-31]. 14:52:38 Topic: other documents 14:53:45 http://lists.w3.org/Archives/Public/public-owl-wg/2008Oct/0160.html 14:53:56 Jim's email on UCR 14:54:12 alanr: requirements document? 14:54:29 ... what issues remain, what the roadmap is 14:54:38 ... reviews and workplans are on the table 14:54:56 ... maybe people who have opinions to speak up now 14:55:22 ... we are heading for first public working draft and then issue is rec track 14:56:03 Rinke's email: 14:56:21 Rinke: i think the use cases should be in there, but section 5 is the core of the document 14:56:38 ... the idea would be to move the use cases in the appendix and refer to that from the core 14:56:50 ... also remove the domain dependence of the use cases 14:57:02 .... they should not be so clearly bound to a domain 14:57:31 Christine: i just agree with bijan's and Rinke's proposal 14:57:40 ... and to put the use cases in the appendix 14:58:07 ... i only implemented the decision of the user facing document group who asked to make those three documents 14:58:24 ... i am o.k. to keep the features, this is the core of the document 14:58:43 .... it is important to have a human facing part that describe all the new features 14:58:43 q+ 14:59:00 ... all these are editorial changes only 14:59:21 ... i can also remove the domain aspects, 14:59:38 ... for each feature there is a 'tag' to assign them to domains 15:00:28 alanr: rinke was also suggesting if you read 3.10, there is lot of text on clinical trials, hcls, etc 15:00:54 ... i thought that the proposal was to remove thos specific case and, in some cases, add text from other areas 15:01:02 ... christine, what do you think about that? 15:01:39 Christine: I would cut the use cases section, put it somewhere, if somebody want to work on the formulation, that is fine 15:02:02 ... but i would like to have only editorial chagnes 15:02:22 ... i would prefer to keep the text like it, only editorial information 15:02:35 .... i am o.k. to remove all that stuff 15:03:00 ... if you go to the feature section, there are three buttons to stress the example, the implementation or the theoretical perspectives, 15:04:34 wallace: i am confused because I read rinke's mail differently 15:04:48 ... now i am confused 15:05:01 Rinke: my preference would be to have more general issues with those use cases 15:05:10 ... but i am o.k. with a more superficial changes 15:05:32 wallace: i think what rinke suggests is a good way to go 15:05:46 ... i understood the idea was the requirements to the features' sectioon 15:06:09 ... this looks like a nice way to go 15:06:23 bijan: i like section 5, i am not sure to include the grammar 15:07:05 ... my idea roll sections 4 into 5, dump the rest 15:07:32 ... looking at the use cases i do not think that making them more abstract would be more helpful 15:07:58 ... i have problem with the non changable status of the document 15:08:10 ... if i could change them later that would be o.k. 15:08:25 ... if we made it a placeholder for later 15:08:31 ... eg in the esw 15:08:35 ... it could be viable 15:09:11 ... eg we discussed about updating the test cases beyond the group 15:09:21 ... something similar could work 15:09:32 ... i like section 5 a lot 15:10:08 Achille: i like the features and requirements, initially i thought the use cases being too long and too long, putting them in the appendix 15:10:22 ... i like the ide of bijan to put it to a place where we can update it 15:10:39 michael: making use cases more abstract would help you work 15:10:55 ... if at all, come up with new use cases in other domains 15:11:06 alanr, can I say something? 15:11:08 bernardo: agree with bijan 15:11:41 ... i am not such a need to update in a very abstract way 15:11:48 ... it is really difficult to make this explicit 15:12:06 ... if we were to move that into a place where we could maintain them 15:12:11 .... section 5 is the core of the document 15:12:38 IanH_ has joined #owl 15:13:16 Zhe: i am in love with section 5, it does not belong to a requirement document 15:13:39 .... a requiement document should focus on use cases and the job is done 15:14:17 IanH_: i am happy with the stage of the document 15:14:39 Ivan says: 15:14:52 closest to opinion of Zhe 15:15:13 Use case and req are more for documenting the history 15:15:19 what stays long term is section 5 15:15:30 Take section 5 as other document 15:15:39 suggestion: Take section 5 and merge with QRG 15:15:56 +q 15:16:00 dlm has joined #owl 15:16:02 That way there is one place to go for all parts of the language - overseeable good document to give people outside 15:16:50 q+ christine 15:16:56 bijan: to speak to the concern of the traditional requirement document, this is exactly the requirement we had 15:16:56 ... it was enormously useful for the language 15:17:15 ... this is not like the traditional u&R documents 15:17:55 (scribe was a bit lost) 15:18:17 ack Zhe 15:18:22 ack baojie 15:18:33 dlmcg2 has joined #owl 15:18:37 q+ 15:18:40 baojie: i love section 5, just rename the document to reflect design considerations 15:18:44 zhe: let's add "design rationale" as part of the title. 15:18:59 ... about ivan's document of merging it with the reference guide, i am not sure about that 15:19:02 +1 to keeping separate from the requirements/rationales 15:19:21 ack christine 15:19:23 ... the quick reference guide has other goals 15:19:30 section 5 is useful. however, it gets into design domain. maybe we can rename the document to "Requiremetns and Design Rationale" 15:19:39 Christine: i think the name of the document are details to be agreed later 15:20:02 ... we have to agreed on the principle on this content to be working draft document and i just want to answer 15:20:27 ... i agree it would be highly useful to have this section with the quick refernece guide 15:20:42 ... it would help to access the whole language and to caption of the new features 15:21:01 ... having the sue cases somewhere it would be useful, with links from the documents 15:21:23 ... from the quick reference guide there will be links tot he spec, from the features to the use cases 15:21:25 I'm confused...section 5 doesn't cover all of the language..so the quick reference guide can't really use it 15:21:44 ... and I am not sure about the use cases to be updated 15:21:48 q+ Bijan 15:21:59 ... the used case give a requirement for the language, it has to be frozen at some point 15:22:12 ... there is no reason to update the use cases 15:22:27 ... afaik a w3c has often a requirement section, that is frozen 15:23:42 alanr: section 2 should be out, some people like use cases, could be good to move them elsewhere and slightly neutralize them 15:23:59 .... i have some doubts whether they would be updated 15:24:03 bijan: there is a misunderstanding 15:24:16 ... this is not a requirement document for the language design 15:24:23 ... it is a post facto rationalization 15:24:55 ... what is the most useful thing this design gives? what is the design of the language? what is the use of owl and owl2 15:25:12 ... use cases can be expanded 15:25:33 ... i do think that people come to see use cases to understand 15:26:07 q+ 15:26:08 ... if we give this a static thing this would be messing them up 15:26:22 bijan: I see this document as a way to explain OWL2 to users -- and we'll get better at that as time goes along. There's really no need for use cases. 15:26:27 q? 15:26:30 ack alanr 15:26:33 ack Bijan 15:26:41 Zhe: bijan, do you object to rename the document 15:26:44 ack Zhe 15:26:48 bijan: i do not care abou tthe name 15:27:07 .... i am happy with anything, requirement and blablabla 15:27:12 bijan: I like "Features and Rationale" as the title. 15:27:17 Christine: so do I. 15:27:30 alan: broad consensus that Section 5 is great content. 15:27:37 it is indeed great content! 15:27:37 alan: no support for users and applications 15:27:37 alanr: concensus on section 5 great content 15:27:47 alan: some support for use cases -- as appendix 15:28:13 alanr: the most contentious one is the question of use cases and where they go 15:29:43 alanr: a straw poll on on the fate of use cases (section 3): (1) get rid of them altogether, (2) put them in an appendix (3) put the use cases in some place where they may be updated 15:30:02 (4) status quo 15:30:08 STRAWPOLL: For section 3 (use cases) -- 1== get rid of it 2==put them in an appendix 3== put them some place where they can be updated. 4==leave it as is 15:30:21 3 15:30:24 3 15:30:30 3 15:30:32 2 15:30:35 4 and 2 15:30:41 0 15:30:49 0 (abstain) 15:30:51 0 15:30:52 2 15:30:55 2, 4 15:31:03 3 15:31:05 four 15:31:08 2 15:31:11 2 15:31:24 4, 3 15:31:38 quatre? 15:31:50 Christine: in the description of each feature ther eis a list of use cases, it is supposed to have links to link use cases 15:33:34 four 3-s, five 2-s, four 4-s, 15:33:45 for 2: baojie Christine sandro ivan alanr 15:33:45 for 3: Rinke bernardo bijan wallace 15:33:45 for 4: Zhe pfps IanH 15:33:53 winer is probably 2, 15:34:01 I can switch to 2, and 4 if that makes things better 15:34:43 alanr: what woudl people would say if 3 is not accepted 15:34:47 bijan: my backup is 1 15:35:02 alanr: majority would probably go to 2 15:35:09 dlm has joined #owl 15:35:32 sandro: we can have an appendix which says that 'there is a wiki for this, that can be udpated...' 15:35:47 http://www.w3.org/2007/OWL/wiki/RequirementsDraft#Use_Case_.235_-_OBO_ontologies_for_biomedical_data_integration_.5BHCLS.5D 15:36:02 bijan: for people who chose 2 what do you get from the use case? 15:36:28 Christine: for each use case there is a full paper online, people can go and find the paper on line 15:36:29 ... these are only short abstracts 15:36:44 ... this was the criteria to select one or not 15:37:04 Rinke: the formal reasons for doing this is to back up the requirements 15:37:22 ... having no use cases is not really good 15:38:03 alanr: what i like about seeing these, that there are people who have really used this 15:38:27 ... it is better at the appendix rather than not have this 15:38:39 bijan: i did not realize that those links are there 15:38:53 ... some of the use cases are not really use cases 15:38:53 ... there is a lot fo them 15:39:11 Bijan: Make it something more like an annotated bibiliography. 15:39:20 ... presenting all this as an annotated bibliogrpahy, it is providing an abstract description 15:39:33 ... then having it static is fine becasue it is also historical 15:40:27 Bijan: it's okay to call it use cases. 15:40:45 Christine: send me the sentence to be put 15:41:04 "Use Cases: An Annotated Bibliography" 15:41:14 bijan: i am happy taking an action to reformat one of the entry 15:41:40 ACTION: Bijan to show a format for the use cases that he likes, making clear what it is and does. 15:41:41 Created ACTION-240 - Show a format for the use cases that he likes, making clear what it is and does. [on Bijan Parsia - due 2008-10-31]. 15:42:51 alanr: for the next week's meeting, i would propose to cancel the meeting 15:42:56 No Meeting Next Week. 15:43:21 alanr: I think we are fine with that document 15:43:31 Christine: i want to know the future of the document 15:43:42 alanr: there is a question whether it is a rec track or a note 15:43:56 ... we are moving the document ahead 15:44:13 ... i would propose to consider this as a rec track document 15:44:34 ... it may avoid disagreements and criticisms 15:45:14 bernardo: what is the w3c a recommendation 15:45:26 ... what is w3c recommending 15:45:36 sandro: what it means that it has been widely reviewed by the community 15:46:12 bijan: if we decide this document become a rec, we make a case for all use case dodcuments to be rec track 15:46:38 bernardo: there is a difference, there is a useful information in this document 15:46:50 alanr: plus the level of quality in them 15:47:08 Alan: I'm open to any document being a REC if the quality is good enough. 15:47:29 IanH_: i agree with bijan, every additional document you give rec track too, 15:47:46 bijan: i am in principle having all these rec track 15:48:06 pfps: i think that w3c has made a disservice to make non-normative documents rec track 15:48:11 +q 15:48:16 PFPS: I think the bar for Rec Track should be "rec track". 15:48:26 ... the precise part to be rec track is when you have normative status 15:48:31 q? 15:49:10 pfps: this one is below that one. THere is a distincition between this one and the primer, this one has some impact on our spec 15:49:44 http://www.w3.org/2007/06/OWLCharter.html 15:49:51 baojie: remind of jim's remark, the charter says that the requirement might be part of the deliverables as rec 15:50:01 "Requirements: 15:50:01 A description of the goals and requirements that have motivated the design of OWL 1.1. 15:50:02 " 15:50:28 alanr: I am not sure that mandates us, but there might have been an expectation on us 15:51:28 sandro: webont pushed the w3c process and we are pushes more. We have a technical spec and a manual, and for whatever reasons of process and credits we split it into lots of documents 15:51:50 ... i would not split hairs on that, and say this is all documenations 15:52:16 schneid: this would mean that only technical documents that can be rec track and user facing document cannot? 15:52:33 alanr: peter pointed out that there is room for this document 15:53:25 Sandro: I'd say imagine this is all one or two big documents, which are Recs. the fact that we're splitting it up, ehhhh, not so important. 15:54:31 STRAWPOLL: yes==accept this document as a rec and accept this document on a case by case basis no==keep it as a note 15:55:16 Please note OWL 1 has user facing document as rec, e.g., http://www.w3.org/TR/owl-guide/ 15:55:59 STRAWPOLL: 1==accept this document as a rec and accept subsequent documents on a case by case basis 2==make it as note 3==decide as a package 15:56:09 3 15:56:12 3 15:56:15 1 15:56:15 3 15:56:19 1 15:56:20 0 15:56:20 1 15:56:22 1 15:56:27 1 15:56:27 1 15:56:29 3 15:56:35 3 15:56:36 3 15:56:39 3 15:56:39 3 15:57:18 eight 3-s, six 1-s, no 2-s, and one 0 15:57:54 schneid: we should have OWL as rec, and not this one and this one 15:58:07 bijan: i dislike things that do not have normative value as a rec 15:58:27 Bijan: I've always disliked the practice of things that don't have normative force being called a "Recommendation". I'd like us to be consistent. 15:58:29 ... the more recs you have tends to make other things look stranger 15:58:50 Christine: i definitely have problems deciding altogether 15:58:52 q+ 15:58:57 ack baojie 15:58:58 ... there is a level of quality to be a rec 15:59:07 ... if we have to decide it for a package 15:59:24 bijan: what I meant is at the same time! 15:59:46 Christine: one of the other documents may take a long time to be ready and this time may take a week 16:00:05 alanr: the status of the document does not reflect 16:00:16 ... the final goal of the document 16:00:35 pfps: We Want Uniformity. 16:00:41 alanr: i do not think we have concensus 16:00:59 +q 16:01:03 ... there is a significant portion of the people that would be leaning towards a rec 16:03:10 there was a larger portion that did not give a preference 16:03:38 meeting adjourned 16:03:48 have a nice trip back home! 16:04:09 sandro: we need a fight to right home about. 16:04:21 Rinke has left #owl 16:04:21 -Zhe 16:04:47 so, we leave the rec status of all "other" document decided? 16:05:09 s/decided/undecided 16:05:33 Sandro: Ah, I didn't know the editor was only willing to work on this if it was going to be a Rec. 16:05:37 Alan: Oops. 16:07:12 ivan has left #owl 16:08:38 rdfa primer is a note - but will probably be the RDFa document most read by people 16:17:53 zakim, who is here? 16:17:53 On the phone I see Riviera_B, baojie, msmith 16:17:54 On IRC I see dlm, IanH_, baojie, schneid, Christine, sandro, MarkusK_, msmith, bijan, pfps, RRSAgent, Zakim, trackbot 16:17:56 -baojie 16:18:52 zakim, who is here? 16:18:52 On the phone I see Riviera_B, msmith 16:18:52 Rinke has joined #owl 16:18:53 On IRC I see dlm, IanH_, schneid, Christine, sandro, MarkusK_, msmith, bijan, pfps, RRSAgent, Zakim, trackbot 16:29:22 PROPOSED: Target date for FPWD publication of UCR is Dec 1, along with the other document.s 16:29:44 (this is informal, since the meeting is adjourned) 16:30:01 (but everyone is sounding encouraging. there is no disagreement.) 16:30:13 (no one has even considered that we won't publish it.) 16:30:27 +1 16:30:33 +1 16:34:18 -Riviera_B 16:34:21 -msmith 16:34:22 SW_OWL(F2F)2:30AM has ended 16:34:24 Attendees were Riviera_B, Zhe, msmith, baojie 16:37:48 msmith has left #owl 16:59:18 dlm has left #owl 19:27:20 alanr has joined #owl 20:16:32 IanH has joined #owl 20:37:03 IanH_ has joined #owl 21:56:41 Zakim has left #owl