- From: Andrea Splendiani <andrea.splendiani@univ-rennes1.fr>
- Date: Mon, 10 Sep 2007 12:57:53 +0200
- To: wangxiao@musc.edu
- Cc: Nigam Shah <nigam@stanford.edu>, satya30@uga.edu, public-semweb-lifesci@w3.org, public-semweb-lifesci-request@w3.org
- Message-Id: <D6C85AE8-63DE-46BE-BD5E-D62AF83B7EF3@univ-rennes1.fr>
>> 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 UTC