% by Mirella M. Moro; version: September/03/2010 @ 6:04pm 
% -- 09/03/2010: bib file with names for proceedings and journals; cls with shrinked {received}
% -- 08/27/2010: appendix, table example, more explanation within comments, editors' data

\documentclass[jidm,a4paper]{jidm} % NOTE: JIDM is published on A4 paper
\usepackage{graphicx,url}  % for using figures and url format
\usepackage[T1]{fontenc}   % avoids warnings such as "LaTeX Font Warning: Font shape 'OMS/cmtt/m/n' undefined"

%\usepackage{cite} % NOTE: do **not** include this package because it conflicts with jidm.bst


% Standard definitions
\newtheorem{theorem}{Theorem}[section]
\newtheorem{conjecture}[theorem]{Conjecture}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{lemma}[theorem]{Lemma}
\newdef{definition}[theorem]{Definition}
\newdef{remark}[theorem]{Remark}
\newenvironment{latexcode}
{\vspace{0.1in}\setlength{\parindent}{18pt}}
{\vspace{0.1in}}


% ALL FIELDS DOWN TO BEGIN{document} ARE MANDATORY

% The following data (volume, number and page) are given by the editors prior to publishing your paper
\jidmVolume{3}
\jidmNumber{1}
\jidmYear{12}
\jidmMonth{February}
\setcounter{page}{43}


% Includes headers with simplified name of the authors and paper title
\markboth{D. de Oliveira et al.}
{JIDM - Journal of Information and Data Management}
%  -> \markboth{}{}
%         takes 2 arguments
%         ex: \markboth{M. M. Moro}{Any paper title}


% Title of the paper
\title{Ontology-based Semi-automatic Workflow Composition
}


% List of authors
%IF THERE ARE TWO or more institutions, please use:
%\author{Name of Author1\inst{1}, Name of Author2\inst{2}, Name of Author3\inst{2}}
\author{Daniel de Oliveira\inst{1}, Eduardo Ogasawara\inst{1,2}, Fernanda Bai\~{a}o\inst{3}, Marta Mattoso\inst{1}
}


%Affiliation and email
\institute{Universidade Federal do Rio de Janeiro (UFRJ), Brazil 
\and Federal Center of Technological Education (CEFET/RJ), Brazil 
\and Federal University of the State of Rio de Janeiro (UNIRIO), Brazil \\ \email{\{danielc, ogasawara, marta\}@cos.ufrj.br, }\email{fernanda.baiao@uniriotec.br}
% IF THERE IS ANOTHER INSTITUTION:
%\and Name_of_the_second_institution \\
%\email{address@whatever.com}
}


% Paper abstract - it should be from 100 to 300 words
\begin{abstract} Scientific workflows are being used as an abstraction for the composition of large scale scientific experiments. As scientific workflows become more complex it is important to provide for more abstractions to isolate them from infrastructure issues and let them focus on their domain of expertise. Although using abstract workflows  is a first step, there are many open issues, such as the ones related to semantics. Adding semantics to abstract workflows enables the explicit representation of which activities can be linked to each other, or which activities are equivalent to each other. However, representing an abstract workflow with semantics is an open problem. Existing approaches address either the representation of abstract workflows or the use of domain ontologies to add semantics to activities, but not both. In the latter case, these approaches focus only on adding semantics to executable workflows, instead of working in different abstract levels. This makes it difficult to group workflows into a common abstract representation in the conceptual level. Common abstract workflow representation allows for a better understanding of the experiment by scientists and enables the association of the experiment definition with domain knowledge. This paper proposes coupling workflow ontologies to abstract workflow representations. This is a step forward to semantic mechanisms, to help scientists to identify equivalent activities, group executable activities into one abstract activity with the same semantics, and verify the compatibility between activities. We implemented and evaluated the proposed approach by coupling SciFlow - a workflow ontology - with GExpLine - an abstract workflow design tool. Experiments show how these abstraction levels improve workflow composition.
\end{abstract}


