Hi Pradeep, |
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
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
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
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
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
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
I request experts here to suggest me how to proceed further
from list of terms to making a good ontology?
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?
I want to render a ontology that could be used by data mining
tools and serve biological community in their data analysis.
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/
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 (01)