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

One thing we have to remember is that biologists are building ontologies to 
do a job of work. they are not produced as some end of CS or SW research. 
the annotation of biological data with terms from the gene ontology, for 
instance, has done much for computational analysis of data -- and it is not 
using sW technology.

We can't just expect people, whose priorities are not those of the SW, to 
simply use this technology because we say it is good. It is up to us to 
demonstrate its utility. Such demonstration should be done in collaboration 
with biologists -- only in this way can we ensure sensbile biology is done 
and SW technologies are used appropriately. RDF and OWL are not easy 
technologies and we ask a great deal of people when we expect strict 
esemantics to be used in a complex domain.

A few pointers to things and events in SW and bio:
* A paper at November's ISWC by K Wolstencroft et al on the use of OWL 
ontologies and reasoners etc to classify proteins
* the OWL experiences and directions workshop following ISWC will have some 
contributions from biologists
* there is a  track at this year's PSB on "semantic webs for life 
sciences"  http://psb.stanford.edu/ and this will feature BioDash: 
http://www.w3.org/2005/04/swls/BioDash/Demo/
* A special issue of the Journal of Web Semantics  on life sciences -- 
deadline 15 Nov.
* bioPAX, as mentioned by Phil, is well workth a look -- www.biopax.org and 
several contributing databases have data in RDF (and the Uniprot data in 
RDF has been much featured on this list)

Again, as Phil mentions, the OBO format is essentially compatible  with OWL 
semantics and  converters are available. there is, for instance, a Protege 
plugin and we have one under development here in Manchester. One of the 
rules of OBO is that their ontologies should be orthogonal. If they are 
not, then perhaps this is a sign that such a goal is difficult and that we 
should use our tools and techniques to resolve the problem. Finally, if we 
want nice modular, SW technology ontologies then perhaps we should produce 
usable tools and techniques for delivering them. Modularisationof OWL 
ontologies is still a hot topic. I note in your latest email "because I am 
still chewing on some problems." -- so it is not a surprise bio people are 
not doing it as a priority for their work?

I think the point of imports and modularisattion etc. are  mtherhood and 
apple pie, but until the technologies and methodologies (how do I fragment 
my ontology appropriatly for any possible re-use?) are in place and 
yield  tangible benefits for ontology developers then it will not be done. 
What bene fit do I, as an ontology developer, get from spending a lot of 
precious development time making my ontology re-usable. Obbiously  I know 
the answers, but we need to make it cheap for people to do such nice 
engineering solutions.

Robert.


Robert.





At 03:19 30/09/2005, wangxiao wrote:

>Sorry, I was out of town for a few days.  Just came back and very glad to
>see my "request" can trigger so many response.  I didn't even know there are
>many people actually pay attention to this list.  Hope we can keep this up.
>So, here will be my responses.
>
> > The namespace in GO is a URI not a URL. Should there be any
> > expectation that it does anything other than 404?
>
>Yes, the RDF/OWL file should be accessed from the ontologies' namespace.
>RDF's namespace differs from XML's.  The latter only promises a unique
>string (that is why XML has schemaLocation tag but not in RDF) but the
>former promise a set of axioms.
>
> > There have been many considerations of practicality made. Monolithic
> > development is a problem, but both OBO and the MGED ontologies have
> > been attemping to ensure consistency between ontologies as well as
> > minimise overlap.
>
>Consistency is only the nesessary condition for an ontology but not
>sufficient to make the ontology reusable. For instance, if I want to borrow
>the "experiment" concept from MGED, I must import all other classes and
>properties.  It is a tramandous waste.  Besides, what if I don't subscribe
>to the view of the rest concepts?  Ontology should be build orthogonal to
>each other. It needs to be carefully pacakaged by the use of namespace. I am
>currently writing something about it but may take a while to finish it
>because I am still chewing on some problems.
>
> > We routinely reason over ontologies much larger than the wine
> > ontology.
>
>You can doesn't means you should.  The "wine ontology" issue is just a
>figure of speech. What I want to imply is we need carefully designed
>ontology to minimize unintended "imports".
>
> > Semantic web technology much scale to the size of the "encyclopedic"
> > ontologies; otherwise, what use is it?
>
>But in a distributed but not monolithic manner, don't you agree?
>
> > The boss ontology looks, at a quick glance, fairly similar to the
> > parts of the provenance ontology from mygrid, or perhaps the
> > experiment ontology by Larisa Soldatova and Ross King, or even the
> > work on Hybrow. MGED also has an experimental ontology somewhere
> > within it, or, at least, I think that this is the case.
>
>The "parts" is the key.  I put BOSS up in such a trivial manner is for a
>reason.  I can simple put up a hiearchy as the subClass of boss:Study,
>boss:Data, etc.  We should, when designing ontology, give users a certain
>degree of control on the granuality.  For instance, if I only do data
>analysis, why I care about the boss:Protocol? If I don't need it, why I
>bother to import it?
>
>Though I do have some thoughts, I don't think I have all the answers.  I
>hope from this, you can see why I post that request.