Feta: Semantic Service Discovery Framework of myGrid

In addition to the Scavenging Functionality built into Taverna, services can be discovered by exploiting their semantic descriptions. Feta is the component within myGrid responsible for semantic service search. Feta is composed of two sub-components, namely Feta Client-Side and Feta Engine.

Feta Client

Feta Client is the name of a group of UI-based components that are plug-ins to Taverna. These components and their functionality are:

• Service Mark-Up with Pedro: Pedro is an XML data entry tool that allows incorporation of ontology terms into generated XML instances. Within myGrid Pedro is used to generate XML based semantic service descriptions that contain service mark-up information that refers to the myGrid service ontology. Pedro is an external component developed within the Pedro project. The chief-developer of it is Kevin Garwood. The version of Pedro that we use within myGrid is a slightly hacked version of Pedro 1.7.
• Query Design and Result Display with Feta Client GUI: This simplistic GUI allows creation domain specific semantic service search queries to be sent to the Feta Engine. Once queries are built by the user via the UI, the client connects to a configured instance of the Feta Engine web service and forwards the service search query to it for evaluation. This GUI also displays of information about the resulting services for the queries and allows integration of the resulting services in to the workflow via Drag and Drop.

Feta Engine

Feta Engine is a web-service based component responsible for:

• Converting and Loading Pedro Descriptions and the myGrid ontology into an RDF model in order to provide service search over this model with RDFS inferencing on.
• Accepting 1) a set of pre-defined search requests and 2) free-form RDQL queries and returns the results for these queries.

Feta architecture

The overall architecture and interaction of component is given in the following figure.

For interested readers, details of how Feta works can be found here Feta.pdf

Semantic Service Discovery Roadmap

I have prioritized the requirements wrt when we need them, from 1 to 5. Meanings: 1 --> urgent, 5 --> can be ready by the end-of 2 years.

• Custom Annotator A custom myGrid Service Annotatotion UI is needed. The service mark-up that this component generates should be in RDF, as it is the metadata representation language of the project. (Priority - 1)

• Custom Service Search UI the existing search UI is rather minimal and not nice looking. This is mainly to my poor ability (or inability) to code UI components. (Priority - 1)

• A Registry Browser Currently we only provide a list view of the services in the registry or those that match our query. Given that we have 3000 services and hopefully all will be annotated by an expert curator we need (possibly an ontology driven) browser over the registry, that would provide categorized views of services (e.g. phylogenetics services, proteomics services etc., or for example services that do certains tasks e.g. alignment plotting etc. )(Priority - 2)

• A Change Management Strategy and Supporting tools Currently we have no change-management mechanism. Whenever a change is made to the ontology, this has the potential to effect existing service descriptions. Tools that 1) detect which descriptions are effected and 2) semi-automatically perform (if possible) update of these stale descriptions is necessary. (Priority - 3)

• A Persistent and Secure Registry Currently Feta Engine has no security, (neither AuthZ nor AuthN) and operates over an in-memory RDF model. All of these issues can be solved with a moderate amount of coding. That said, there is the GRIMOIRES registry from OMII, which does all these things and will be integrated with Taverna. WRT some experiments we have done with the GRIMOIRES people, GRIMOIRES can accommodate Feta Service descriptions by the help of some adaptor code. The results of these integration experiments are here GRIMOIRES-Experiments.txt. (Priority-2)
  • Note that FETA annotates WSs but also all other widgets invokable from Taverna. Thus we can only register the annotated WSs, leaving the problem of where we register the rest.
  • GRIMOIRES uses RDF but you cannot register domain specific ontologies like the FETA ontology - thus we cannot query GRIMOIRES using the FETA ontology
  • There already exists an adaptor allowing to store FETA annotated WSs into GRIMOIRES (see GRIMOIRES-Experiments.txt); the adaptor is one-way: you cannot read back into FETA

• Sustaining Ties with BioMOBY BioMOBY and myGrid has very similar service description models. In August 2005 we had a registry hackaton with them in order to analyze both models in detail. The outcome of this work was that we can come up with a canonical model as bith projects model a service as an operation that has inputs and outputs and with further metadata assertions on these aspects. In the following months after the hackaton we have developed a canonical RDFS model. The next release of Feta Engine will be operating over this model. The details of how Feta Engine acts as a service regsitry for BioMoby is in this document IntegrationStatus.pdf. We would very much like to keep this BioMoby link active. They have a more involving/active community when it comes to semantic service search. (Priority-1)

• *A detailed status report on the current Semantic Registry and some ideas for future development are given here Semantic-Registry-Planning.ppt.

Any questions/comments on Feta should be forwarded to Pinar Alper (penpecip@cs.man.ac.uk).

• views_on_view.pdf: An experience report on GRIMOIRES and motivatios for FETA

• BIoinformatics-registry-requirements.pdf: a list of requirements for a registry from the biology/bioinformatics domain