HCLS/OntologyTaskForce/OntologyAccess

Ontology Access and Use

Standards for accessing and retrieiving ontological information may need to be identified. There are efforts in the healthcare informatics community to define web service standards for accessing and manipulating terminological concepts. The suitability of this standard for requirements of the HCLS areas could be examined and extensions could be proposed.

 Comments?

Ontology-based inference functionality that checks for ontology consistency and subsumption knowledge

 Comments?
Comment: It is imperative to examine instance data when checking for ontology consistency. Ontologies are built to enable us to represent instances, and therefore the ease and accuracy with which instances are represented is an important factor in checking an ontology. I have done some work in this area. http://www.biomedcentral.com/1471-2105/7/196/abstract

I agree, and I'd like to add a related point. It's a fundamental decision for an ontologist to decide what is an instance in his/her ontology. For example, in a layperson's anatomy ontology, instances might be examples of heads, necks, and torsos. Whereas, in an anatomy ontology created by pathologists, the "leaf nodes" (=instances) might be cells. In one created by molecular biologists, the instances might be protein molecules, and if a biologically-minded physicist ever created an anatomy ontology, the instances might be subatomic particles!!

In other words, instances in an ontology are just the things that the ontology author decides are the smallest (i.e., nondecomposable) entities that he/she is interested in representing.

And here's the key point: this decision is highly use-case dependent. So what's an instance for me, might not be for you. This can create bigtime problems. We talked about whether "diseases" are instances or classes. Is "the disease influenza" an instance? Well, yes if you're writing an ontology of diseases. But no, if you're representing cases of influenza like e.g. "John's influenza", "Vipul's influenza", etc.; in that case it's a class.

Well, first I dont agree that "leaf nodes" (=instances). Confusing leaf nodes with instances is a cause for a large amount of problems. Leaf nodes are just the finest classes in a particular ontology. If this was religiously followed then in the biologically minded physicist's anatomy ontology, the leaf node would be a sub-atomic particle and the lay person can have "head" as the leaf node and there would be no problem. Again, for diseases, "the disease influenza" is a class even if I am writing an ontology of diseases. And a case of influenza, such as "Vipul's influenza" is an instance. Tomorrow if I start having further subtypes of influenza there is no problem because "the disease influenza" is a class and so I can have a subclass "the disease influenza type 1" without causing any problem for the instance "Vipul's influenza".

I'm not sure we completely disagree, but I'll grant that my choice of "leaf nodes" was inauspicious and subject to misinterpretation.

Let me be more explicit. Instances are to classes as (nondecomposable) elements are to sets. There are certainly classes that have only a single instance, just as there are sets that have only a single element. But just as for sets there is a big difference between a [=element a] and {a} [=the set composed of the element a], so also in ontologies there is a big difference between a singleton class and an instance. When you create a set-based formal language, one of the first things you do is indicate the symbols that represent the domain (the nondecomposable elements) of the language. Likewise in creating an ontology, one should give careful thought to the domain of the ontology -- what are the nondecomposable instances that it aims to represent.

I also think you're underestimating the semantic difference between conceiving of "influenza" as

   (a) the class of all cases of influenza (i.e. influenza infections occuring in people)
        versus
   (b) the "disease" influenza (e.g. the abstract idea of the disease influenza, or perhaps "influenza" as the subject of a monograph, or indeed perhaps as an instance in an ontology of diseases that does not also have people in its domain at all and so is quite unable to represent cases of influenza).

I also disagree that a case of influenza like "Vipul's influenza" is invariably an instance (if you were implying that--maybe you weren't). Suppose I want to create an ontology called "Vipul's health history ontology". I might create a class of "Vipul's influenza" and it might include all possible instances of Vipul having influenza. So in that case "Vipul's influenza" would be a class. On the other hand, maybe I want to go the other direction and represent the stages of influenza as manifest in Vipul. Then "Vipul's influenza" could be comprised of a number of instances: "Vipul's influenza(date:2004, stage:early"), "Vipul's influenza(date:2004, stage:late").

My point is that there is no obvious or natural choice for what kind of entity constitutes the instances in an ontology. It's purely a choice made by the ontology author. And different choices end up having a big influence on interoperability. If two ontologies have partially disjoint domains, then they cannot be merged in the current iteration of OWL, for one thing.

Okay, I see you point. Here is how you can always think of influenza as a class and still do everything you describe. The class "Vipul's influenza" is a short hand for a relationship between a person (Vipul) standing in relationship of having a disease (influenza). Ideally, your class influenza would already have properties for describing who got it, when, what stage, how long did it last etc. So to represent "Vipul's influenza" you dont create a new class. You create an instance of a relationship (getting a disease) that exists between the instance Vipul and the class influenza (We, just stepped out of OWL-DL I think).

This is very similar to what Alan Rector is proposing in "Modularizing" OWL ontologies in http://www.cs.man.ac.uk/~rector/papers/rector-modularisation-kcap-2003-distrib.pdf

Nigam, I think you're absolutely right to make the point that this discussion area is related closely to the distinction between OWL-DL and OWL-Full. As I see it, OWL-Full, by letting you treat classes as instances, allows you in some sense to defer the decision about what your (nondecomposable) instances are. You could just keep creating classes forever and never create non-class instances. And I can definitely see the appeal of doing this--it is a very flexible approach--but you have put your finger on the price to be paid in terms of computability.

That Alan Rector paper is a wonderful reference, thank you! I had no idea he had discussed this.

HCLS Home

OTF Home

Discussions

Post to HCLS listserv

Minutes

Links