[MOBY-dev] [moby] Re: registering INB services in Canada

[Mark Wilkinson]

Hi Oswaldo, 

I think the most important thing is to thank you for your team's
willingness to contribute to the code-base and the public registry and
ontologies.  It is greatly appreciated, as are all of the INB
contributions!

I have no doubt at all that your registry works far better than the
public one because it has been hand-curated and carefully controlled
from the outset.  I think that, for academic interest, the chaos of the
public registry and ontologies has been interesting to observe, since
one of the major research questions of my laboratory is "can a useful
ontology arise through a completely open and non-curated process"[1].
Economically we adopted a non-curated approach because our original
development budget was barely enough to get the project off the ground
at all.  And finally philosophically the public registry has a "laissez
faire" attitude towards what we allow people to register in it, because
we specifically avoid telling people what data-types, service types,
etc. they should use in order to be as open as possible to all
participants.  

Nevertheless, as you correctly point out, and a variety of us have noted
several times on the discussion list, this makes the public registry an
uncomfortably "wild" place to do any real work!  The various projects
who have set-up independent registries have all handled this in
different ways.  The PlaNet project registered data-types in their local
registry as well as in the public one on an ongoing basis in order to
keep their ontologies as synchronized as possible with the public ones;
the GCP project created a "branch" of the public ontology (the GCP_*
Objects) containing several structurally identical or semantically
similar objects to those in other parts of the public ontology, but in a
hierarchy that was specifically meaningful and useful to them; and the
INB created it's own ontologies  entirely from scratch.  Of these
approaches, only the PlaNet approach retained true interoperability with
those outside of their own project.  This is not a criticism of any
approach, it is simply an observation that the concept of "ontology
sharing" is critical to the functionality of MOBY (the question of
whether the shared public ontology is "good" or "not good" is an
entirely different story...)

The issue of how to re-integrate two forked copies of the ontology is,
therefore, a very complex one, since none of our software is currently
prepared to deal with this problem in any automated way, and automated
ontology-alignment is still largely wishful thinking anyway [2].  It is
undesirable for the INB to have to re-code their services since this is
extra work, and it is similarly undesirable (in fact, more or less
impossible) for us to ask the other public services to re-write their
code to adapt to the INB objects, even if they are "better".

Short-term, I honestly don't see a straightforward solution to the
problem for every case.  Obviously the objects that can be registered in
the public ontology without naming clashes can be registered there
whenever you wish.  However, for those that have identical names...??  I
guess the first step would be to check if the objects in the public
registry are being used at all.  If they are not, then you are welcome
to de-register them as per the API.  Second, you could check if the
services that use that object are functional.  At the moment, about 15%
of the services in the public registry are non-functional [3].  If a
service is non-functional, you could contact the provider and ask if
they are still maintaining the service at all, and if not, ask them to
de-register the service such that you can de-register the objects that
it uses.  Finally, if there were only one or two services that use the
object you wish to remove, you could ask them if they would be willing
to change their service to adopt your new object.  They may say no, of
course, but... you could ask :-)

Longer-term, we might be able to solve this problem at the level of XML
namespaces (i.e. identify which of the two ontologies the object came
from based on its XML namespace); however as I said, none of the code
currently can handle this situation, so it isn't a solution in the
short-term, and moreover I would much prefer to see the project move
toward an RDF-based data representation system versus continuing to
develop code for and refine the existing custom-MOBY-XML standard.  If
we plan to support multiple ontologies in the future, I think it would
make more sense to do so under one of the W3C ontology standards versus
invest more resources in making the current MOBY "standard" do what
these other standards can already do (to some limited extent...)

So... I honestly don't have a suggestion that solves all of the problems
without requiring someone to do some re-coding of their services.  I
guess this is what I said in my original response, but it seems to have
caused some offense, so I hope this more verbose response is less
controversial.

Regardless, any contribution your team is willing to make is always
welcome and appreciated, 

Best wishes, 

Mark

[1] http://helix-web.stanford.edu/psb06/good.pdf
[2] http://www.atl.lmco.com/projects/ontology/
[3] http://mobycentral.icapture.ubc.ca:8090/authority/ValidateService?
getDeadServices





