- From: Boris Motik <boris.motik@comlab.ox.ac.uk>
- Date: Sun, 28 Sep 2008 15:08:30 +0100
- To: <public-owl-wg@w3.org>
Hello, Here is my response to some general comments that were embedded in the document and to the comments by Jeff. Here is the diff: http://www.w3.org/2007/OWL/wiki/index.php?title=Profiles&diff=13466&oldid=13235 I'll send a response to Ian's and Jim's comments shortly. Please let me know should you think that some comments need further attention. Regards, Boris ---- Some general comments ------------------------- Several people have asked be whether reflexive properties could be removed from OWL-RL. As I explained in an e-mail (http://lists.w3.org/Archives/Public/public-owl-wg/2008Sep/0212.html), this might indeed make sense. Since nobody complained, I removed them. I have also addressed two review comments that were inserted directly into the document. @Mike Smith, Section 4.2.3: It seems incorrect that the IntersectionOf terminal for superClassExpression requires a single subClassExpression. Is this a cut and paste error? Yes, sorry! @Ivan, Section 4.3: The two rules for qualified max cardinality are missing. They should be added probably before the one on owl:oneOf. They are almost identical to the two rules on maxCardinality, except for the usage of owl:onClass to express the additional constraint. I have added the missing rules. In fact, there was an error in the unqualified rules for maxCadinality 0. It would be good if someone would take a second look. ---- Review by Jeff -------------------------------- > Section 1 > ========== > In general, some references are needed to support some of the > claims, such as those about useful application scenarios for the > three profiles. Also, after a quick check, we didn't find any > complexity results about instance checking in OWL 2 EL in the > references [EL++, EL++ Update]. Also, these two references are > only given in Section 2. > > The OWL 2 EL bulletin point in Section 1 says > > [[ > Dedicated reasoning algorithms for this profile are available > and have been demonstrated to be implementable in a highly > scalable way. > ]] > > However, we could not find algorithms (that can be followed by > implementors who are not logicians) for the full OWL 2 EL from > [EL++, EL++ Update]. > The standard classification algorithm for EL++ is immediately applicable to instance checking in EL++: after running the algorithm, the label of each individual provides exactly the classes that the individual belongs to. This may not have been explicitly stated in the EL++ papers; however, this fact follows in a really straightforward way from [EL++]. Thus, there is no a separate reference that I can cite. Because of that, I have not made any changes in response to this review comment. Please let me know if you are not satisfied with this. > The OWL 2 RL bulletin point in Section 1 says > > [[ > OWL 2 RL reasoning systems can be implemented using relatively > simple technology, ...conjunctive query answering can be implemented by > extending a > standard relational database system with rules. > ]] > > We could not find any further discussions about using relational > database systems to implement OWL 2 RL; thus, the sentence is not > very helpful in the Introduction. We should either delete this > sentence or provide some reference to provide further details. > > I agree that this sentence is misleading: it leaves an impression that OWL 2 RL can be implemented only by means of database technology. This is indeed incorrect. Therefore, I have changed this and the following sentence into this: OWL 2 RL reasoning systems can be implemented using rule-based reasoning engines. Such rule-based approaches can be used to perform consistency, satisfiability, subsumption, classification, instance checking, and conjunctive query answering in time that is polynomial with respect to the size of the ontology. > Section 2 > ========== > > The design principle for OWL 2 EL seems to be a bit confusing. The > first sentence of Section 2 says > > [[ > The OWL 2 EL profile [EL++,EL++ Update] is designed as a maximal subset > of OWL 2 that > * captures the expressive power used by many large-scale ontologies and > * for which the following reasoning problems can be decided in > polynomial time: > satisfiability, subsumption, classification, and instance checking. > ]] > > Being a maximal subset of OWL 2 seems to indicates OWL 2 EL is a > superset of OWL 2 QL and OWL 2 RL, which is not the case at all. > For example, OWL 2 QL provides inverse roles that OWL 2 EL does > not support, and OWL 2 QL still enjoys polynomial time complexity > for the mentioned reasoning problems. As for OWL 2 RL, it supports > some form of number restrictions that OWL 2 EL does not support, > and OWL 2 RL also enjoys polynomial time complexity for these > reasoning problems. To some extent, all the three profiles are > maximal subsets of OWL 2, and the above design principle does not > really distinguish OWL 2 EL from the other profiles. > I have removed the word "maximal". > The sentence before Section 2.1, a reference should be provided > for SNOMED CT. On the other hand, it is good that some specific > applications are mentioned here, while we need to provide similar > kind of information for OWL 2 QL and OWL 2 RL. > I have added a reference that points to http://www.ihtsdo.org/snomed-ct/. > Section 2.2.6 is a bit difficult to follow. If it is hard to be > followed by WG members, it is likely to be hard to be followed for > other readers. To make it more readeable, we should at least > provide a reference here, i.e., [EL++ Update]. I have added it. > There are two > points that we should further clarify here: > > 1) It seems that in order to have PropertyRange (OP1 CE) we need > to have some super property OPk or OP1 with the following axiom > PropertyRange (OPk CE) appearing in the ontology. One might ask > how we could have PropertyRange (OPk CE) in the first place, does > it require a further super property OPk+1 with a range axiom? > You do not need to have a superproperty: it was possible for k to be 1. Now this might now have been clear. To clarify this, I have rephrased the paragraph like this: We say that Ax imposes a range restriction to CE on an object property OP1 if Ax contains the following axioms, where k ? 1 is an integer and OPi are object properties: > 2) According to {EL++ Update], the condition is vacuously true for > role hierarchy statements, but in Section 2.2.6, even for > SubProperty (OP1 OPk), we still need to have the restriction, > i.e., having PropertyRange (OPk CE) in the ontology to allow the > use of PropertyRange (OP1 CE). > I'm not sure I understand this comment. This condition merely expresses the fact that, if Ax contains the axioms, say, SubPropertyOf( PropertyChain( R S ) T ) PropertyRange( T C ) then Ax must contain as well the axiom PropertyRange( S C ). I have not changed the document in response to this comment. Please let me know if you are unhappy with this. > At the end of Section 2.2.1, a list of datatypes that must not be > used in OWL 2 EL are provided. This is unclear what are the > rationale of disallowing them. Is that because of the complexity? > Some references would be helpful here. Disallowed datatypes in OWL > 2 QL and OWL 2 RL should be treated in a similar manna. > All profiles enjoy the "single model property": each ontology of each of the profiles can be interpreted in only one model. To achieve this, you need to get rid of disjunctions. Regarding datatypes, you have to ensure that you can encounter only infinite datatypes during reasoning. To ensure that, you need to eliminate datatypes whose intersection is finite. For example, if we allowed for owl:real and owl:realPlus, then one could write an ontology where the range of a property is restricted to be exactly the four special values; but then, we would get a disjunction and would loose the "single model property". Now I'm not sure about how to present this decision in the document. I don't think this document is an appropriate place to talk about models and such. I've therefore added the following rather vague statement at the end of each of the datatype sections. The set of supported datatypes has been designed such that the intersection of the value spaces of any set of these datatypes is finite, which is necessary to obtain the desired computational properties [<cite>[[#ref-ELpp|EL++]]</cite>]. Consequently, the following predefined OWL 2 datatypes <em title="MUST NOT in RFC 2119 context" class="RFC2119">MUST NOT</em> be used in OWL 2 EL: > > Section 3 > ========== > It is worth mentioning the applications (with references) of OWL 2 > QL in the beginning part of Section 3, like what was done in > Section 2 for OWL 2 EL. > The introduction already says that OWL 2 QL can express features of UML and ER. I wouldn't go further into a debate about the types of applications. I haven't changed the document in response to this comment. > Near the end of Section 3, the draft says > > [[OWL 2 QL disallows negative object property assertions and > equality axioms. ... Equality and inequality axioms and > property assertions are the same as in OWL 2. > ]] > > This is confusing - on the one hand, equality axioms are > disallowed, while on the other hand, equality axioms are the same > as in OWL 2. > Yes, that was a ghost. I removed "Equality and". > > Section 4 > ========== > The first sentence of Section 4 says > > [[ > The OWL 2 RL profile is aimed at applications that require > scalable reasoning without sacrificing too much expressive power. > ]] > > This seems to be a bit vague and not very helpful - it makes OWL 2 > RL sounds like OWL 2 EL, which is claimed to be the maximal subset > of OWL 2 to provide scalable reasoning (see Section 2). > Furthermore, it is unclear how much sacrifice of expressive power > is not too much. > Again, I would prefer not to go into a polemic on what is too much and too little. Feel free to suggest a concrete alternative for this section. > There seems to be a big jump between Section 4.2 and Section 4.3. > After the former section, readers would expect to see how OWL 2 RL > ontologies can be translated into logic programs. Instead, Section > 4.3 is about RDF rules rather than the above translation. The big > picture isn't clear until Theorem 1 at the end of Section 4.3. The > would be more readable if RDF rules are explicitly mentioned at > the beginning of Section 4. > But this is already done right after Table 1. > The first sentence of Section 4.1 says > > [[ Restricting the way in which OWL 2 constructs are used makes it > possible to implement reasoning systems using relatively simple > technology - in particular, rule-based reasoning engines - while > still providing desirable computational guarantees. ]] > > This unclear why rule-based reasoning engines are relatively > simpler. Some justifications are needed. > I have removed the word "simple". > Section 4.2.3, there is only one subClassExpression (with > maxCardinality for ObjectPropertyExpression) used in the > production of superClassExpression. Is it a typo? Otherwise, some > explanations are needed. > Yes, this was a typo. Sorry! > In Section 4.2.5, it would be helpful to explicitly state that OWL > 2 RL disallows both negative class assertions and negative > property assertions. > The description of OWL 2 RL lacked a general list of supported axiom types, which I have not added. I haven't, though, listed all the different axiom types: OWL 2 RL supports almost all axioms of OWL 2, so listing them seemed superfluous. I have just listed the axiom types that are disallowed in OWL 2. > After Table 8 in Section 4, the draft says > > [[ > Note that the rules relating to rdfs:domain and rdfs:range > reflect the IFF semantic conditions of the OWL 2 RDF-Based > semantics [OWL 2 RDF-Based Semantics] rather than the weaker > ONLY-IF semantics of RDFS [RDF Semantics]. > ]] > > More explanations are needed here: What do the rules look like if > we use the weaker ONLY-IF semantics of RDFS? With the weaker > semantics, will Theorem still hold? > Theorem 1 would hold nonetheless. I do agree, though, that this sentence came a bit out of the blue. I have therefore removed it: this document should serve mainly as a normative definition, and it does not seem to be an appropriate place for discussing various consequences of different semantics. > The next paragraph, the draft says > > [[ > OWL 2 RL/RDF rules include neither the axiomatic triples and > entailment rules of RDF and RDFS [RDF Semantics] nor the axiomatic > triples for the relevant OWL vocabulary [OWL 2 RDF-Based > Semantics], as these might cause performance problems in practice. > ]] > > However, the current RDF rules don't seem to very scalable either. > For example, the third RDF rule in Table 7 adds > > T(lt1, owl:differentFrom, lt2) > > for all literals lt1 and lt2 with different data values. If we > have 10^x different data values, we will then need to add 10^2x > generalised triples of the above form. > This sentence was introduced as a consequence of the resolution of ISSUE-144 (Base triples). Let us not reopen "old wounds" :-) > > Section 5 > ========== > > The first paragraph of Section 5 is redundant; the same idea is > repeated in the third paragraph. > I agree, and I have reorganized the first few paragraphs. > It seems to be better to move the second paragraph after the > introduction of the reasoning problems. Also, this paragraph says > > [[ > None of the described profiles, however, is propositionally > closed, so these reasoning problems thus can have different > complexity and require different algorithmic solutions. > ]] > > This seems to indicate in Table 8, for some profiles, that the > problems of ontology consistency, class expression satisfiability, > class expression subsumption and instance checking, could have > different complexity, which is not the case at all in Table 8. > This sentence thus does not seem to be very helpful in the > context. > I agree, and I have removed this sentence. > After Table 8 in Section 5, the DL Handbook and the Description Logic > Complexity Navigator are mentioned. Again, they don't seem to be > very helpful here. For the DL Handbook, we are not sure if all (or > any) the new results about the profiles are included. For the > Navigator, it is mainly based on the assumption that the supported > constructors can be used on both sides of concept inclusions; > hence, it is not obvious how to check the complexity results for > the profiles, in which there are detailed restrictions on where > certain constructors can appear. > I agree, and I have removed this sentence. > > Typos > ========== > Section 3.2, 1st paragraph, 2nd line: restriction -> restrictions > > Section 3.2, 1st paragraph, 2nd line: DL-lite -> DL-Lite > > Section 3.2.3, 1st paragraph, 4th line: can occur -> occur > > Section 3.2.5, 1st paragraph, 3rd line: remove "them"? > > Section 3.2.5, the paragraph before the following production, 2nd > line: "object property" should be "data property"? > > [[ > DataPropertyDomain := 'PropertyDomain' '(' { annotation } > DataPropertyExpression superClass ')' > ]] > > Section 4.2.1, 1st paragraph, 1st line: EL -> RL > > Table 1: "a class descriptions" appears twice > I wasn't able to find this error -- can you please be more specific? > There are two Table 8 in the draft > > > The University of Aberdeen is a charity registered in Scotland, No SC013683. >
Received on Sunday, 28 September 2008 14:10:14 UTC