% ACM Computing Classification System categories
\category{H. Information Systems}{H.3. Information storage and retrieval}{Databases}
% Categories and Descriptors are available at the 1998 ACM Computing Classification System
% http://www.acm.org/about/class/1998/
%  -> \category{}{}{}
%         takes 3 arguments for the Computing Reviews Classification Scheme.
%         ex: \category{D.3.3}{Programming Languages}{Language Constructs and Features}
%                   [data types and structures]
%                   the last argument, in square brackets, is optional.

% Paper keywords
\keywords{Ontologies, Scientific Experiments, Scientific Workflows, Semantics}
%  -> \keywords{} (in alphabetical order \keywords{document processing, sequences,
%                      string searching, subsequences, substrings})


% THE PAPER BEGINS
\begin{document}

% This is optional:
\begin{bottomstuff}
% similar to \thanks
% for authors' addresses; research/grant statements
\end{bottomstuff}

\maketitle


% PAPER NEW SECTION
\section{INTRODUCTION}

In the last decade, the effective use of scientific workflows to model large scale scientific experiments became a reality. A scientific experiment is characterized by the composition and execution of several variations of workflows \cite{Mattoso2009}. These variations include changing input data, parameters, programs, or even a combination of all previous changes. This turns the management of a scientific workflow into a very complex task, especially in large scale scientific projects. Workflows are usually managed by Scientific Workflows Management Systems (SWfMS), which enable the specification and execution of a chain of executable activities represented by programs or services, and are responsible for enacting, controlling and monitoring the workflow execution. There are innumerous SWfMS \cite{Taylor2007}, but they focus on managing the execution of a workflow in an isolated way, disregarding the relationship between executions of workflows variations.

When scientists model their experiments using scientific workflows, one important problem they should worry about is the composition process. Composing a scientific workflow is not a simple task. During composition, scientists structure and define the entire experiment, establish the logical sequence of activities, plan variations that have to be explored, and define the types of input and output data for each activity. There are not many approaches for workflow composition \cite{Mattoso2009}; currently, composition considers workflows in a low (and fixed) level of abstraction. This means that scientists are required to compose their workflows directly in the SWfMS specification language, and to design their workflows in terms of programs or services, which poses several limitations to scientists and may prevent them from planning and controlling alternatives. Composition tasks, however, should ideally be carried out before defining a concrete workflow,{\em  i.e.}, a workflow specified using SWfMS language. Some initiatives to workflow composition encompass the representation of workflows in hierarchical abstract levels. This facilitates workflow composition, but this abstract representation is still an open, yet important, issue \cite{Shoshani2009} \cite{Ludasher2009} \cite{Gil2007}. Current limitations include:

\begin{itemize}
\item The tacit knowledge of which activities can be linked to each other; 
\item Lack of a standard vocabulary used in the abstract representation (which may be very difficult to achieve with distributed and heterogeneous teams of scientists); 
\item Lack of representation of which activities are equivalent to each other; and 
\item Lack of representation of dependencies between activities.
\end{itemize}

These problems can be addressed by adding semantics to the composition process, through the use of ontologies. Some existing approaches propose to add semantics to workflows by associating domain ontologies to the specification, but they associate ontologies to concrete workflows \cite{Wolstencroft2007}. This enables ontology navigating from an activity of a concrete workflow, but it does not help in grouping workflows that share the same algorithm or method, for example, since abstract concepts, such as algorithm or method, are not associated to abstract workflow activity representations. Therefore, workflow metadata is needed to represent the abstract workflow and to help workflow resource finding according to these constructs (activities, algorithms, methods) in higher levels of abstraction. According to \cite{Gomes-Perez2004}, task and domain ontologies are complementary when applied to a specific application or scenario. Domain ontologies model a specific domain, or part of the world. It represents the particular meanings of terms as they apply to that domain. On the other hand, a task ontology describes the vocabulary related to a generic task, independent of its domain of application. Workflow composition in a specific scientific domain ({\em e.g.}, Bioinformatics or Oil exploitation) requires the ontology to include both domain-specific terminology and workflow composition concepts, thus providing a more complete semantics for scientists. Associating the ontology with abstract representations provides the following benefits: 

