Meetings & Conferences Semantics and Ontologies Standards

3rd OBI Workshop: Day 3

Today was a highly informative combination of talks and further improvement of OBI. Hopefully, you'll find these musings on the day's work helpful at either jogging your own memory of the events, or in giving you an idea what went on in our heads.

Outside OBO
Ontologies – How do we integrate and/or make use of them?

  • Can we, at the moment or in future, place
    parent classes for all OBO ontologies in OBI? Definitely not now, as they don't share the same ULO (Upper Level Ontology). Some work is being done by the OBO-UBO group on mapping OBO ontologies to ULOs like BFO. (See the OBO-UBO web page for more information)

    • In a related question, should all OBO
      ontologies use BFO? It would make integration a much more straightforward process. In my opinion, this would be a great idea in the long term, however practicalities may prevent it. 🙂

  • Should things like
    BioTop ( be integrated
    into OBO, under BFO but before OBI? In my opinion (though today was the first time I have read about BioTop so it isn't the most informed one), in our case probably not, as resolving the three may be problematic. However, some terms or ideas might be useful to share.

Formal OWL, aka making OBI Formally correct

  • Should be assigned
    to someone/some people for later, after more classes have been
    created. There is simply too much flux in the file at the moment. Get the graphs in place first, perhaps working on some
    complex relations as you go. Further, the definitions must explicitly hold information
    on creating these relations, irrespective of whether or not you make the relationships as you go or at the end.

  • BFO and OBI use
    different metadata tags, and there should be a
    shared set of tags.

    • The metadata tags
      used in BFO are part of snap/span, I think. Would need to bring up the idea of metadata resolution (if possible, and we all agree it should be pursed) with that group too.

  • Barry Smith will bring OBI's information object and plan terms to the BFO group.

  • A milestone has been added (see the OBI Wiki) to
    hammer out exact implementation of the metadata list, and to work
    with other communities as appropriate (e.g. BFO, OBO Foundry =
    Barry, M Ashburner, Suzie, Chris M.).

Clinical Trial
Ontology – Simona Carini
& Barry Smith


  • Rctbank is a
    clinical trail db – information on all published clinical trials.
    (from journal articles)

  • Its purpose is to provide enough
    information to allow evaluation of these trials

  • RCT = randomized
    controlled trials

  • Epoch and Clinical
    Trial Ontology (CTO) are the other two that are being developed.

  • Barry Smith is involved in CTO, and therefore is built with OBI
    in mind, but is still very small

  • RCT and Epoch
    aren’t close to being OBO/OBI compliant.

    • Developed

    • Their choices are
      in conflict with the choices we’ve made

    • that does NOT mean that they aren't imminently useful (which they are), just that merging would be problematic
  • There has been
    agreement between Epoch and RCT that all should work towards a CTO
    that will work within the OBI framework

    • This necessary
      reconciliation is one of the goals of the CTO workshop in May.

  • There are people
    claiming to develop a CTO but it is actually a CT database
    ontology (I missed the name of the people being referred to here). It isn’t
    the same beast. Understanding the data is not equivalent to
    understanding the processes in a trial.

RCT Schema – Barry

  • Built
    independently of OWL or protégé, and is more correctly
    a database schema, though it is called an ontology.

  • Top-level class:

    • 2o study

    • Trial-details

    • Trial

    • Concept

      • Subclasses

  • Not the right way
    to do it – it is unbalanced: no place for a study, though is a
    place for a 2o study.

  • 2o study seems to
    be at the wrong level in the hierarchy

  • it is unclear what
    trial details means

  • When the same term (or portion of a term) is repeated
    over and over, it is often the a sign of a mistake, of redundancy

  • One of the
    children of population concept is population.

    • An ontology is
      important for reasoning using the is_a hierarchy, which can be reasoned
      over: Population is NOT a population concept and is NOT a concept

    • Reasoning is
      blocked here “from both directions”

    • Further, a recruitment
      flowchart is not a population concept

  • These things, like
    population concept, are headers/labels/conveniences, but they are not
    ontological forms. Some options for restructuring could be the following two things:

  • Population/protocol/design
    is_a continuant is_a entity

  • Trial is_a
    occurrent is_a entity

  • Not all RCT terms have

Epoch Ontology (Dave
Parrish in charge of it) – Barry Smith

  • There are parts of
    this ontology that don’t belong in the CTO, but do belong in OBI

  • Originally
    developed to support the immune tolerance network (ITN), a big
    clinical trial resource: they fund, implement, monitor and assess
    clinical trials, and provide data services.

    • Informatics dept
      of ITN perform operations (generation and collection) -> data
      management -> analysis

  • They have an
    ontology of the kind of analytical steps their software needs to
    perform, and it helps them configure the software application.

  • For example, elements are claimed to be
    nouns, and represent the physical objects of the system. Classes of
    elements are domain types, containers, relationships. These are not
    physical objects always – they’re sometimes processes. Also,
    they are not always nouns.

  • Fits in with the
    community milestones, i.e. we could get many terms from the clinical trials community.

Branches have been assigned. See the OBI Branches Wiki Page for up to date information.


  • Mapping between
    current terms in various OBO ontologies to BFO

    • E.g. GO
      biological process is_a span:process

  • Gramene has
    already developed an environmental ontology in a plant context,
    which we should remember and hopefully incorporate useful terms in the first round of community term dates.

More general

  • Have moved all terms
    that would fall under PATO out of the ontology, e.g. state and
    anything under quality.

  • Do we really need
    "in vitro state" as well as "in vitro"? Terms such as
    these are always tied to objects like cells – these are not design
    as much as the state of the cells.

    • Is in vivo
      a location or a state? You can take in vitro cells and put
      them into “vivo”, and they are still in vitro cells,
      which means in vitro is a BFO quality.

  • The interior of
    your gut is the site for your gut bacteria. The interior of gut (IG)
    is also a type/node in the FMA (as a location). IG has qualities
    (shape, etc). In addition to these qualities it has others that
    determine its roles (having certain pressure, pH value). How to
    distinguish what FMA means from what an environment ontology means?

  • If we remove
    in-vivo_state, we run into problems with multiple inheritance. We
    needed to separate out the state of a biomaterial from the
    biomaterial itself, i.e. don’t have in-vivo_material as a child of

  • What terms do we
    need to use to describe diseases?

    • Disease (hook for
      disease ontology), disease_symptoms, disease_stages,

  • Ended up going through the entire ontology, resolving many problems. There is a new OWL file, but it is not yet ready for public consumption therefore it won't be posted here until it is available from the official OBI pages.

There is general consensus among the workshop attendees that a very large amount of work is getting done, and there is a lot of positive feeling that the Milestones developed this week are giving us hard dates for inclusion of many more terms. The addition of terms can only truly start once the high-level structure has been decided, and this workshop has moved in great leaps and bounds towards a final structure of the higher levels of OBI. The "higher levels" have been generally defined at this meeting as the top two levels of OBI below BFO. This is what was completed today: the two levels directly below BFO have been studied by the group and cleaned.

Read and post comments |
Send to a friend


Meetings & Conferences Standards

OBI Workshop Day 2

At the moment I am trying out an alternative blogging site, and so you can see this post on that site.

Meetings & Conferences Standards

OBI Workshop Day 1

At the moment I am trying out an alternative blogging site, and so you can see this post on that site.

Meetings & Conferences Standards

FuGO Workshop Days 2-3

Ever since Monday (Day 1), there has been change afoot in the secret depths of the FuGO workshop. Not only were the discussions stimulating (as my previous post indicated), but there were ideas of redefinitions and term shuffling that grew, and then grew again during the evening of beer and revelry at the Red Lion Hinxton. Days 2 and 3 continued in this vein, and while I am being deliberately obtuse in order to tantalize the reader with our goings-ons, there was the smell of change in the air (and luckily, in this low-30s heat wave for Britain, that was all – our meeting room is one of the few in the entirety of the EBI where 15+ people can sit in air-conditioned comfort).

I think we are all starting to feel comfortable about where FuGO is headed, and while there was probably a little “analysis paralysis” (a term which Chris was the first, but not the last, to gently use at this meeting), the top-level decisions that need to be made at this stage do require serious discussion, and I believe the balance was about right. Everyone was contributing, and the daily (local to the workshop) update of the OWL file looked significantly different after yesterday’s changes. I shall wait to comment on any specifics until everything is up on the FuGO website, but I look forward with interest to the final day of discussion, and will probably have a sufficently tired brain that the talks on upcoming FuGO tools on Friday will be a balm.

Meetings & Conferences Standards

FuGO Workshop Day 1

Today was day 1 of my first (but in reality the 2nd) FuGO Workshop. It was full of interesting ontology ideas for the realm of functional genomics and beyond. There were talks concerning new ontological communities (GCP by Martin Senger, BIRNLex by Bill Bug, Immunology Database and Analysis Portal by Richard Scheuerman, and IEDB by Bjoern Peters) first thing, followed by a very interesting discussion on OBO Foundry Principles and developments in a phenotype ontology for model organisms and a unit/measurement ontology.

The most interesting points made this morning (to me!) were:

  1. Richard Scheuerman: the Immunology DB and Analysis Portal group has been thinking closely about data relationships – how much do you capture in the ontology and how much in the corresponding data model? Their current answer is to use only an is_a in ontologies, and to capture more specific stuff in the data model. (As I understood it, they would like to change this to make the ontology more complex at a later date). With their ontology, they emphasized modeling the data based on how the data was going to be used (don’t go into too much detail of the robots, for example). In choosing what data fields to require, they realize that experimentalists would only be happy to fill out forms that had perhaps a dozen data fields, therefore it is important to choose fields which anticipate how users will want to query the database.
    I really like this idea of requiring only those fields which would be of most use to the biologist, rather than those that would make us bioinformaticians most happy. Hopefully with time, the biologist would be happy to fill out more of a FuGE data structure.
  2. The MIcheck Foundry, which will create a “suite of self-consistent, clearly bounted, orthogonal, integrable checklist modules”. This is coming out in a paper (currently in press in Nature Biotech by CF Taylor et al.). It will contain MICheck – a “common resource for minimum information checklists” analogous to obo/ncbo bioportal (analogous to a shop window for displaying these checklists). There are many minimum information checklists out there, and the number will only grow, so it makes a lot of sense.

The afternoon was characterized by good-natured “discussion”. Here’s a summary of the mild-mannered (but – seriously – quite interesting) discussions:

  1. Argument against multiple inheritance (MI) in application ontologies, by Barry Smith.
    The root of the problem is that one shouldn’t combine two diff classifications, e.g. color and car type (if trying to have a red cadillac inherit from both red car and cadillac). Instead there should be a color ontology and car ontology. Many ontologies were originally built to support administrative classifications, but his opinion is that when you’re doing science, you’re interested in capturing the law-like structures in reality, not administrative information. Barry says every instance in reality can fall into many types of classes – the issue is how to build the ontologies: you can capture these instances by having either separate single inheritance (SI) ontologies, or one single “messy” MI ontology. Further, if you have MI, you might not have reuseability (ie why have colors just in car ontology, when they could be reused if they were separate?). In response, Robert Stevens suggested that you could have MI and let a machine deal with the differences – take car and color ontology and combine them mechanically through the relationships you put between them: people shouldn’t be scared of multiple inheritance, just use it carefully.
    The final conclusion was that normalization can upack MI into SI as long as it is a “good” MI ontology, and therefore this can be a reasonable way of ensuring your MI ontology is still a strong one – most errors are associated with misuse or overuse of MI. Another way to think of it would be to have a set of SI reference ontologies, but in your application ontology you would use MI. SI is very useful, as it supports all sorts of reasoning algorithms / statistical tools that MI does not allow. So MI ontology ONLY works if you can break it down into a set of SIs. Normalize a MI in order to use the checking mechanism, and only use a MI if it can be normalized.
  2. I learnt today about fiat types (no – not a car!), and how they relate to a putative measurement/unit ontology. A unit is a fiat universal/type in the dimension we use it to measure. In other words, measurements involve fiat units. A measurement ontology should be about storing units, and therefore do NOT want numbers. Numbers are part of the data, not the ontology.

…And that was only the first day! Wowsers…