W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Re: ACTION-320 Review profiles

From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
Date: Tue, 7 Apr 2009 12:48:29 +0100
Message-Id: <C0769DF4-B18C-4813-9A5A-4C7017B74FCE@comlab.ox.ac.uk>
Cc: W3C OWL Working Group <public-owl-wg@w3.org>
To: Jie Bao <baojie@cs.rpi.edu>
Many thanks for the very detailed and thoughtful review. I have dealt  
with most of the comments -- see inline discussions in those cases  
where there was some doubt.


On 1 Apr 2009, at 17:06, Jie Bao wrote:
> Review of OWL 2 Profile
> By Jie Bao
> The version I looked at was:
> http://www.w3.org/2007/OWL/wiki/index.php?title=Profiles&oldid=19851
> (13:45, 17 March 2009)
> Profile is in general a well-written, clear technical document. Thank
> all editors for a brilliant job.
> Some of the detailed comments are given below. In general, my main
> high-level comments are that the document should be improved for users
> who do not necessarily have logic or computational complexity
> background. The distinction between profiles should be further stated
> – the current wording does make it quite explicit.
> ==Introduction==
> #0: We should say something about the audience, such as prerequisite
> knowledge on RDF for RL (and whatever else).

This could be said of all of the documents, and I don't want to add  
something here "unilaterally". I will raise the matter with other  
editors and see if they want to add something to all of the  
"technical" documents. Hopefully, the issue is now addressed (to some  
extent) by the Overview.

> We also need to indicate
> that the three profiles are independent from each other, thus a user
> only need to read the profiles s/he is interested in. One sentence
> should be mentioned that complexity notions are further explained in
> section 5.


> #1: EL is for “ontologies that contain very large numbers of
> properties and/or classes”. This description may not be very clear to
> a developer. Emphasis should also be on its relatively simple
> structure. It shall also provide information to distinguish from RDFS,
> which can also model “very large numbers of properties and/or
> classes”.
> #2: EL: the notion of “very large numbers” varies from community to
> community. To many, thousands of classes are “large”, while to some
> others it’s a small set.  I would prefer wording like “ontologies that
> mainly model class hierarchies and/or property hierarchies, plus
> limited class restrictions such as existential quantifications (i.e.,
> predication for the existence of a property value)”
> #3: The distinction between EL and RL is still not clear enough.
> QL: “applications that use very large volumes of instance data, … The
> expressive power of the profile is necessarily quite limited”
> RL: “…scalable reasoning without sacrificing too much expressive
> power, … trade the full expressivity of the language for efficiency”
> To a user, the difference looks quite subtle. Both are about
> scalability and limited expressivity.  It also gives the impression
> that QL is less expressive than RL. The description to RL is
> applicable to other two profiles as well.
> #4: In general, the presentation of the targeting applications of the
> three profiles should be improved to make their differences more
> explicit. Maybe a table with columns “main features, targeting
> applications” will help.

The introduction was already the subject of "extensive negotiation"  
with interested parties, and the common consensus was that the  
descriptions of the various profiles and their likely use cases  
should be kept brief and anodyne. I am very reluctant to reopen this  
can of worms. More detailed (user-oriented) explanations of the  
differences between the various profiles can be found in thePrimer. I  
added a few words and a pointer to the primer.

> ==EL==
> #5: ontology satisfiability => ontology consistency (to be consistent
> with Table 10)


> #6:  “captures the expressive power used by many large-scale
> ontologies and … can be decided in polynomial time.” – this is
> applicable to RL as well.

I reworded this to make it clear that we are talking about large  
terminological ontologies such as SNOMED.

> features that are at risk should be either marked out, or mentioned in
> the “Feature At Risk #1” box.


> ==QL==
> #7: the opening paragraph is mainly about complexity and the
> underpinning logic of QL. I believe this should be actually the 2nd
> paragraph, with the 1st paragraph explaining what QL is for with more
> details (e.g., accessing data via a relational query interface).

Already changed.

> #8: “this profile contains the intersection of RDFS and OWL 2.” What
> features are in RDFS but not in OWL 2? And is it OWL 2 DL or OWL 2
> Full?

Should say DL -- the missing features are the "Full" features.

> #9 (3.1): supported features: “assertions other than the equality
> assertions” should be “assertions other than individual equality
> assertions and negative property assertions”.


> not supported features: add “individual equality assertions and
> negative property assertions”.


> #10 (3.2.5): “OWL 2 QL disallows the use of functional, transitive,
> asymmetric, reflexive and irreflexive object properties” contradicts
> with the def of ObjectPropertyAxiom  below (which allows
> ReflexiveObjectProperty and AsymmetricObjectProperty)

Already fixed

