W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > September 2007

Re: One ontology schema - heterogeneous instance bases

From: Andrea Splendiani <andrea.splendiani@univ-rennes1.fr>
Date: Mon, 10 Sep 2007 12:57:53 +0200
Message-Id: <D6C85AE8-63DE-46BE-BD5E-D62AF83B7EF3@univ-rennes1.fr>
Cc: Nigam Shah <nigam@stanford.edu>, satya30@uga.edu, public-semweb-lifesci@w3.org, public-semweb-lifesci-request@w3.org
To: wangxiao@musc.edu
>> The problem is not about what is data and what is metadata.  The  
>> problem is that how you think will dictate how you design your  
>> artifact.  In the case of data standard, it subsequently  
>> determines how much inter-operable your ontology is with others.
>
> Let's use a concrete term as example, the biopax:AUTHORS.  (By the  
> way, it is very strange that bioPAX, use Capticalized term for  
> property and small-cased term for class, where the most conventions  
> is the other way around). Is its semantics any different from the  
> "creator" defined by the dublin core?  If there isn't any, (at  
> least from what I can tell), then bioPAX SHOULD NOT reinvent the  
> wheel to mint this term because, if every "ontology" developed its  
> own author term, then, there will be hundreds of "authors/creators"  
> etc., that we have to align when the so-called BioPAX data is mixed  
> with other kind of data.  And if you think it doesn't matter, why  
> bother developing ontologies, what is wrong with using XML schema  
> then?
I agree. biopax:AUTHOR is likely to be an artifact due to "historic  
reasons"... we may either assert an equivalence to a DC property or  
directly use them in a next version (I'm not an exper of DC, so this  
idea is tentative).
I mean, from errors come experience, no ?


> The reason, I guess, that "biopax:AUTHORS", is developed is because  
> the bioPAX people wants it to be a "format" rather making it a  
> knowledge.
No... just DC was not so widespread and known when biopax begun, I  
guess.

> To make it a format, you then think it in a closed world because  
> you want to "control" your own terminology.  Ontology is different,  
> its development is based on an open world semantics (at least RDF/ 
> OWL are).  When you developed your term, you should only care about  
> the consistency of your terms and not the completeness.  And don't  
> worry those terms that are not in your domain, for instance, I  
> don't think AUTHORS are pathway knowledge.  If you have to use it  
> for your application, then reuse other people's ontology. If there  
> isn't any, develop your own but at least put them under a different  
> namespace so you can later switch to others.....
Yes I agree and I agree that "format" and "ontology" should be "more  
distinct".
What I think is that we should have an "ontology of how a pathway is  
represented" and a definition of a "valid unit of information  
exchanged between two pathway systems". For the latter, you need some  
constraint that usually involves a closed world assumption. But this  
doens't mean you cannot base this on the URIs of the ontology (though  
the discussion here gets more articulated).
Authors are part of a pathway knowledge ?
Not of a "core" pathway knowledge, but they are pertinent as DC/ 
Annotation...


> If an ontology is developed to be a "format", it will fail and fail  
> miserably.
This sounds apocalyptic!

Nobody is saying BioPAX is ontologically clear... but let me explain  
where it stands now.

First, to understand the current biopax design, think about it in  
Object Oriented terms, not OWL. Think about classes and slots. OWL  
was largely used "as if it was" an OO specification.
This is wrong and odd, but again... from errors come experience. The  
thing is very well known and discussed within the community, and it's  
the reason for which last release took longer to be presented.

Currently there is some investment from information providers and  
consumers on tools to export/import data with the current specs. This  
is use of OWL to define BioPAX is continuing, but the aim is to  
address OWL compliance and integrate it with current ontologies (note  
that while DC terms were not included... uso of GO terms was) and  
properly define the role of ontology, format and so on.

By the way, you may note that a "pathway exchange" language with  
"pathway" beining something as metabolic/signalling/interaction...  
was clearly a underestimation of the task.

Some of these issues are discussed in the BioPAX wiki.

best,
Andrea



>
> Cheers,
>
> Xiaoshu
>

-----------
Andrea Splendiani
post-doc, bootstrep project (www.bootstrep.eu)

UPRES-EA 3888 - Laboratoire d'Informatique Médicale
CHU de Pontchaillou
2, rue Henri Le Guilloux
35033 Rennes - France
Tel : +33 2 99 28 92 45 / +33 2 99 28 42 15 (secr.)
Fax : +33 2 99 28 41 60

48° 07.275N
1° 41.643W
Received on Monday, 10 September 2007 10:58:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:49 GMT