\begin{itemize}
\item Controlled vocabulary that formalizes domain terminology, which is also coupled to abstract representation of activities; 
\item A checking mechanism to verify program and service compatibilities prior to execution time; 
\item Formalization of knowledge related to which activities can be linked to each other;
\item Verification of equivalence between activities (if they perform the same conceptual role in the experiment);
\item Verification of dependency between activities.
\end{itemize}

This article proposes an approach to associate ontologies to abstract workflow representation. We propose the use of SciFlow ontology \cite{Oliveira2009} to improve abstract workflows composition before using a SWfMS. SciFlow is a task ontology for workflow composition that may be associated to domain ontologies to provide semantic facilities on scientific workflows. It relates the components of the workflow with domain terminology, associating roles in different levels of abstraction. These levels go down until the level of a SWfMS language workflow. SciFlow was incorporated into GExpline \cite{Oliveira2010}. GExpline is an abstract workflow composition tool that guides scientists in composing the abstract workflow and maps to the chosen concrete SWfMS for workflow execution. By using SciFlow in GExpline in a real scenario we observed the five previously mentioned benefits of coupling workflow ontologies to abstract representations. 
This article is organized as follows. Section 2 presents SciFlow. Section 3 explains the advantages and benefits of coupling ontologies to abstract representation of scientific experiments. Section 4 presents the effective use of ontologies with an abstract representation and discusses the coupling of SciFlow to GExpline. Section 5 discusses the existing semantic support for scientific workflows. Finally, in section 6, we conclude this article and point to future work.

%%

\section{SCIFLOW: A SCIENTIFIC WORKFLOW ONTOLOGY}


This section presents SciFlow \cite{Oliveira2009}, an ontology for scientific workflow composition. SciFlow represents a generic model that includes the main concepts and axioms related to scientific workflows. Scientists may specialize SciFlow ontology and the domain concepts in order to represent the specific scientific experiment being addressed. By the time the ontology is specialized, it may be referred to by all subsequent scientific workflow composition tasks of that domain. SciFlow models the template ontology in two levels: a super class level and a domain specific level. 

The first level has classes that represent general concepts used throughout the scientific domains, while the domain specific level is composed by classes that should be specialized by scientists (or ontology engineers) for each different scientific domain. Scientists need to specialize the super classes with domain terminology, without concerning about scientific workflow concepts already modeled. SciFlow was implemented in OWL using Prot\'{e}g\'{e}. Based on scientific workflow definitions, some concepts are extracted and modeled as super classes in SciFlow. SciFlow extends the DAMON ontology \cite{Cannataro2005} taking into account the scientific workflows requirements, such as input and output data and chaining of tasks. Its key concepts are: 

\begin{itemize}
\item Step: it represents a macro activity of the workflow, and models its highest abstraction level; 
\item Task: it is a specialization of Step and defines a specific problem that is being solved; 
\item Method: it is a methodology (or scientific model) used as a basis for an Algorithm;
\item Algorithm: it is how a Task is performed, and is based on a specific Method;
\item Software:  it is an implementation of a particular Algorithm. This is an important concept to our proposal, since the SciFlow ontology may be used to guide the user during the composition of abstract workflows and concrete workflow derivation. It complements the computational environment (SWfMS) in which the concrete workflow definition is manipulated and essentially deals with logical sequences of executable programs.
\item Measure: it is a representation of how an Algorithm performance is measured;
\item Data: it is the semantic representation of an input or output of any Software. Each Software consumes and produces a specific type of Data. The input and output of a Software is modeled in SciFlow.
\end{itemize}


