Re: REQDOC: New Draft

Ian,

Please see my responses below...

(Note, apparently these comments concern the older draft of the
document. This may be my fault, because my message about the new version
along with the new URL only made it out about an hour before this
message was sent. Note that the current document is at:
http://km.aifb.uni-karlsruhe.de/owl/index.html)

Ian Horrocks wrote:
> 
> Here are some comments on the revised text.
> 
> 0. The term "definition" is often used to refer to statements in an
> ontology, e.g., in 3.1 "to provide additional definitions", in
> 5.Commitment to ontologies "which set of definitions", 5. Class
> definition primitives, etc. Are we suggesting that all statements in
> an ontology are "definitions". What about statements of the form
> sameClassAs C1 C2, where neither C1 nor C2 is a class name? I think
> that each use of "definition" should be examined and, in most cases,
> changed to something more neutral such as "axiom" or "statement".

I can understand your objection to word "definition." I think
"statement" would be too vague. "Axiom" is a possibility, but I fear
that there might be a number of readers who don't have the background in
logic to understand what we mean here. Can someone suggest a better
term?

> 1. The second bullet point at the end of section 2.2 says "The search
> should be able to utilize part structure of objects to return better
> search results". I don't understand what this means. Does "part
> structure of" refer to partonomies (i.e., part-whole relations used to
> specify the physical structure of objects)? Or does it mean "part of
> the structure of". Assuming the latter, I would suggest changing the
> wording to:
> 
> [[The search should be able to utilize (part of) the structure of
> objects to return better search results]]

I believe, that "part-whole" relations is what is intended. The new
version of the document says "utilize the part structure." We will
consider clarifying this.

> 2. In 3.2, justification, it says "Both compatible and incompatible
> revisions should be allowed, but it should be possible to distinguish
> between the two.". It isn't clear if compatibility is to be computed
> (e.g., by comparing ontologies) or asserted (e.g., by the author of
> the revision). I don't know if it is possible/worthwhile to clarify
> this point.

I think in most real-world cases, semantic backward compatibility cannot
be computed, because it depends on the intended interpretations of the
terms. The last sentences "... the ontology author needs to be able to
indicate such changes explicitly." argues for the "asserted" case.

> 3.In 3.5, justification, it says "There are over one billion pages on
> the Web, and the potential application of the Semantic Web to embedded
> devices and agents poses even larger amounts of information that must
> be handled. The web ontology language must support systems that can
> scale to these sizes." There is no differentiation here between
> ontologies and data/markup/annotations using terms from
> ontologies. Surely no one is suggesting that size of ontologies will
> be of the order of billions of pages? Moreover, the ontology language
> itself provides no mechanism for adding annotations - we are relying
> on RDF (or some similar mechanism) for that. What applications will do
> with semantic markup is as yet rather unclear (to me at least), and
> may vary widely between different applications.
> 
> One thing that is clear is that it will not be possible to perform
> reasoning across the entire web w.r.t. the full semantics of any
> language that even remotely resembles DAML+OIL or comes anywhere close
> to satisfying the requirements set out in this document, and it
> doesn't seem to make much sense to state that as a requirement (or
> even a goal).
> 
> How about changing the paragraph to say something like:
> 
> [[There are over one billion pages on the Web, and the potential
> application of the Semantic Web to embedded devices and agents poses
> even larger amounts of information that must be handled. The
> ontologies needed to describe this information can be expected to be
> both large and complex. The web ontology language must therefore
> support very large ontologies, but it should also be as expressive as
> possible, so that users can state the kinds of knowledge that is
> important to their applications.]]

The thing about the Semantic Web that I find most exciting is the
possibility of combining information from multiple, distributed,
seemingly unrelated resources in order to produce new knowledge or
answer difficult questions. This would require reasoning across large
portions of the Web. Although, we cannot have a complete DAML+OIL
reasoner that can accomplish this, we may be able to design various
incomplete reasoners that could perform the task satisfactorly. In any
case, I consider this to be an important goal (but not a requirement!).
However, perhaps I should change
the wording from "The web ontology language must support systems that
can scale to these sizes" to "The web ontology language SHOULD support
reasoning systems that scale well."

