Skip to end of metadata
Go to start of metadata

Here we keep track of the implementation plan for the IU-Lilly-UoM semantic provenance project

Here is a sketch of the relationships among the three main components: LSG (Lilly), Karma (IU), and S-OGSA (UoM) 

Lilly project goals:

  • add value to LSG by integrating functionality from Karma [provenance] and S-OGSA [storing and retrieving various types of annotations].

To meet this goal, the plan includes two parts:

  1. perform architectural integration between LSG, Karma, and S-OGSA
  2. demonstrate its value on Lilly-defined use cases.

Background on Lilly's LSG.

Background on Karma 

At the end of the 4-08 kick-off meeting it seems clear that we have a good plan for (1) but we still don't have any use cases from Lilly (2). The  Lilly presentation focused more on installation and third-party development of LSG components than on their use... their will be hopefully more chances to go over use cases with them at a later time.
LSG and Karma will be  tightly coupled through an event bus. Karma has its own reqs regarding instrumentation of the underlying workflow / session manager that it is to monitor.
This will involve some degree of .NET programming using c#. No java anywhere. Lilly is a Microsoft shop.
The good news for us is that UoM should not be concerned with any of this.

Scenario and implementation goals for (1):

  • The goal is to enrich system-level provenance data collected by karma using semantic annotations of the LSG plugins (WS). Yogesh is interested in a new Karma component that can consume these rich service annotations.
  • Two types of annotations:
    • structural: use an ontology that reflects the interface-op-method-parameter structure of WS definition
    • functional: use formal annotations of the WS functionality.
  • this requires to "invent" a new ontology for the structural annotations. This will reflect the ER Karma model [IU].
  • use myGrid annotations for functional annotations. Use S-OGSA effectively as a semantic registry for services, accommodating both types of annotations.
  • Both types of annotations to be contributed initially manually (a "service curator"), and possibly using some annotation tool later. What we need is a good way to add these annotations as Semantic Bindings to S-OGSA.
  • Running example: LSG plugin to access NCBI services. The NCBI LSG plugin is provided by Lilly as part of their distribution.
  • Annotations to be done using SAWSDL style.

Short-term plan:

  • Develop a small structural ontology to describe structural relationships among elements of a WS WSDL interface: operations -> methods -> parameters. [IU]
  • Provide functional annotations for NCBI services [UoM] --> ask Franck / Katy: can we reuse their curated annotations?? what form do they take?
  • Add both types of annotations to S-OGSA [UoM]. In this case the Grid Entities are LSG plugin unique identifiers, the KEs are the ontologies used in the annotations.
    • This becomes an annotation graph that conforms to the structural ontology defined earlier.
    • I expect to be should be able to reuse our existing test S-OGSA clients that we used to populate S-OGSA for the Ontogrid final demo
  • Karma must be able to query S-OGSA to retrieve SBs using the LSG plugin identity as keys.
    • Provide IU with the WSDL interface to S-OGSA [UoM]
    • Requires a new component that can exploit the structural ontology to sensibly navigate the service annotation graph [IU / UoM]
  • Karma will then do "something sensible" with the annotations [IU]
    • Strictly speaking we are just providing support for the S-OGSA service, however this is where it gets research-interesting: how to combine system-level provenance with semantic annotations from the services.

Short-term requirements on S-OGSA:

  1. Store semantic bindings that annotate elements of a WS definition (WSDL). This involves taking SAWSDL annotations extracting them and creating Semantic Bindings from them.
  2. Develop a "snapshot" component that retrieves all service annotations, for use by Karma. This requires knowledge of the ontology, so the component needs to know that it can retrieve annotations from operations to methods to their parameters... this navigational ability relies on the service description ontology.
  3. provide a GT-free implementation.
    • I expect to use the existing tomcat-based version of S-OGSA
  4. provide support for robust (scalable etc.) back-end RDF store.

mid-term plan for S-OGSA:

  1. support for annotation versioning -- not just lifetime/state management as it is now, but rather,  support for snapshots of different version [UoM]


  • Ian for the first month, 50%
  • Paolo 50% (of his current 50%...)
  • Any other development resource that we can use to relieve Ian?? 
  • None