Figure \ref{fig:sciflow} shows part of the SciFlow ontology, in the UML class diagram notation. Axioms are defined for the classes Step, Task, Algorithm, Method, Measure, Software and Data, to represent semantic statements, such as: a step Si always preceeds a step Sj if there is a task Ti that preceeds a task Tj, Ti follows algorithm Ai, and Tj follows algorithm Aj, Ai is implemented by software Swi and Aj is implemented by software Swj, Swi outputs data Di and Swj outputs data Dj. Many important properties were defined for the super classes as well. For instance, a property ''Available'' of Software indicates whether it is available for use or not. Other examples we can cite are: the relationship ''Preceeds'' that indicates which Step or Task precedes another in a logical order.

\begin{figure}[t] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\centering	% FIGURES SHOULD BE CENTERED
		\includegraphics[width=0.5\textwidth]{SciFlow.png} % YOU MAY SHRINK YOUR FIGURE WITH width
	\caption{An excerpt of the SciFlow ontology}	% ALWAYS INCLUDE CAPTIONS IN YOUR FIGURES
	\label{fig:sciflow} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)
\end{figure}



\section{USING ONTOLOGIES TO SUPPORT ABSTRACT WORKFLOW COMPOSITION}

Scientific workflow composition has many difficulties. One of the difficulties is to represent the experiment while moving along these different levels of abstraction. Domain ontologies provide semantic support to workflow activities and data. Combining domain ontologies with workflow ontologies associated with abstract workflows provides a flexible representation mechanism and allows for navigating through several hierarchical levels. These characteristics can help the composition process, for example, when looking for a specific abstract level component or when finding components that are (or may be) used in sequence. Scientific methods and algorithms can be represented along the composition of the abstract workflow, independent from technological issues. It also helps concrete workflow definition. By following an abstract definition, corresponding executable resources can be found to derive the workflow at the concrete level, while still being independent from the SWfMS. The SciFlow ontology plays a fundamental role during concrete workflow derivation by restricting the set of possible programs that may be chosen by the workflow designer to implement each corresponding activity of the abstract workflow. Only programs or services associated to the ontology classes of the abstract workflow are available to be included into the concrete workflow, avoiding rework and misunderstandings. Since there may be several programs, algorithms and methods available, the ontology also helps in exploring these several alternatives. In summary, our approach provides the following facilities to scientists:

\begin{itemize}
\item A controlled vocabulary to be coupled to abstract workflows: activities of an abstract workflow may be associated with ontology terms by a curation team (a team responsible for managing provenance in scientific experiments) and/or by scientists. The terms associated may be methods, algorithms, artifacts, measures, depending on the ontology that is imported to the abstract representation; 
\item A checking mechanism to verify program and service compatibilities: through inference on the ontology, it is possible to identify which data type is related to each software component input and output. With this resource it is possible to run a check type consistency validation of data types in the definition of the scientific workflow, thus avoiding incompatible chaining; 
\item Formalization of all knowledge related to which activities can be linked to each other: all the knowledge related to the experiment is structurally represented in the ontology;
\item Verification of equivalence between activities (if they perform the same conceptual role in the experiment): in most scientific experiments it is necessary to identify which activity of an abstract workflow is equivalent to another. This is possible by looking for all activities which perform the same step in the workflow. This may be useful when a scientist knows the algorithm he/she wants to execute, but does not know (or does not care of) which software to choose that implements the algorithm. In this case, the ontology should be able to offer a list of available software that implements the specific algorithm. Additionally, SciFlow supports the derivation process from abstract to concrete workflows. Relationships between software and its method, algorithms and their associated measures, are explicitly represented. When scientists derive a concrete workflow based on an abstract representation, it is possible to discover programs that can be derived from a specific abstract activity through reasoning from a particular method or algorithm.
\item Verification of dependency between activities: the ontology provides ways to identify whether an activity depends on another and to guide the scientific workflow specification.
\end{itemize}

