Mapping Rationale

From Wings-drugome
Jump to: navigation, search



This pages summarizes the mapping rationale followed to convert the WINGS template and result files to OPM and PROV.

WINGS produces the template separated from the results. However, to understand the execution results it is mandatory to have the template beside you, because the results have the bindings of the variables within the template.

The mapping to OPM and PROV aims to:

Reference Ontologies

OPM proposes to model workflows as a DAG (Directed Acyclic Graph), where the main three nodes are Artifacts (immutable pieces of state), processes (actions or series of actions that occur to artifacts and that end up in the creation of new artifacts) and Agents (catalyzers of the processes, entities that control them).

This three nodes relate to each other through 5 different relationships: used (a process used an artifact), wasControlledBy (a process was controlled by an agent), wasGeneratedBy (an artifact was generated by a process), wasTriggeredBy (a process is triggered by another process) and wasDerivedFrom (an artifact is derived from another artifact). Since the last 2 relationships don't appear in WINGS, and wasDerivedFrom can't be inferred according to the specification, we will not use them for our modelling.

OPMW specification is published here:

Update 27-Aug-2013: The PROV standard has been released in 2013. Therefore we have updated OPMW with a mapping to PROV. All the resources being published according to OPMW are also published according to PROV concepts.

Workflow template

WINGS workflow templates hold the main structure of the workflow. They have descriptions of the inputs and outputs of each node and they provide a unique identifier for each component in each template. They also link to the components and their classes. Although the templates have different node names for each template, different templates may have the same nodeName. When publishing the information as linked data, each node should be unique per template.

See the full OPMW specification for further details.

Workflow execution


StartTime: If we query the processes that use artifacts that haven't been generated by any other process, then it is not enough. In the figure, we see that according to this assertion P1 and P2 have the same starting time, which would be wrong.


EndTime: If we query the nodes that generate artifacts that are not used anymore, then it is not enough. In the figure, we see that according to this assertion P1 and P2 have the same ending time, which would be wrong.

Therefore, the design decission taken is to create 2 new properties (overallStartTime and overallEndTime) to link an account to a dateTime literal. If execution times of each process is included in the future, we could add the relationship to each node too.


OPMW describes the traces of the execution of a workflow along with the abstract workflow (template) used for its design. The trace is described by extending opmv:Artifact with opmw:WorkflowExecutionArtifact; opmv:Process with WorkflowExecutionProcess; and reusing OPM relationships to link them(opmv:used, opmv:wasControlledBy and opmv:wasGeneratedBy). All the assertions from an execution are grouped in a opmw:WorkflowExecutionAccount, a subclass of opmo:Accoount that represents the view of the system on the execution.

Templates are defined with new terms in OPMW, in a similar way to the traces. In this case, the reuse of OPM is not appropriate since we are describing the plan of the workflow(which may be executed in the future or not), not the execution. Templates have opmw:WorkflowTemplateArtifacts (which can be either opmw:DataVariables or opmw:ParameterVariables) and opmw:WorkflowTemplateProcesses, which represent an abstraction of the method that is being executed.

The opmw:WorkflowTemplateArtifacts are connected to opmw:WorkflowTemplateProcesses by opmw:uses and opmw:isGeneratedBy properties. These properties define which type of opmw:WorkflowTemplateArtifact is used by each opmw:WorkflowTemplateProcess and the type of the expected result. The next figure shows a brief example.


The figure shows a process view high level diagram of the OPM and OPMW representation of an abstract workflow on the left and a workflow execution on the right. The example workflow shown here has one step (executionNode1), which runs the workflow component (specComp1) that has one input (execInput1) and one output (executionOutput1).

URI naming convention

URL base for the ontology repository:
URI of the OPM profile:
URI followed by the resources:<Type>/<ResourceName> 


Virtuoso endpoint

Installation where we have the current workflow repository.

Allegro endpoint information (deprecreated)

Allegro was used as an early installation for tests of the repository. It is not further mantained.

Personal tools