Personal tools
You are here: Home Wiki ModelingApproach
 
Views

Edit history

Edit: -1 of 1
Time: 2005-10-18 14:57:51
Note: /cellml/portal_migration/upgrade

changed:
-
This section discusses our approach to ontology modeling.

Modeling approach
=================

Some of this was previously entered under classes vs instances

The anatomy ontology at the moment is a slightly confusing mixture of
classes and instances.  I think to clear this up we need to draw some
clear lines about what the classes are representing and what the
instances are representing.

The classes we create and the properties defined on them form a meta
model for the instances.  The definition of classes and properties is
a meta-meta model.  Therefore, the classes we define should hold
information about the properties we need to fill out and the
associations between instances that can be made.  In our case, we
should not be using these classes to define actual biological types,
in the end, they just end up being classes with the same kinds of
properties but different labels.  If we were building a *defined
ontology* using say OWL, then we could define some biological types
that are defined on the basis of their property restrictions.  But we
are not doing this.  A very good example of that kind of ontology is
the TAMBIS_ ontology(for the ontology in OWL form see
TAMBISOWLONTOLOGY_).  Our ontology instead should just define the top
level classes that it does, like `Anatomical Type
<http://n2.bioeng5.bioeng.auckland.ac.nz/ontology/anatomy/ontology_class_view?class_uri=http%3A//physiome.bioeng.auckland.ac.nz/anatomy/all%23Anatomical%20Type>`__
and not hierarchies of actual biological forms like `Blood vessel
<http://n2.bioeng5.bioeng.auckland.ac.nz/ontology/anatomy/ontology_class_view?class_uri=http%3A//physiome.bioeng.auckland.ac.nz/anatomy/all%23Blood%20Vessel>`__.

The proposal would be to add some properties to AnatomicalType, or
specialize AnatomicalType to provide properties such as part_of, or
types such as anatomical_compartment.

Another value we get from using instances to hold all our content
rather than a mixture of classes and instances is so we can operate
better across other ontologies and databases.  If we bind too much
information up in our Class descriptions, then we may be making these
inaccessible to other modeling environments.  If instead we bundle all
the useful property values into an instance, then we can at least port
those frames into other database forms, or test whether they conform
to alternative models.


`This
<http://lists.w3.org/Archives/Public/public-swbp-wg/2004JanMar/0119.html>`__
message is an interesting point in a thread the use of OWL classes as
instances.  In this case, the person wanted to use an OWL class as the
subject of 'dc:Subject' from the dublin core specification.  Watch for
the split in the thread, so make sure you follow `this
<http://lists.w3.org/Archives/Public/public-swbp-wg/2004JanMar/0124.html>`__
part too.

.. _TAMBIS: http://imgproj.cs.man.ac.uk/tambis/

.. _TAMBISOWLONTOLOGY: http://protege.stanford.edu/plugins/owl/owl-library/tambis-full.owl