SciFlow also allows ontology-based semantic provenance registry. Data provenance is the process of storing and sharing information about the origin of each data generated by the workflow \cite{Freire2008}. SciFlow can help users track workflow definitions using domain terminology and semantic relationships between concepts. The ontology data may be stored in a provenance schema along with data of workflow definitions, thus enabling to semantically track composed workflows at several levels of abstraction. Consider that an algorithm follows a significant scientific method and that is implemented by programs P1, P2 and P3. Current provenance support is based on the concrete level only. Thus, when scientists want to know which executed workflows employed some algorithm, they must know there are three available programs and must write queries that search workflows using P1, P2 and P3. SciFlow coupled to a provenance schema can solve queries at more abstract levels (methods, algorithms or programs) through inference capabilities. Browsing provenance data with high levels of abstraction also helps composition with workflow reuse, answering questions such as: What Task does the Software A perform? What kind of Method is used by Software B? What types of Data does the Software C handle? What Algorithm does Software D implement?

\section{MODELING AN ABSTRACT WORKFLOW WITH SEMANTICS ASSOCIATED}

Modeling a computational experiment is very similar to designing an {\em in vivo} or {\em in vitro} scientific experiment \cite{Travassos2003}. In a scientific experiment in laboratory scientists choose a scientific method to follow, document steps executed and then analyze results. Scientific experiments carried out in a computational environment should also be considered in the same way. Their representation should reflect the scientific method, the chosen algorithms and so on. Experiment lines \cite{Ogasawara2009} are an option to model abstract workflows. 

An experiment line \cite{Ogasawara2009} may be defined as an abstract workflow capable to derive multiple workflows at concrete (executable) level. It is a flow of activities in an abstract workflow, where each activity behaves like an independent component. Each activity in an abstract workflow (for simplicity, abstract activity) may be implemented by a sequence of compatible concrete activities. Also, a sequence of abstract activities may be grouped to form another abstract activity. An abstract activity may be mandatory (if it must be used in all derived concrete workflows), optional (if it may be suppressed from a derived workflow related to the experiment line) or variant (if it has more than one alternative program to implement its conceptual component behavior). An example of derivation is in Figure \ref{fig:expline}. 

\begin{figure}[t] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\centering	% FIGURES SHOULD BE CENTERED
		\includegraphics[width=0.5\textwidth]{Expline.png} % YOU MAY SHRINK YOUR FIGURE WITH width
	\caption{An example of an experiment line derivation}	% ALWAYS INCLUDE CAPTIONS IN YOUR FIGURES
	\label{fig:expline} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)
\end{figure}

Although an experiment line is designed to derive many concrete workflows, it presents the same problems of any abstract representation (already presented in Section 1), since it does not provide: a controlled vocabulary to be used, a representation of activities that are equivalent to each other and dependencies between activities. For example, when scientists have more than one concrete activity (a program, a service or a script) that performs the same abstract activity, the scientists need to manually investigate to determine which alternative is the most suitable. However, this investigation can be laborious. Scientists need more support on workflows composition and analysis of the experiment.

We implemented SciFlow in OWL and coupled to experiment lines to support our proposal. SciFlow facilitates the derivation process and acts as a controlled vocabulary for the attributes of the software model. The ontology terms are used to query on metadata and on provenance data, thus helping scientists during derivation process through its inference mechanisms. As mentioned in Section 3 we must have a unified conceptual model to represent the abstract and concrete definitions along with ontology concepts. We extended the experiment line conceptual model (dark gray classes in Figure \ref{fig:model}) to create this unified model, including nine classes to map any workflow ontology to a domain conceptual model. This mapping metamodel allows scientists to associate ontology concepts to workflow activities. Each one of those classes was then implemented as a table in the physical database schema, following the work of Astrova and Kalja \cite{Astrova2008}. In addition, the Workflow concept was distinguished between SimpleWorkflows (which contain just one Activity) and ComplexWorkflows (which are composed of two or more ''parts'', that is, Activities), to address the weak supplementation principle for conceptual modelling \cite{Guizzardi2011}.

