[MOBY-dev] Service Ontology developments

Simon Twigger simont at mcw.edu
Mon Apr 19 15:25:36 UTC 2004


Hi there,

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

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

I went through Emboss and Pise and tried to use those tools to guide 
the types of classes we should have - I dont think they all will fit in 
what I have now but its a start. I looked at the MyGrid ontology and 
the reasoned version courtesy of Phil Lord and the power of being able 
to reason over the ontology is well worth considering and this was 
another reason I went with OWL (you can attach the Racer reasoning 
engine very easily). Their ontology is much more fully formed but that 
is the nature of DAML/OIL and OWL - you are trying to describe your 
'knowledge space' and the hierarchical ontologies we have in MOBY right 
now are a very simple structure in comparison (but on the flip side, 
they are useable now!). Now I understand things a little more, there is 
much in the MyGrid ontology that we might want to use/copy/refer to. Im 
not yet at the point of being able to say if we should adopt it 
wholesale, that is a much larger issue but we all want to avoid 
reinventing these wheels.

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

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

Structure of the ontology - I've be wresting with naming and how to 
partition services that obviously do more than one thing. Mark was 
going to check to see if a service could have more than one service 
ontology term attached to it, I think he said they could. Using OWL and 
reasoning would allow services to be described by their properties 
(input/output, what the service does, etc.) and the reasoning process 
would slot services into all the correct places that they belong, based 
on their properties - this would alleviate the problem of trying to fit 
a service into one service ontology category. [This would be more 
S-MOBY-esque, the RDF for the service could describe its properties and 
the discovery engine (moby-google, moogle?) could use those properties 
to slot it into the service ontology strucutre appropriately, no 
registration, etc required]

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

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

Cheers,

	Simon.



--

Simon N. Twigger, Ph.D.
Assistant Professor, Department of Physiology
Medical College of Wisconsin
8701 Watertown Plank Road,
Milwaukee, WI, USA
tel: 414-456-8802
fax: 414-456-6595
AIM/iChat: simontatmcw




More information about the MOBY-dev mailing list