[MOBY-dev] Re: Service Ontology developments

[Phillip Lord]

>>>>> "Simon" == Simon Twigger <simont at mcw.edu> writes:

  Simon> Hi there,

  Simon> Following the MOBY meeting a few weeks back, I've started to
  Simon> sketch out a service ontology structure as a basis for
  Simon> discussions - Im sure it will get kicked around and reworked
  Simon> but thats the goal. I've committed some things to the
  Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/


  Simon> Given the S-MOBY direction of going to OWL and needing a
  Simon> decent editor and some practice with these things, I've been
  Simon> putting this together using Protege in OWL format. If we need
  Simon> to convert to something else, thats fine but its a reasonable
  Simon> place to start and Protege is a nice tool with the OWL plugin
  Simon> and the OWLviz graph add-on. If you open up the .pprj file in
  Simon> Protege you will be able to read the service descriptions,
  Simon> etc. which will help understand what I thought they all did.


The OWLViz plug-in was written by people, here, at Manchester. So if
you start using it please give me a shout; they would welcome the
feedback. 


  Simon> I went through Emboss and Pise and tried to use those tools
  Simon> to guide the types of classes we should have - 

If you have not already, then its worth having a look at the EMBOSS
ACD type system. 


  Simon> I dont think they all will fit in what I have now but its a
  Simon> start. I looked at the MyGrid ontology and the reasoned
  Simon> version courtesy of Phil Lord and the power of being able to
  Simon> reason over the ontology is well worth considering and this
  Simon> was another reason I went with OWL (you can attach the Racer
  Simon> reasoning engine very easily). 


<partisan>
Or, of course, the wonderful FaCT reasoner. 

http://www.cs.man.ac.uk/~horrocks/FaCT/
</partisan>


Hopefully there should be a new version of fact out soon, which does
some things quite a bit quicker. 




  Simon> Their ontology is much more fully formed but that is the
  Simon> nature of DAML/OIL and OWL - you are trying to describe your
  Simon> 'knowledge space' and the hierarchical ontologies we have in
  Simon> MOBY right now are a very simple structure in comparison (but
  Simon> on the flip side, they are useable now!). Now I understand
  Simon> things a little more, there is much in the MyGrid ontology
  Simon> that we might want to use/copy/refer to. Im not yet at the
  Simon> point of being able to say if we should adopt it wholesale,
  Simon> that is a much larger issue but we all want to avoid
  Simon> reinventing these wheels.


My own feeling, which may surprise you, is that you should not adopt
the ontology wholescale. Currently, I think the ontology is too big,
and somewhat confusing to use. Within an end user tool, you would need
to document all the concepts. And there are quite a few of them. 

Within mygrid our intention would not be to present the entire
ontology to the end user, but chunks of it. It's not really possible
to make this split in moby-s as it stands; at least not to my
knowledge. 


  Simon> Key things for us to look at as I see it, bearing in mind
  Simon> I've only been looking at this for a few weeks:


  Simon> Development path - do we want to have some simple,
  Simon> incremental additions to our current Service Ontology so we
  Simon> can better classify services for MOBY-S or are we looking to
  Simon> make a quantum leap towards a more comprehensive ontology in
  Simon> OWL that is leading towards S-MOBY in the future, or more
  Simon> likely, both of these options?

If you want to go for OWL, in a way which enables you to reason, then
you would need to think a fair bit about the ontology API which is not
really up to it yet. It would also mean that you would have to tackle
events like the ontology becoming inconsistent. 




  Simon> Structure of the ontology - I've be wresting with naming and
  Simon> how to partition services that obviously do more than one
  Simon> thing. Mark was going to check to see if a service could have
  Simon> more than one service ontology term attached to it, I think
  Simon> he said they could. Using OWL and reasoning would allow
  Simon> services to be described by their properties (input/output,
  Simon> what the service does, etc.) and the reasoning process would
  Simon> slot services into all the correct places that they belong,
  Simon> based on their properties - this would alleviate the problem
  Simon> of trying to fit a service into one service ontology
  Simon> category.


As it stands I think you could do this without reasoning. Essentially
what you are asking for here is a multiple inheritance tree, I
think. Where OWL gets very powerful is if your properties are
complex, have constraints on them, or there are lots of them.  


  Simon> [This would be more S-MOBY-esque, the RDF for the service
  Simon> could describe its properties and the discovery engine
  Simon> (moby-google, moogle?) could use those properties to slot it
  Simon> into the service ontology strucutre appropriately, no
  Simon> registration, etc required]


  Simon> I divided into bioApplicationService and
  Simon> infrastructureService as children of the parent ServiceClass
  Simon> node to try and separate bioinformatics services from other
  Simon> types of service that arent really bioinformatics but are
  Simon> essential to the system - service registration, etc. What are
  Simon> other's thoughts on this? I noticed I left Resolution in the
  Simon> wrong branch.


  Simon> At this point, have a look at what I have and give me your
  Simon> input and I'll go from there. I will also try and assemble a
  Simon> bibliography of all the papers I've been reading on OWL,
  Simon> etc., they would be useful for understanding S-MOBY too I
  Simon> suspect.


I will try and comment on what you have in the next few days. 

Cheers

Phil