> #11 (3.2.5): “OWL 2 QL disallows …  equality axioms”should be “OWL 2
> QL disallows …  individual equality axioms”


> ==RL==
> #12 (4): “return all and only the correct answers to certain kinds of
> query” –from the wording it’s hard to see what kinds of queries they
> are

You are right, but an explanation would be quite technical, and  
probably too much for the introduction. We provide forward refs, and  
I changed the first of these to be more specific (to Theorem PR1,  
which provides complete information).

> #13 (4.1) typo “ObjectDataValuesFrom” => “DataSomeValuesFrom”


> #14 (4.1) Superclass Expression: (ObjectMaxCardinality 1) should be
> “(ObjectMaxCardinality 1/0)”


> #15 (4.1) “Thus, OWL 2 RL supports all axioms of OWL 2 apart from…”,
> should be OWL 2 Full.

In all our documents OWL 2 is used in the most general sense (i.e.,  
not specifically any "species"/profile) -- see Overview for fuller  
explanation -- and this is what we mean here.

> #16 (4.1) the last paragraph: overlaps with the last paragraph of
> section 4 and should be merged.

I extended the paragraph at the end of section 4 and deleted this one.

> #17 (4.2.1): typo: “OWL 2 RL supports the the predefined classes” –  
> two “the”


> #18 (4.2.3): “superClassExpression production defines the classes that
> can occur as superclass expressions in SubClassOf axioms” – it can
> also appear in range/domain.


> #19 (4.2.3) typo: superDataMaxCardinality – shall remove the last “|”


> #20 (4.2.5) organization: to be consistent with EL and QL,
> ObjectPropertyAxiom  should move up to be after domain/range axioms.


> #21 (4.3) “first-order (material) implications” need explanation, esp.
> what is “material”.

I deleted "(material)" as it was superfluous.

> #22 (Table 4): rule eq-rep-p: owl:sameAs is defined as individual
> equality, but p and p’ here are properties

This is because in RDF the same IRI can be used as a subject,  
predicate or object. Therefore, owl:sameAs can be used to assert  
equality between two IRIs that are used in predicate position. This  
rule takes care of that.

> #23 (Table 8): shall we have another rule about DataIntesectionOf?

It is taken care of by the rules for intersection in table 6 (cls- 
int1 and cls-int2) which apply equally to classes and dataranges.

> #24 (Table 9): it looks strange to me that it seems some statements
> that can be inferred from the rules are illegal if they are explicitly
> added to an ontology. For example, scm-svf2 infers T(?c1,
> rdfs:subClassOf, ?c2); however,  SubClassOf (?c1, ?c2) is not a legal
> RL statement (since ?c2 is not a superClassExpression)

As a result of its derivation, ?c2 will always be a  

> #25 (Table 9): there are some more that can be inferred about
> cardinality restrictions, for example,
> If
> T(?c1, owl:maxCardinality, "n"^^xsd:nonNegativeInteger)
> T(?c1, owl:onProperty, ?p1)
> T(?c2, owl:maxCardinality, "n"^^xsd:nonNegativeInteger)
> T(?c2, owl:onProperty, ?p2)
> T(?p1, rdfs:subPropertyOf, ?p2)
> Then
> T(?c2 rdf:subClassOf ?c1)
> I’m not sure about the complexity consequence of adding those types of
> rules. If it still fall within P-TIME, we shall add them.

You are right in pointing out that Table 9 is not complete. It is  
still an open research issue to determine whether or not it could be  
made complete (for ontologies not satisfying the constraints  
specified in Theorem PR1). RL implementers within the WG, however,  
wanted to avoid extending Table 9 unless it was clear that the  
resulting inferences will be important in realistic applications.

> #26 (after Table 9): for self-containedness, may explain what are
> “axiomatic triples of RDF and RDFS”.

I added a few words.

> #27(Theorem PR1): the motivation of the theorem is not given. I don’t
> feel the theorem is needed by developers. It would be better to move
> it into the appendix. The proof sketch is also hard to understand, for
> example “axioms are of depth at most one” and “derivation tree” are
> not defined. I’m also not sure if the DLP rules and the rules in Table
> 3-8 have one-to-one and complete correspondence.

Actually, the Theorem is pretty important, as it defines under  
exactly which circumstances an implementation based on the given  
rules will be complete w.r.t. either semantics. This result is  
crucial to the definition of conformance for OWL RL reasoners. The  
proof sketch is just that -- only a sketch. It could have been  
omitted, but does provide some ideas, although admittedly only for  
experts. The *proof* could be moved to an appendix, but this seems a  
bit unnecessary.

> ==Computational Properties==
> #28: “PSPACE is the class of problems solvable by a nondeterministic
> algorithm” – should be “deterministic algorithm”, even though

Received on Tuesday, 7 April 2009 11:49:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:58 UTC