Re: One ontology schema - heterogeneous instance bases

Il giorno 10/set/07, alle ore 13:48, Xiaoshu Wang ha scritto:
> Andrea Splendiani wrote:
>>> 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.
> Dublin Core starts at mid-90s. And bioPax at about 2002.  Even in  
> RDF there were dublin core vocabulary. That is not a good  
> guess, :-) Andrea.
Well, that's still my guess. For instance I came to know DC after  
biopax.

>>
>>> 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).
> You should focus on how a pathway is "described", not represented.   
> I don't think you understand the difference between open and close  
> world semantics yet. See later.
> So, please DO NOT think an ontology in OO.  (A slot is different  
> but I prefer to use the RDF term 'property' since we are talking  
> about RDF/OWL not frame. Again don't let's your ontology editor, in  
> this case it is Protege, dictate your thinking as well.)
I guess you are taking me wrong. As I said, all these issues are very  
well known. Indeed, the first time we tryed to use an OWL validator  
the difference between the CWA and OWA became quite evident. Just  
there was not a deep understanding of owl in the community in the  
beginning, and now there is some legacy we have to deal with (at the  
moment).

>> 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.
> Sure, you can tailor your term with a specified interpretation.   
> Just like MGED ontology, which just simply convert OO terms into  
> ontology term.  Isn't it odd that all MGED term has a superclass of  
> mged:Ontology? So, an mged:Experiment is also an mged:Ontology.   
> But their interpretation is this, a mged:Experiment is not an  
> experiment in the normal sense, it is the mged interpretation of  
> the experiment.  Well, with this "interpretation", it sure makes  
> sense to make an mged:Expreiment a mged:Ontology because what they  
> are modeled is not the real-word entity but an indirected  
> interpretation of a real world entity.  Of course, you can do  
> that.  But the problem is, how other people should use the mged  
> term?  How others should interprets the "interpretation" of a mged  
> term? And how two people's interpretation will be the same?
>
> Hence, if the development of bioPax follows the similar path to  
> create a "representation" of pathway knowledge, it falls to the  
> same trap.  It is my sincere wish that the group don't think it in  
> that way.
Don't worry. If you look carefully, you would even see that different  
versions of BioPAX are in different namespaces! We have a proposal  
for a consisent re-use of URIs.
Keep in mind that for many people these are secondary issues respect  
to the ability to import/export information in a common syntax, so we  
need a balance between "adding features" and "refactoring". Other  
than that, it's clear we would commit to shared representation of  
concepts (at least as far as they are well understood).
>
> But if  bioPax's objective to develop a "special representation" of  
> a pathway rather than a description of a pathway, I think  
> developing XML schema is much more appropriate for the task because  
> an XML document can be validated if a given document is correctly  
> represented or not.
That would have been a solution (I'm nut sure inheriance is supported  
by XML schema, though).
But BioPAX has an hybrid commitment, since it ideally address also  
the integration of heterogenous "pathway" information. This clearly  
implies an ontological commitment.

I agree that to exchange information per-se XML-schema would be more  
appropriate (we would still need an ontology for semantic  
integration). But now we have a legacy biopax + plans for next step.

best,
Andrea

P.S.: if you are interested in this, please continue the discussion  
on the biopax-dev mailing list!
>
> 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