\begin{figure}[t] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\centering	% FIGURES SHOULD BE CENTERED
		\includegraphics[width=0.8\textwidth]{Model.png} % YOU MAY SHRINK YOUR FIGURE WITH width
	\caption{Conceptual model for experiment lines}	% ALWAYS INCLUDE CAPTIONS IN YOUR FIGURES
	\label{fig:model} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)
\end{figure}

The Domain class represents the domain in which the ontology is inserted, the Ontology class represents the ontology itself (and its general properties like name, file name, and so on). The OtlElement class represents all of the concepts that exist in the ontology. These concepts may be classes (modeled by OtlClass), properties (modeled by OtlProperty) and relations (modeled by OtlRelation). The other classes (OtlInstance, OtlPropertyValue and OtlRelationInstance) represent the individuals (instances of the ontology), its relations and property values. Although the ontology concepts are present in the conceptual model, inference is still applied using an external reasoner ({\em e.g.} Pellet ). Once the inference is completed, the concepts of the ontology are associated to a specific experiment line or abstract activity to be persisted in the repository (that follows the classes of the conceptual model), thus allowing future queries on experiment definitions.

Other improvements were made on the GExpLine tool to associate ontology concepts to the activities of the experiment lines, support semantic derivation and facilitated composition. They include importing OWL ontology to the GExpLine environment, thus making GExpLine aware of the ontology structure in order to control inference and reasoning and store the ontology concepts in the GExpLine model. A plug-in to parse the entire ontology and populate the model with ontology concepts was developed. This plug-in is based on the Prot\'{e}g\'{e} OWL API that implements a layer over JENA  to handle with OWL files. Also, a specific user interface was developed to import the OWL ontology to the model. The next step was to model the experiment line. We modeled an experiment line, initially represented as a XPDL file without concepts from the experiment. In the GExpLine tool, the imported ontology was associated to the modeled experiment line, by associating an instance of the Ontology class to one instance of the Workflow class. In our current implementation we limited the association to a single ontology {\em per} experiment line. Ontology concepts are then associated to the activities, as illustrated in Figures \ref{fig:tela1} and \ref{fig:tela2}. GExpLine enables reasoning on the ontology to find resources if any concept associated with an activity. For example, suppose that an abstract activity may be derived in many concrete activities. Ontology reasoning guides the scientist to find options and choose a variation to derive the concrete representation by adding ''filters'' using ontology concepts as criteria. Once the concrete activities are chosen and compatibilities are verified, a plug-in is invoked on GExpLine tool to derive concrete scientific workflows modeled to many formats, including to Kepler \cite{Altintas2004}.

\begin{figure}[t] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\centering	% FIGURES SHOULD BE CENTERED
		\includegraphics[width=0.4\textwidth]{tela1.png} % YOU MAY SHRINK YOUR FIGURE WITH width
	\caption{The association of ontology concepts to an abstract activity}	% ALWAYS INCLUDE CAPTIONS IN YOUR FIGURES
	\label{fig:tela1} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)
\end{figure}

\begin{figure}[t] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\centering	% FIGURES SHOULD BE CENTERED
		\includegraphics[width=0.4\textwidth]{tela2.png} % YOU MAY SHRINK YOUR FIGURE WITH width
	\caption{The list of concepts imported from the ontology}	% ALWAYS INCLUDE CAPTIONS IN YOUR FIGURES
	\label{fig:tela2} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)
\end{figure}

\section{RELATED WORK}

