Re: REQDOC: New Draft

On February 27, Jeff Heflin writes:
> 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?

As I said in my reply to Guus, "asserted fact" might also be a possibility.

> 
> > 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.

It certainly needs to be clarified. I'm still not sure I believe your
interpretation - why should search only (or particularly) utilise
part-whole structures in preference to any other information in the
ontology?

> 
> > 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.

OK - new text is better.

> 
> > 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."

A definite improvement.

> > 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. 

In this case I think you should refer explicitly to individuals in
order to avoid tautology and/or possible confusion.

> 
> > 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.

It is a good example as far as it goes. My point about this kind of
example is that it doesn't really demonstrate the utility of having
meta-classes. The main purpose of the class-instance model of KR
seems to be to have instances inherit properties from the class that
they instantiate. What are the properties of Species are that are
inherited by Orangutan? 

> 
> > 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.

I can do it in one (very long) line. Seriously, the verbosity is an
RDF problem and not really a DAML+OIL problem - the DAML+OIL axiom
stating this fact is similar to the "rule" as written, with any extra
verbosity being accounted for by increased precision. (E.g., does
style="LateGeorgian" mean that there must be at-least or exactly one
style with a string datatype value "LateGeorgian", or no styles with a
datatype value that is not "LateGeorgian", or something else? And if
it means one of these things, then how do I express the others?).

Ian

> 
> > Regards, Ian
> 
> Thanks for your comments.
> 
> Jeff
>

Received on Thursday, 28 February 2002 09:57:38 UTC