> 4. Section 4, "Class and property equivalence". I would delete
> "definitions" from the text - it is meaningless w.r.t. the kind of
> language we are considering. The text should just say
> [[The language must include features for stating that two classes or
> properties are equivalent.]]

Okay. Change accepted.

> 5. Section 4, "Identifier equivalence". This is really just an
> extension of the previous point, which could be changed, e.g., to say:
> 
> [[Class, property and individual equivalence: The language must
> include features for stating that two classes, properties or
> individuals (objects) are equivalent.]]

Although I see your point, I think there is some value to keeping them
separate. 

> 6. Section 4, "Ability to state closed worlds". I think that this is
> still much too vague to be included as a requirement and should be
> changed to being an objective (as Frank says, "there is clearly work
> to be done here").

In the current document, it already is an objective. Frank's new wording
is available on the mailing list, and assuming no one objects to it,
will be added after the telecon.

> 7. Section 4, "Classes as instances". Ditto for this requirement. It
> is very vague as stated. Although there may be some cases where it is
> useful to have classes of classes, convincing examples are
> surprisingly few (many of the supposed examples I have seen have been
> ill conceived, and/or are of little benefit in terms of the knowledge
> captured in the ontology). The cost of such a requirement may also be
> very high in terms of the computational complexity of the resulting
> language. Again, I would suggest that this be made an objective rather
> than a requirement.

The current version of the document has an example to help explain it.
Please see if this helps.

> 8. Section 5, "Chained properties". The text here needs
> revision. Composition is better than chaining (it is the standard
> term), and the sentence about "linking the range of one property to
> the domain of another property" is unclear/incorrect. Also, the
> statement about the use of variables may not be correct - it is
> certainly not clear given the vague specification of what variables
> means. I would suggest changing the text to:
> 
> [[The language may support the composition of properties in statements
> about classes and properties. An example of the use of property
> composition would be the assertion that a property called uncleOf is
> the same (has the same extension) as the composition of the fatherOf
> and brotherOf properties.]]

This change sounds okay to me. If no one has an objection, I'll add this
to our change list.

> 9. Section 5, "Variables". This is so vague as to be meaningless in
> its current form. I'm not sure how to fix it. I would suggest simply
> removing it for now.

Removing a requirement or an objective is a major change, and would
require group consensus before I would do it. Unless this is a
show-stopper, I suggest tabling the change.

> 10. Section 5, "View mechanism". This is more or less incomprehensible
> to me, so what chance is there for readers outside the WG. It needs
> significant clarification or deletion.

Same response as issue 9 above.

> 11. Section 5, "Arithmetic primitives" and "String manipulation". I'm
> not sure that these are reasonable objectives w.r.t. the language
> itself (although they would clearly be useful in an integration
> tool). Even if they are to be retained, it might make more sense to
> state the requirement in terms on n-ary datatype predicates.

I think to the greatest extent possible, ontologies should provide
axioms that allow terms to be related to terms in other ontologies.
That is, the axioms used by an integration tool should be shareable.
One way to do this is to publish "integration ontologies." Note that
this is an objective, and not a requirement, because I see this as
something that would be good for the Semantic Web, but I don't expect
us to get to with the first versino of the language.

> 12. Section 5, "Aggregation and grouping". I would suggest that this
> should be part of the query language (as in SQL) and not of the
> ontology language itself.

For similar reasons as the one above, I see this as useful for
establishing links between different ontologies. For example, a
corporate level ontology might have a numEmployees relations, while a
Human Resources ontology might have a employee relation. Integrating
these two ontologies would requre the ability to specify that
numEmployees is the count of the employee relation.

> 13. Section 5, "Definitional constraints on conjunctive types". It
> seems strange to have this as an objective as it is just a special
> case of the requirement for being able to state class
> equivalence/subsumption relationships.

This particular example was originally raised by Guus Schreiber in his
"art-image collection" use case. His point was although it could be
expressed in DAML+OIL, it required 24 lines and an unintuitve structure.
I think the point is it would be nice to have a simple way to express
this knowledge.

> Regards, Ian

Thanks for your comments.

Jeff

Received on Wednesday, 27 February 2002 13:56:16 UTC