On Wed, 2006-12-13 at 19:45 +0100, Oswaldo Trelles wrote: 
> I'd like to provide some additional information to help understanding 
> our perspective.
> 
> 1) When we were developing the INB system we realise on the need for 
> ensuring availability and service inter-connection based on the moby 
> ontology. However, several mails from the moby community warned us on 
> the importance of a curate catalogue. (i.e.) "Right now in the registry 
> if I send a generic object I get over a hundred services back, almost 
> none of which will actually consume the object without dying a horrible 
> death." (Gordon, Feb 17th), or this other more explicit, "MOBY Central 
> has become increasingly useless over the past couple of years as it got 
> filled with junk, badly registered services, dead services, "localhost" 
> services, test services, and all manner of other registration artifacts 
> (M.W. response)"
> 
> 2) In this sense we made a great effort in the registering procedure. We 
> hold several internal meetings with some invited experts from the moby 
> community to introduce, comment, discuss and get feedback about our 
> strategy. So, it is not a new issue.
> 3) Natalias’s email correctly states the real-problem of different 
> catalogues. In several previous emails the equivalent issues of 
> federated ontologies, disperse catalogues, etc. were at least 
> enumerated. So, it is opportune to launch the discussion.
> 4) My group at the GNV5-INB University of Malaga- is open to contribute 
> in the discussion of the technical and procedural aspects involved in 
> this issue, oriented to propose a global solution.
> 5) In our opinion, Natalia’s email is not the problem but part of the 
> solution (our system works properly…at the moment at least !)
> 
> with regards,
> 
> O.
> 
> PS, I’d like to thanks all mobiers that having nothing constructive to 
> say have avoided reply with unfortunate emails.
> 
> and finally I suspect that the Phillip Lord phrase regards **good** 
> ontologies.
> 
> 
> 
> Mark Wilkinson escribió:
> > The immortal words of Phillip Lord are ringing in my head right now... "An  
> > ontology is not an ontology unless it is SHARED!" :-)
> >
> > This is a topic that has been discussed (perhaps not on-list?) for many  
> > years - going all the way back to the first group (PlaNet) who set up  
> > their own registry.  If you "fork" the ontology, then everything breaks,  
> > unfortunately.  I don't think we have ever found a workable solution to  
> > this situation.  Next-generation MOBY, with RDF/OWL and reasoning and  
> > such, may be able to deal with this problem, but MOBY-S is pretty much  
> > stuck with one, centralized ontology (which, in our defence, is how the  
> > vast majority of ontologies work at this point in Web history).
> >
> > I'm just catching up with my emails after being away for 10 days.  I don't  
> > see anyone else responding to this so far.  I don't have any suggestions  
> > to help you at the moment, but I can raise it at my next lab meeting and  
> > perhaps an idea will come up...??  I have a feeling that there isn't a  
> > "magic" solution.  MOBY works *because* we all agree on the ontology.  If  
> > you don't agree on the ontology, then you aren't interoperable... it's  
> > pretty much the core principle of the project...
> >
> > M
> >
> >
> >
> >
> > On Thu, 07 Dec 2006 03:04:47 -0800, Natalia Jimenez Lozano  
> > <natalia.jimenez at pcm.uam.es> wrote:
> >
> >   
> >> Hi,
> >>
> >> I would like to open a discussion about ontologies. I belong to the INB
> >> where we have currently a lot of working services. We would like to
> >> register all of our services in Canada but due to the differences
> >> between both ontologies (Canada and Spain), we could ran into the
> >> following problems:
> >>
> >> a) Identical objects (objects that share the same name and the same
> >> hierarchy): in this case there would be no problem using the object
> >> previously registered in Canada.
> >>
> >> b) Analogous objects (objects that share the same name but different
> >> hierarchy): it would be possible to register in Canada the object with
> >> the same name but different hierarchy? If it would be possible we would
> >> be "breaking" the Canadian ontology :-(
> >>
> >> Some examples of this situation can be easily found:
> >>
> >>     b.1. NCBI_BLAST_Text: in Spanish ontology, this object is a son of
> >> text_formatted node but in Canadian ontology is a son of BLAST-Report
> >> that is at the same time a son of Sequence_alignment_report.
> >>     b.2. There is a lot of common objects like Clustalw_Evaluated_Text,
> >> FASTA, GFF ..., etc which only difference is their depencency: in
> >> Canadian ontology, these objects are depending on text-formatted node
> >> but in the Spanish ontology on text_formatted (the only difference is
> >> hyphen/underscore!).
> >>
> >> c) Similar objects (different name -similar, upper-case/lower case,
> >> underscore/hyphen- and/or different hierarchy but same meaning): to fit
> >> to this last situation, we have several options:
> >>
> >>     - To register INB objects -> this would not "break" the Canadian
> >> ontology but would "blur" it.
> >>     - To adjust each one of the INB services to the Canadian ontology ->
> >> This would mean the modification of the code of each one of the services
> >> and it would require an extra work.
> >>     - To modify INB ontology to adjust to Canadian ontology -> This
> >> would be a thorny issue because since INB beginnings we have work very
> >> hard in this sense. Even we organized an ontology committee to give
> >> advise on each new object to be registered. Moreover, few months ago we
> >> restructured our ontology with the aim of removing inconsistencies. In
> >> my opinion, we have currently a very solid ontology.
> >>
> >> Suggestions about how to register INB services in a easily and not
> >> damaging way?
> >> Thank you very much in advance,
> >> Regards,
> >> Natalia
> >>
> >>
> >> _______________________________________________
> >> MOBY-dev mailing list
> >> MOBY-dev at lists.open-bio.org
> >> http://lists.open-bio.org/mailman/listinfo/moby-dev
> >>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev