Methodology > Workflow-Driven Ontology
Ontologies are developed for several purposes including the support for search, information integration and services discovery. At the same time, organizations developing ontologies are also using workflow techniques to support the computation of complex activities. Workflow-driven ontology (WDO) is an approach for ontology design. Typically, use cases are used to drive the design of ontologies. In the WDO approach, the elicitation and connection of concepts required to specify abstract workflow specifications are used to drive the design of ontologies. We claim that these abstract workflow specifications are indeed the use cases for WDOs. For instance, in the context of a WDO, if a concept is defined as a kind-of information, it must be either the input to or output of some concept defined as a kind-of method. In this case, both information and method are core concepts of WDOs.
The design of Ontologies using the WDO approach provides two benefits: First, the resulting ontology provides intentional support to workflow development; Second, the workflow specifications derived from the ontology can be used by domain experts to validate the ontology.
The WDO Specification
The notion of Workflow-Driven Ontologies (WDOs) stem from efforts to produce a domain-based ontology by a February 2004 Seismology Ontology workshop held at Scripps Institution of Oceanography in San Diego, California. The attendees of the workshop included experts in the areas of seismology and information technology. The result was a categorization and relationship model that supports workflow specifications. These categories drive the classes that are to be elicited from scientists in defining a workflow-driven ontology, and the relationships between the classes that form the foundation to produce workflow sequences that can be mapped to CI development efforts. The following figure shows the class hierarchy that forms the basis for a WDO.
As ontologies implemented in OWL, the class hierarchies of WDOs are subclasses of the most general OWL class Thing. To facilitate the production of workflow specifications from ontologies, the first requirement to create a WDO is to categorize classes into Information and Method. The Information class is further specialized into Data and Product. The justification for this distinction is that classes categorized as Data are considered first-class citizens in CI-related scientific activities while classes categorized as Product are considered artifacts that can be reproduced given a reliable data source. It is the authors' belief that this categorization of Information is applicable to other scientific fields employing CI and should be preserved as a general requirement for WDOs.
The Data class is further broken down into Raw Data and Processed Data. Raw Data is what is referred to as "measured" data or data that is in its natural form, i.e., data that has not been transformed through the application of some Method. On the other hand, classes categorized as Processed Data represent data that has undergone a transformation from an initial state through the application of some Method. This distinction is done in order to support basic rules for workflow construction, where we can identify when a workflow construction process should stop because it has reached the "base" class of information, i.e., Raw Data. The capture of provenance information would also benefit from this distinction by providing the scientist with the ability to annotate Raw Data with source metadata, e.g., sensor metadata, and to annotate Processed Data with method metadata, e.g., metadata about the method generating the data.
In addition, methods are categorized as Information Retrieval and Information Transformation. Functionality that retrieves data from a data source are called Information Retrieval methods; as part of the WDO approach, concepts classified as Raw Data would typically have a corresponding Information Retrieval method. Finally, Information Transformation methods correspond to functionality that takes information as input, processes the data, and outputs another type of information.
Model-Based Workflow Specifications (MBWs)
Model-Based Workflows (MBWs) are the resulting specifications obtained from a WDO to produce information desired by the scientist. They are referred to as MBWs because the specifications use the knowledge captured by an ontology, and as a result, the terminology is based on the target domain, not computer science terminology.
Eventually, MBWs will be transformed to executable workflows using OWL-S or MoML. OWL-S is a markup language that facilitates the automation of web services tasks, and MoML is the modeling markup language used by the Kepler Scientific Workflow Engine. In order to create an executable workflow, a mapping has to be established between the WDO classes involved in the workflow and the CI resources that carry out the actual work, e.g., web services. Our initial prototype assumes that this mapping is manually established by the user; however, mechanisms like OWL-S allow for more dynamic settings where the workflow engine can search through the CI to look for matching resources based on some semantic description.
The WDO Software
Copyright @2006 The University of Texas at El Paso