The pure structural approach to workflow building (as one may usually see that in workflow-oriented business process environments) is usually not enough for scientific types of workflows, especially the ones that are constructed in semi-automatic way like in our example. The syntax and datatype description of data and transformations is simply not enough to support such a sophisticated functionality and therefore the introduction of a abstract naming layer is needed. What is more, such another level of abstractness introduces the possibility of abstract workflow reuse (by abstract workflow we mean every complete application workflow that has no implementation (or execution) details embedded inside and thus may be executed in different environment configurations.
The new abstract naming layer is introduced through annotating important elements in a workflow with concepts describing their semantics These concepts are gathered in a special ontology store that could be accessed from the outside. An example of such an ontology store is Grid Organization Memory (GOM) produced as a part of the K-WfGrid Project.
In order to visualize the matter please visit one of the registries inside GOM. It contains description of services, their inputs and outputs in the domain of Coordinated Traffic Management application. Searching through it one may find concepts of DataObjectsInputs and DataObjectsOutput - these are the actual ins and outs of the operations in the workflow. Especially such outputs are good candidates to be the final result of our workflow:
<DataObjectOutput
rdf:about="http://gom.kwfgrid.net/gom/ontology/ServiceRegistry/CTM/AirPollutionEmissionCalculator#calculateEmissionReturnDataObjectOutput">
<contentConstraint ...>http://gom.kwfgrid.net/gom/ontology/DomainDataOntology/CTM#PollutantEmissionsData</contentConstraint>
<formatConstraint ...>http://gom.kwfgrid.net/gom/ontology/DomainDataOntology/CTM#EMS</formatConstraint>
<storageConstraint ...>http://gom.kwfgrid.net/ontology/DataOntology#RemoteFile</storageConstraint>
</j.0:DataObjectOutput>
For example, if one wants to acquire a workflow that is able to calculate pollutant emission using the CTM application, (s)he can use the URI of the desired output (bolded out in the above example) and put it as the value of the owl attribute of the final place (see description in language section. This way WCT is able to understand what exactly the user wants to get as the final output of the workflow.