Re: Antwort: RE: Semantic web article in Nature Biotechnology

Hi Xiaoshu,
	I work on the BioPAX project for biological pathway representation and 
this discussion is very interesting.  We are currently facing a problem 
where we would like to import other commonly used bioinformatics 
ontologies as controlled vocabularies for use in the core BioPAX ontology.

The types of vocabularies I'm talking about are:
Gene ontology (OBO format)
PSI-MI controlled vocabularies (OBO format)
http://cvs.sourceforge.net/viewcvs.py/psidev/psi/mi/rel25/data/
BioCyc evidence code ontology (ocelot format - I assume)
http://bioinformatics.ai.sri.com/ptools/evidence-ontology.html
INOH moleular role and event ontology (OBO format)
http://www.inoh.org/download.html

(maybe others)

Because we use OWL and none of the above ontologies are available 
directly from the source in OWL, we are currently referencing external 
controlled vocabularies using a custom pointer class (as almost all 
bioinformatics systems currently do).  Our pointer is (badly) named 
"openControlledVocabulary" e.g.

     <FEATURE-TYPE>
       <openControlledVocabulary rdf:ID="openControlledVocabulary246">
         <TERM>phosphorylation site</TERM>
         <XREF>
           <unificationXref rdf:ID="unificationXref201">
             <DB>PSIMI</DB>
             <ID>MI:0170</ID>
           </unificationXref>
         </XREF>
       </openControlledVocabulary>
     </FEATURE-TYPE>

We have been toying with the idea of converting the external ontologies 
to OWL format and packaging them with our ontology, but that is 
obviously non-optimal because of maintenance issues.  Also, we're not 
sure exactly what the best way to do this is, though we've tried a few 
different ways - convert each term to a class, convert to instances of 
our openControlledVocabulary class, etc. A partial discussion of this is 
  here:
http://biopaxwiki.org/cgi-bin/moin.cgi/Alanr_Level_2_or_3_Proposal/Undesirability_of_openControlledVocabularies

One requirement is that we maintain the namespace (e.g. PSI-MI) and 
identifier (e.g. MI:0170) and not just rely on an RDF ID, so that we can 
connect to existing systems which rely on these IDs to e.g. make 
hyperlinks on a website that point to the definition of the term or 
which genes the term is used to annotate, etc.  This use will likely 
continue for many, many years.

We will be discussing this in depth at our next meeting in November and 
will likely have to come up with a solution in the near term, but maybe 
the above could be used as a realistic use case for this discussion.  We 
would certainly appreciate any constructive help we can get.

Thanks,
Gary

wangxiao wrote:
> - Robert Stevens,
> 
> 
>>My point of substance was about modularisation. I hope that 
>>someone will show me how to do it in OWL, after telling me 
>>what the behaviour of a module is.
> 
> 
> I have came up to this idea. Please see
> http://www.charlestoncore.org/ont/2005/08/o3.html , the ontology's namespace
> URI is http://www.charlestoncore.org/ontology/2005/08/o3#.
> 
> In short, a Profile is an ontology that only handles the merging of
> ontologies but do not create concepts under its own namespace.  All
> ontologies shall be deployed as a local ontology, i.e, ontologies without
> using foreign concepts. And complext ontologies, i.e., those import foreign
> concepts should be normalized into local ontologies and profile.  Such a
> separation will increase ontology reuse and system's robustness because all
> ontology is disjoint from each other.  In addition, it maximize overall
> system expressiveness.  Now, ontology creator shall try to develop ontology
> without thinking how it relates to others.  On the other hand, using
> o3:Profile allows all ontologies be combined according to a users' viewpoint
> or an application profile. The separation, IMHO, is very important.  And
> this is a concrete engineer principle that everyone can follow without
> subjective debate.
> 
> Of course, how to partition content (not the engineer artifacts) into local
> ontologies is subjective.  Detailed ontology needs a top ontology to help
> them.  For instance, if when MGED is designed with a top experimental
> ontology in mind (something like BOSS.
> http://www.charlestoncore.org/ontology/boss#), content decomposition will be
> easier.
> 
> If an ontology developer doesn't know what the system is supposed to run and
> what it can possibly achieve, how can they do things right.  To help them
> "comprehend" is much more important than let them simply "know".
> 
> Xiaoshu 
> 
>

Received on Wednesday, 12 October 2005 19:34:03 UTC