Chatlog 2008-10-24

See original RRSAgent log and preview nicely formatted version.

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

<sandro> PRESENT: Ian, Boris, Pfps, Bernardo, Sandro, MarkusK, michael_schneider, Achille, bijan, wallace, Christine, Rinke, Ivan, alanruttenberg
<sandro> REMOTE: Zhe, baojie, msmith

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