We analyzed existing SWfMS support for workflow representation in different levels of abstractions and the semantic support for the process of composing scientific workflows. Available SWfMS are restricted to concrete level. In this way, the knowledge of which activities can be linked to each other is still tacit. Currently, projects in many domains force scientists to redefine, almost from scratch, scientific workflows previously developed by other scientists, incurring in the same composition trial and error process. This occurs due to the absence of a systematic approach for composition and lack of abstract workflow representation. Some approaches use ontologies to help composing scientific workflows. One example is the TAMBIS \cite{Stevens2000} project that aims to provide transparent access to biological databases and scientific analysis tools. It provides a knowledge driven interface where the scientist is able to compose experiments in terms of biological terminology. It focuses on a specific domain (biology) and does not represent generic workflow metadata. In the same direction, the approach proposed by Wolstencroft et al. \cite{Wolstencroft2007} proposes an ontology based on a specific project. 

Ludascher et al. \cite{Altintas2003} present an approach to relieve the scientists from designing directly executable workflows. It represents an abstract workflow based on directed acyclic graphs. It uses database mediation techniques that automatically map abstract workflow activities into executable ones. This mapping is powerful and independent of SWfMS. However, this approach does not add semantics to the abstract activity, thus identifying similar workflows that share a common ancestor is not possible. OWL-WS \cite{Beco2005} is a semantic workflow representation model with a related language that is workflow ontology. The objective is to define a workflow language that enables a specification of dynamic workflows, which are composed of Grid Services and are used as evaluation and binding mechanisms in a Grid Service enactment engine. Although OWL-WS offers a meta-model for scientific workflows, it focuses on concrete workflow representation to model services, ports and infrastructure issues, lacking support for modeling a conceptual representation of a workflow in different levels of abstraction. 

Altintas and  Ludascher et al. \cite{Altintas2003} highlighted the need for conceptual-level features in scientific workflows. They show how to couple domain ontologies to the Kepler SWfMS, through semantic annotations. However, they do not provide different levels of abstraction for scientific workflows, thus it cannot be used to represent abstract workflows in general. The work of \cite{Shoshani2009} distinguishes between different levels of abstraction of loosely coupled experiment workflows to facilitate reuse and sharing of experiments. It has an approach for semantic composition to design scientific workflows in semantic grids. However, they focus on the semantic grid structure, thus navigation along abstract levels is not supported. The work of \cite{Gil2007} highlights the challenges and benefits of composing scientific workflows in different abstraction levels.

myGrid is a semantically rich approach \cite{Wolstencroft2007} coupled to Taverna SWfMS. It is an OWL ontology developed for service discovery through service annotation. This ontology is composed by two sub-ontologies: domain ontology and services ontology. The domain ontology models the bioinformatics domain and the services ontology models the function of Web services and their parameters inside Taverna. Reasoning can be used to find common ancestors of activities between workflow definitions. However, since activity roles are not explicit it is not straightforward to find workflows that share the same method or algorithm. Also, it does not represent which activities can precede one activity or data dependencies as in SciFlow. The authors did not find approaches that represent and comprise semantic support for different levels of abstraction in a generic way, decoupled from specific SWfMS or domains. A careful survey  \cite{Yu2005} for Grid SWfMS reinforces the lack on semantic support for such distributed systems.

\section{CONCLUSIONS}

In this article we proposed an ontology-based approach to add semantics to abstract representations of workflows. We combined the SciFlow ontology to the GExpLine tool. This association enables scientists to add semantics of different levels of abstraction to this generic representation of the experiment line, so that they can focus on the concepts related to the experiment, instead of having to deal with infrastructure issues during the composition phase. 

Once the experiment is represented with all its desired variations, concrete workflows are generated to be executed by the SWfMS of his choice. Our approach was based in a real experiment in the deep water oil exploitation for oil platforms fixation. The ontology specialization helps scientists in understanding the scientific workflow domain and the processes that are being specialized in the SciFlow ontology.

\ack The authors thank CNPq and CAPES for partially sponsoring this research.
				
	
	
% INCLUDE BIBLIOGRAPHY WHICH MUST FOLLOW jidm.bst TEMPLATE

\bibliographystyle{jidm} 
\bibliography{jidmb}


% For information on how to write bibliography entries, 
% see file jidmb.bib

\begin{received}
\end{received}

\end{document}
