Would you agree that I may summarise your approach as
· Extract Terms (from existing ontologies, applications schema, taxonomies and corpus, domain experts)
· Define Terms
· Identify Concepts
· Classify Terms & Concepts (As-Is relationships) – Generalization relationships
· Attribute Concepts with Facts (Assign Properties)
· Express domain Policies / Business Rules / Constraints /Domain Logic using associative relationships
· Agree output of each process stage with domain experts
Date: Thu, 4 Nov 2010 14:08:30 +0000
To: pradeeps@xxxxxxxxxx; ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Need suggestions developing cardiac disease/phenotype ontology
Here's how I tend to look at creating an ontology. Assuming the ontology is intended as a conceptual model of the reality itself, and is not constrained by any specific application requirement (i.e. it's a model of the problem and not the solution), I would proceed as follows:
1. Have a strict taxonomic hierarchy in which something sits below something else if it is a "kind" of that thing, that is it inherits all the facts defined for that thing above, and its parents and so on;
2. If there are multiple ways of classifying things in the problem domain, consider honoring all that are relevant (for example, a whale is both a Mammal and a MarineAnimal). However, you may wish to consider that while reality and therefore ontology support multiple inheritance, most of the applications that use this information will not. Having multiple taxonomies will enable you to develop (and map against) different applications which classify the diseases in different ways. So you should be able to achieve a taxonomy for any application that you need to deal with.
3. At the top of your hierarchy have what sort of "Thing" everything is, that is "DiseasePhenotype" I would imagine. If there is a separate way of classifying the diseases (genotype?) then put a separate top level term, with an even more general term above that (e.g. Disease).
4. Finally the facts (properties). For every new kind of thing (every disease) ask yourself two questions:
- what sort of thing is it? (this determines where it goes in the taxonomy e.g. is it a neurone related or muscle related condition);
- what facts distinguish it from other things in that part of the taxonomy?
This latter gives you the necessary facts that define that that thing is what it is.
There may be other, incidental facts. In financial securities we have lots of facts that always apply to a given kind of security so it's not always obvious which one is a necessary, defining fact. For example exchange traded options are distinguished by the fact that they are traded on an exchange, and also by the fact that they have specific, standardized legal terms. So don't worry too much about distinguishing necessary from incidental facts since the main semantics notations don't have a means to put that in anyway. Just make sure you have captured the necessary facts that give a thing its meaning.
If no facts distinguish something from something else, you have a synonym (at least at the level of detail you have considered appropriate for this particular ontology). Rather than have separate classes for each word or disease name that exists, you should consider having one class for each meaning, and then identify synonymous words in a separate "synonym" tag. Unfortunately there isn't a synonym tag in OWL (people seem happy to have a class per word and use equivalence relations, which is unnecessary and I would suggest counter productive). So either use RDFS Label or find some way of identifying particular RDFS Labels as "synonym". Here you might also want to have separate synonym tags with a language marker, so you have all your Latin terms.
Ultimately the questions of what amount of relationships / facts to put in, is a judgement call based on what level of detail of terms you need in any applications you will develop from this ontology, or what level of detail exists in databases, data feeds and applications that you wish to relate to with this ontology, for example if you are using it for integration of disparate systems or to create a common messaging language.
What I found is that once you get an initial draft in place and present this to the business subject matter experts to review (I hope you will be doing this, since it's their knowledge), they will tend to let you know about additional facts and levels of detail that are relevant to a given application or to their view of the business domain. For example when we looked at legal entities, we had 4 terms for kinds of relationships among entities, but the business experts identified up to 4 possible shades of meaning for each of these, that they considered relevant, for instance for different levels of control and different kinds of control that one legal entity has over another.
So once you have got your ontology into the hands of the business domain experts they will pretty much fine tune the level of detail for you. The key is making sure that it is structured, and can be presented and explained, in simple set theory logic with the necessary defining facts in place.
Hope this helps,
On 04/11/2010 13:38, Pradeep Kumar S wrote:
I hope this is the right place to request for some help I need developing a cardiac disease/phenotype ontology.
I have been curating list of phenotype/disease terms from biomedical literatures for past 1year.
Now the collection has grown to about ~1200 terms. I have the following attributes curated along with the terms:
1. Term name
2. Source ( web, reference of book or paper)
3. Some times definition and the context in which it was curated.
I request experts here to suggest me how to proceed further from list of terms to making a good ontology?
Specifically I need to know:
1. how many relationships should I consider initially. Putting terms under hierarchy like a taxonomy will be the easiest. But how to incorporate other plausible relationships. When (how many) would it get very complex?
2. Basically I want to render a ontology that could be used by data mining tools and serve biological community in their data analysis.
Any suggestions from experts here will be highly appreciated. Also please point me to any websites/literature/books that would be of help.
89 Worship Street
London EC2A 2BF
Tel: +44 (0) 20 7917 9522
Mob: +44 (0) 7721 420 730
Registered in England and Wales No. 2461068
_________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx Shared Files: http://ontolog.cim3.net/file/ Community Wiki: http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx