=Paper=
{{Paper
|id=None
|storemode=property
|title=Shaken not Stirred: Mixing Semantics into XPDL
|pdfUrl=https://ceur-ws.org/Vol-682/paper5.pdf
|volume=Vol-682
|dblpUrl=https://dblp.org/rec/conf/esws/UrenWS10
}}
==Shaken not Stirred: Mixing Semantics into XPDL==
https://ceur-ws.org/Vol-682/paper5.pdf
Shaken not Stirred: Mixing Semantics into XPDL
Philip Webster & Victoria Uren Marcus Ständer
University of Sheffield Technische Universität Darmstadt
Department of Computer Science Fachgebiet Telekooperation
Regent court Hochschulstr. 10
211 Portobello 64289 Darmstadt, Germany
Sheffield S1 4DP
{P.Webster,V.Uren}@dcs.shef.ac.uk staender@tk.informatik.tu-darmstadt.de
ABSTRACT
Ubiquitous computing requires lightweight approaches to
coordinating tasks distributed across smart devices. We are 1. INTRODUCTION
currently developing a semantic workflow modelling approach Imagine a stylish apartment in the not so distant future. Bob, a
that blends the proven robustness of XPDL with semantics to young IT consultant, has invited his boss to dinner. To impress
support proactive behaviour. We illustrate the potential of the her, he plans to serve dry martinis: four parts gin, one part dry
model through an example based on mixing a dry martini. vermouth and a green olive, chilled to the dew point and shaken
or stirred according to her preference. Luckily for Bob’s career
Categories and Subject Descriptors prospects he has invested in several “smart” consumer products
D.3.3 [Programming Languages]: Language Constructs and that will assist him in creating the perfect cocktail, rather than a
Features – datatypes and structures, I.0 [Computing shot of lukewarm gin with a medicinal aftertaste.
Methodologies]: General, J.7 [Computers in Other Systems]: The SmartProducts project is investigating the technologies
Consumer Products, required to make scenarios such as this one a reality. The project
envisages systems in which some smart products would
General Terms incorporate sensors that can gather environmental data; in this
paper, a cocktail shaker incorporating a temperature sensor is
Languages
taken as an example. Some smart products would also have
enough capacity to reason over ontologies or execute workflows;
Keywords in this paper, this kind of product is illustrated by a device called
XPDL, Ubiquitous computing, Semantic workflows. the Cocktail Guide. Wireless communication would be used to
exchange information between different products in ad hoc
ubiquitous environments. Workflows would provide a means to
Permission to make digital or hard copies of all or part of this work for model tasks that involve a sequence of activities, and to
personal or classroom use is granted without fee provided that copies are coordinate activities being carried out by several products in
not made or distributed for profit or commercial advantage and that copies cooperation with human users.
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior It has been said that modelling behaviour as workflows causes
specific permission and/or a fee. “users to lose control over their work and work to lose the benefit
SBPM2010, May 30–31, 2010, Heraklion, Crete, Greece. of the insights which users bring” [Dourish 1996]. This is a risk
for commercialisation of smart products because, unlike a
business environment where employees can be compelled to
comply with workflow related practises, whether they like them or
not, buying a smart cocktail shaker is a voluntary act. Therefore,
to enhance the experience of using these products, we propose to
add semantic descriptions to workflows to allow ubiquitous
systems to copy the users’ capability of creating links to objects,
combining and reasoning. Ultimately the aim would be to deliver
proactive behaviour based on context information from the
environment, for example, recommending workflows to the user,
or identifying smart products in the vicinity, which could carry
out a given workflow activity.
Annotated workflows have already been investigated in the fields
of business process management, semantic web services and
grids; a review is provided by [Lautenbacher 2007]. All these
fields are characterised by something that the ubiquitous
29
computing environment we have described notably lacks, which is orchestration of participants or services. It is expected that control
access to industrial strength computer processing power. By of process execution will be transferred between the participating
contrast SmartProducts’ technology needs to be deployed on devices, rather than being managed by a centralised workflow
consumer products. This means that cost is a major factor in the execution engine. The SmartProducts consortium agreed with the
selection of electronic. Even a component costing one euro would statement by [Kunze 2006] that a centralised engine may become
significantly increase the final cost of some smaller smart a "single point of failure" and potentially become a "bottleneck
products. These commercial considerations mean that, for the during execution time". All Smart Products developed for the
purposes of current research, we are aiming at working with project communicate over local wireless networks, and may have
gumstix (http://www.gumstix.com). Gumstix is an open source low communications bandwidth. SmartProducts differs from
specification for a computer on a circuit board about the size of a DEMAC in that the process definitions are not transferred from
stick of chewing gum. The targeted gumstix have a 600 MHz device to device as execution progresses. Consequently, the
processor and 256 MB of SDRAM [SmartProducts D6.2.1], transactional and error handling additions made to XPDL in
Although the actual electronics used when products go into DEMAC are not required in our case.
production would most probably not be gumstix, they provide a
readily available research platform of about the right size and SUPER (http://www.ip.super.org) is an integrated project
complexity. providing tools to support the creation and execution of
semantically-enhanced workflows. The SUPER project also uses
Running a workflow execution engine on a gumstix platform is a annotations to provide additional information in workflows. They
big leap from current standards, and in this example we assume use links to ontologies, goals, web services and more [SUPER
that the workflow execution will be controlled by the PDA device 2009] to allow semantic workflow composition, relate
which hosts the Cocktail Guide. Our first step towards achieving input/output to their ontology and allow inclusion of web services.
semantic workflows executing on small devices has been to
develop a lighter weight modelling approach than those that The project provides an Eclipse-derived editor based on the
currently exist. This paper presents the work we have done so far. WSMO Studio editor (http://www.wsmostudio.org/) called
BPMO Editor [Dimitrov 2007] which allows a user to create
Section 2 discusses related work, especially work on semantic workflow process definitions using BPMN (Business Process
annotation of workflows. Section 3 presents the details of our Modelling Notation) or EPC (Event-driven process chain) or to
proposed approach, with discussion of some of the design choices load existing process definitions in these formats and to then add
that were made. Section 4 illustrates functionality the annotated semantic annotation to components of the model, based on
workflows should support using the running example. In Section 5 individuals from an OWL (Web Ontology Language) ontology
we present conclusions. definition. Process definitions created using the BPMO editor are
then converted to BPEL by a plugin for execution on a workflow
2. Related Work execution engine. However, this approach is closely connected to
Modeling task related behavior has been studied extensively the software composition of different services and not to the
because of its obvious commercial importance. Methods that have distribution of workflows on different products, having limited
been considered include task models such as GOMS [Card 1983] resources, e.g. being able to execute one workflow at a time only.
and CTT [Paterno 1997], graph models including Petri Nets
The approach to process definition, annotation and execution in
[Salimifard 2001], and process definition languages like BPEL
SmartProducts differs from the work presented for SUPER in a
[IBM 2007] and XPDL [WfMC 2008]. Since especially the latter
number of areas. The foremost difference is the human-centric
ones have been standards for some time now, they are often used
approach that is central to the SmartProducts platform - products
as bases for manual, semi-automated or fully automated systems.
are intended to assist a human user to complete a task rather than
In the literature there are basically two different concepts for such
being a set of services to be orchestrated. BPEL has weaker
process models: business processes and workflows. The term
support for human participants - this was added initially as a
“business process” thereby describes processes that are focused on
vendor extension (BPEL4People), whereas BPMN and the XPDL
high level descriptions, where objectives play an important role,
serialisation format have human participant capabilities included
while the term “workflow” slides more into the direction of grid
as standard. This difference in scope between BPEL and BPMN
computing, which is much more close to technical details of the
affected the choice of execution engine, and had knock-on effects
environment. Due to the kind of processes in smart environments,
on the choice of process definition languages and tools that could
we stick to the term workflow.
be used without incurring complexity and performance issues.
There are many related projects, which are using workflow
technology combined with semantic information. DEMAC Beyond the human participant emphasis, technical reasons also
[Kunze 2006] for example uses DPDL, an extension of XPDL. influenced the selection of a non-BPEL engine. SmartProducts
DPDL allows annotations about required devices to be attached to uses a workflow execution engine that can execute BPMN
the different participants of a workflow and thus allows the (serialised as XPDL) directly, thus eliminating the need for a
system to choose appropriate devices during runtime. A possible BPMN-to-BPEL translation layer. Much research into BPMN to
problem with such an approach can appear if something changes, BPEL translation has been done, with emphasis on various
e.g. a new device with previously unknown capabilities is techniques for preserving the characteristics of a BPMN process
deployed in the environment. Suddenly the annotation could be diagram when converted to a BPEL executable model. Depending
unsuitable, since it no longer describes the best suitable product. on the modeling style used when creating a BPMN diagram, the
resulting BPEL produced by a conversion algorithm may have
The SmartProducts approach is similar in some respects to the increased complexity (Recker, J. C. M., 2006) and associated loss
approach taken by Kunze, Zaplata and Lamersdorf [Kunze 2006] of human comprehensibility, due to the conceptual mismatch
in that cooperation between devices is emphasised over between the two languages. The solution preferred by
30
SmartProducts was to use XPDL as the serialisation format for suitable base for such descriptions [Kunze 2007]. The
BPMN process diagrams, and also as the execution format development is eased since XPDL supports many workflow
processed by the workflow engine. This eliminated the patterns, which are often used while modeling, directly [van der
complexity issues that would be faced if a conversion were Aalst 2003]. Further, since XPDL is based on the business process
required between the definition and execution phases. modeling notation BPMN [OMG 2009], the workflows can be
visualized using standardized human readable graph
In addition, the BPEL approach places heavy emphasis on visualizations. There are several open source editors available
the use of Web Services to perform execution of the individual (e.g. JaWE), which help developing the workflows. During
blocks of activity in a diagram, and relies on XML-based formats runtime, this visualization eases tracking of the current state of a
for service invocation and data transfer. By comparison, the workflow. Using the XPDL standards also allows developers to
BPMN/XPDL approach allows code to be associated directly with embed their own code into the workflows and thus automate
the activities represented in a process definition. In the XPDL processes by directly steering certain hardware or call own
model, implementation of remote calls is left to the developers. software from within the workflow. To further extend the power
This was an advantage for SmartProducts, as the platform is
of the language, the WfMC has designed XPDL to be extensible.
intended to run on a distributed set of resource contrsained There are tags like the ExtendedAttributes, which can be used to
devices, with no central 'master' process co-ordinator. Typical append data to different parts of the workflows.
SmartProducts devices may be smart kettles or smart ovens, and
as such will have relatively slow CPUs and small amounts of Consequently, our proposed model is an extension of XPDL using
memory, making efficient methods for data transfer and semantic annotation to link in the ontologies. This approach aims
processing very important. Use of a full Web Services framework to blend the power of semantics with the proven capabilities of
would massively restrict the functionality of the SmartProducts XPDL.
devices, as the WSDL and SOAP processing overhead would be
much greater than the overhead imposed by the alternative 3.2 Role of Rules
lightweight embedded middleware used in SmartProducts. Each In a first step, the workflows get annotated with information
device can execute relevant portions of a process directly in a concerning when to start that workflow. Usually there are two
small and functional embedded workflow execution engine, with possible ways to automatically start a workflow: (1) having a big
inter-participant communication achieved via the use of a workflow that permanently runs and that covers every possible
communication middleware layer (MundoCore) which is also situation and then starts sub workflows or (2) trigger workflows
embedded on the devices. from outside. Basically both opportunities are based on the
definition of a set of rules. In our approach we directly attach
Thus, while the SUPER project's implementation was guided by these rules to the headers of the workflows. The purpose of
the requirements imposed by the aim to satisfy the needs of large attaching annotations and trigger rules to the workflow itself is
enterprises seeking to control and monitor commercial business data transfer. It packages the semantic, non-semantic and
processes on centralised workflow execution servers, the workflow information together so that they can be conveniently
SmartProducts implementation is aimed at a radically different stored, e.g., on a new smart product when it is shipped or on a
environment: clusters of small devices working together with a website that provides new workflows to smart product owners.
human user to achieve goals specific to the human user The workflows can be treated as simple XPDL and, if more
participating in the process - with the added flexibility that the powerful computing facilities are available, semantic annotations
human can influence the execution path and non-human and rules can be transferred to them for reasoning.
participant binding dynamically during process execution, rather
than at process definition time. At the time of writing, the rule language that will be used for the
SmartProducts infrastructure remains undecided: the web standard
Further approaches like NEXUS (http://www.nexus.uni-
SWRL (http://www.w3.org/Submission/SWRL/) and Jess
stuttgart.de) or ASTRO (http://astroproject.org) also provide the
(http://www.jessrules.com/) are candidates. To minimize
ability to use semantic information. Unfortunately central
computational requirements, it is likely that a forward chaining
workflow management or missing possibilities to describe the
rule engine will be used.
elements of a workflow flexibly enough make them not
completely suitable for our SmartProducts setting. The format of rules will be determined by the reasoner selection
but we can assume for the purpose of discussion that they may
3. SEMANTIC WORKFLOW MODEL take a form such as:
In this section we detail the semantic workflow model and discuss IF (conditions) THEN (parameters)
our design decisions.
Where the conditions are Boolean expressions containing context
3.1 The Process Definition Language values from the SmartProducts environment and the parameters
One of the central issues in creating smart environments is the are optional context values that identify additional data that the
modeling and handling of processes. These processes require a workflow may require during its execution.
semantically well defined language allowing developers to define Workflow identifiers are not explicitly included in the definition
for example the organizational structures of the different steps, the of rules given above. This is deliberate – the SmartProducts
participants or how to use automation capabilities of some smart platform will be used in environments where devices from
product. Thus, process descriptions range from a very high level multiple product vendors co-operate to complete a process. Each
view down to very system specific details. Regarding the vendor may choose to include a number of process definitions
established standards for process modeling, like BPEL [SRC], with their product, and vendors may not conform to a restrictive
JPDL[SRC] or XPDL [WfMC 2008] it has shown that XPDL is a set of rules for defining workflow identifiers. For this reason, the
31
SmartProducts runtime will generate the identifiers used by the images. While the metadata is put into extended attributes,
process execution engine, eliminating the possibility of conflicts internal data is stored in workflow variables.
by ensuring uniqueness. Vendors may still include their own
workflow identifiers, but these will not be the ones used during
execution. Adding annotations
All trigger rules will be removed from the process definitions and
stored elsewhere, in the trigger component, while the workflows
To allow such annotations, WfMC’s XPDL standard defines the
themselves will be located in a process repository. Workflow ExtendedAttribute element as follows:
identifiers will thus be made unique within a SmartProducts
environment without the need to impose restrictions on vendors.
For the initial design, we reuse the concept of formal parameters “6.4.14.1. Extended Elements and Attributes
used in the XPDL standard. When the workflow is started, so- The primary method to support such extensions is by the use of
called actual parameters are mapped to the formal parameters, extended attributes. Extended attributes are those defined by the
allowing the execution engine to pass required information, like user or vendor, where necessary, to express any additional entity
the user that issued a workflow. Since these parameter signatures characteristics. XPDL schema supports namespace-qualified
form the “interfaces” of the workflows, they can later be extensions to all the XPDL elements. The XPDL elements can be
described by standards like the Web Service Description extended by adding new child elements, and new attributes.”
Language (WSDL) to allow workflows to be used more [WfMC 2008]
dynamically.
We have identified two situations in which rules are required. The
first is for recommending workflows. This will happen outside of Other options within XPDL, such as ExternalReference, have too
the workflow engine. Therefore rules of this type will be added to restricted scopes of use. Extended attributes are a flexible
workflows as annotations so that they can be extracted and approach that we have used to add semantic annotations by
reasoned with to determine the proactive behaviour in the developing a "vocabulary" of different types of extended
ubiquitous environment. The second situation concerns rules that attributes. They can be added to any kind of XPDL element.
are required in order to control the flow of an executing workflow. Therefore annotations could be added in the workflow header if
XPDL already has facilities to add rules of this kind to transitions. they apply to the whole workflow or be attached to specific XPDL
We propose to reuse this feature rather than add semantic rules to elements such as activities, applications, participants, performers
transitions. or transitions if a more precisely scoped annotation is required.
However, so far, we are only annotating activities, applications
The workflow triggering rules should support the proactive and participants. Performers and transitions should not have to be
recommendation of workflows to the user. Default rules for the modeled explicitly for reasons explained below.
triggering of workflows may be attached to workflows when they The WfMC guidelines imply that it is also possible to define
are originally created and shipped to the user. A default rule for ExtendedElements, for example an Application element could be
the dry martini could be that it should not be recommended before defined for smart product software. However in practice we
6pm or to anyone under the age of 18. Individual users may wish cannot find evidence of this being done. Therefore we propose to
to supplement these default rules with personal preferences, for define a vocabulary of extended attributes and guidelines for their
example permitting the suggestion of cocktails from midday use specifying which kinds of elements they can be attached to.
onwards at weekends and on holidays or, for users who abstain
from alcohol, rules that ensure they are only offered nonalcoholic In SmartProducts, lists are used in ExtendedAttributes. This
cocktails. permits multiple values to be added to one workflow element with
a given semantic annotation. In practice, this can be used to
3.3 Annotation provide a list of expected tools or devices that could be used by a
Annotation provides the opportunity to add both semantic and participant to complete an activity, or it could refer to a list of
nonsemantic metadata. This could be of the following kinds: ingredients to be used for a given step in a recipe.
• URIs (linking to instances of an ontology) (semantic) This approach realizes a SmartProducts metadata element set,
• Locally defined tags, required because an ontology will which is more controlled than totally free annotations in which
any extended attributes could be attached to any element. As a
never be complete (could become semantic if fused with starting point we propose three named extended attributes,
the ontology) PRODUCT_CLASS, METADATA and ACTIVTY, which are
• Snippets of text that could be presented to the end user defined in table 1. The workflow elements these can be attached
to are outlined below.
during workflow execution (not semantic)
• Links to other resources such as images (not semantic)
Participant – participants that are smart products can be
• Rules (semantic)
annotated with:
The annotation approach that we propose uses existing XPDL
conventions. In principle we make use of two different kinds of • PRODUCT_CLASS
information when processing a workflow. Informational metadata • METADATA
such as required capabilities of a product, semantic information The Participant PRODUCT_CLASS annotation should not be
about the activity, etc. and information that directly belongs to the used to provide an exhaustive list of acceptable devices that may
information flow of the workflow, like text, names, or links to
32
be used to perform an activity – rather, it enumerates the preferred 4. WORKED EXAMPLE
devices as envisaged by the process designer. The flexibility of An example of a typical SmartProducts scenario is presented to
the SmartProducts platform permits users to utilize alternative illustrate the use of the semantic annotations added to XPDL, and
devices not explicitly defined within the process definition. It may how the SmartProducts platform makes use of this additional
also be possible for a user to use a non-smart device to perform an information to allow new functionality to be implemented. These
activity, and if the workflow engine was designed to strictly reject examples refer to the workflow which is illustrated in figure 1.
any non-specified devices, the process would be stalled
indefinitely in these cases.
Activity – activities that are performed by smart products can be
annotated with:
• PRODUCT_CLASS
• ACTIVITY
• METADATA Figure 1: A workflow for creating a Dry Martini
4.1 Selection of Workflow
Application – applications describing smart products software Imagine Bob can remember that the very stylish cocktail favoured
can be annotated with: by James Bond, includes gin, but he can’t remember what it is
• PRODUCT_CLASS called. He turns to his Cocktail Guide, a piece of software that is
• ACTIVITY installed on his PDA, and which can handle the execution of
cocktail-making workflows. A search for gin quickly pulls up a
• METADATA list of cocktails, which include the ingredient gin. This is possible
The XPDL Performer element is not annotated, as this serves only because the XPDL Activity elements have been annotated with
as a link between a Participant and an Actvity (both of which are METADATA ExtendedAttributes that draws on a domain
already capable of accepting SmartProducts annotations). The ontology that describes the typical ingredients of cocktails.
XPDL Transition element is also not annotated, as the aim of
The following example shows the SmartProducts annotations
SmartProducts is centred on the performance of activities rather
added to the ‘add gin to mixing glass’ step in the creation of a dry
than the flow of the process. The use of expressions as conditions
Martini.
in transitions is considered sufficiently flexible for the project.
It makes sense to have a place in a workflow where people can
store trigger rules that they write to define context conditions that barman
would trigger that flow. These could then be extracted from the
workflow and added to the Ubiquitous Data Store. We propose
the use of ExtendedAttribute to embed a trigger rule into the
Annotation name Description
A product type or types as
PRODUCT_CLASS class it should be possible
to identify substitute
products with similar
functionality.
An instance or instances 4.2 Selection of Devices
from a related domain The smart devices in Bob’s house are wireless enabled. Therefore
METADATA ontology, excluding the Cocktail Guide can recognize which devices are available in
products and activities. It the apartment. Each device can broadcast a semantic description,
supports domain specific which specifies the kinds of action it can perform and the kinds of
annotation. contextual information it can provide. The workflows are
A type of action that is similarly annotated with semantic metadata which describe the
required to complete an actions required to complete activities and context information
activity. This supports the required to coordinate the process.
ACTIVITY
identification of products
based on their capabilities The constrained hardware of ubiquitous computing environments
rather than their type. will compel us to keep the reasoning we do lightweight and to
prove that “a little semantics goes a long way” [Hendler 2003].
33
The kinds of lightweight reasoning tasks that will be needed are This therefore is the element we propose to use. The example
detailed below. below illustrates DataField syntax.
Semantic Querying: Semantic reasoning is required to match the
needs expressed in the workflow annotations against the
capabilities of the devices in the environment. In our running
example, Bob’s apartment contains two alternative devices for
which can perform mixing and detect temperature.
Mapping: Just as nobody can be compelled to buy a smart
cocktail shaker, nobody can be compelled to buy all their
appliances from the same manufacturer (see the discussion on
vendor specific rules in section 3.2). Consequently, different Take four parts gin, one part dry
appliances with similar capabilities will be described differently.
vermouth and place in a cocktail shaker with ice
Taking a semantic approach therefore has clear advantages. Ad
hoc mapping techniques can be envisaged which could recognize
that “Blending” in one ontology is similar to “Mixing” in another.
The example below attaches a metadata URI to a Participant
element. The scope of this annotation is restricted to the
participant. This example comes from the header of a workflow
about making a dry Martini: the annotation identifies that a mixer
4.4 Incorporating Context
To be drinkable the dry martini must be sufficiently chilled. The
can be used and that there are two smart activities that may be
carried out by a compatible mixer. Here there is a choice between workflow is written in such a way that it will not proceed to the
a shaken or stirred Martini. serving step until it has confirmation that the drink has reached
the right temperature. Bob’s smart cocktail shaker contains a
temperature sensor, and the workflow execution engine can make
and designers of workflows should only need to specify when
they react on context changes. In the example above they should
the action.
5. Conclusions
A review of the approaches to semantic annotation of process
4.3 Guiding the user definitions taken so far in existing research led us to conclude that
Bob’s Cocktail Guide, can guide him through the dry martini the SmartProducts platform would need to develop a new
recipe step by step. This will be achieved by using sections of text approach. This approach makes use of the capabilities of a
and images embedded in the workflow, which can be relayed to standard process definition serialisation format (XPDL) that also
Bob through his preferred communication screen; in this case the has good support as a language that can be executed by process
T.V. set in his living room. engines. Semantic annotation functionality was added to improve
retrieval of appropriate workflows and to support functionality
The workflow model requires a way in which to store sections of
such as identifying products that can compete a given activity.
the original text or diagrams. It is common practice in XPDL to
store such text in variables using the XPDL element DataFields.
34
This paper presents the initial effort that has been made toward [IBM 2007] IBM, B. Systems, Microsoft, SAP, and Siebel. Web
this goal. A working version of the system, which includes a services business process execution language (WS-BPEL, BPEL),
newly-defined set of annotations that can be applied to XPDL has version 2.0 specification, 2007
been presented. In additional work not presented here, an editor [Kunze 2007] Kunze, C., Zaplata, S., & Lamersdorf, W. (2007).
prototype that provides support linking of individuals from Mobile processes: Enhancing cooperation in distributed mobile
ontologies to process definition components, and a workflow environments. Journal of Computers, 2(1), 1–11.
engine that can execute semantically-enhanced process definitions
are being developed. Future work will enhance the expressiveness [Lautenbacher 2007] Florian Lautenbacher, Bernhard Bauer, A
and flexibility of the annotation system while also retaining the Survey on Workflow Annotation & Composition Approaches,
ability to use the annotated workflows on lightweight devices co- Proceedings of the Workshop on Semantic Business Process and
operating with a human user. Product Lifecycle Management (SemBPM) in the context of the
European Semantic Web Conference (ESWC), pp. 12-23, 7th
June 2007, Innsbruck, Austria
6. REFERENCES
[Bowman 1993] Bowman, M., Debray, S. K., and Peterson, L. L. [Ouyang 2008] Ouyang C., Dumas M., van der Aalst W.M.P., et
1993. Reasoning about naming systems. ACM Trans. Program. al. (2008). Pattern-based translation of BPMN process models to
Lang. Syst. 15, 5 (Nov. 1993), 795-825. DOI= BPEL Web services. International Journal of Web Services
http://doi.acm.org/10.1145/161468.161471. Research. 5 (1), 42-62.
[Brown 2003] Brown, L. D., Hua, H., and Gao, C. 2003. A widget [Paterno 1997] Paternò F, Mancini C, Meniconi S.
framework for augmented interaction in SCAPE. In Proceedings ConcurTaskTrees: A diagrammatic notation for specifying task
of the 16th Annual ACM Symposium on User interface Software models. In: Proceedings of the IFIP TC13 International
and Technology (Vancouver, Canada, November 02 - 05, 2003). Conference on Human-Computer Interaction table of contents, pp.
UIST '03. ACM Press, New York, NY, 1-10. DOI= 362 - 369 1997
http://doi.acm.org/10.1145/964696.964697 [Recker 2006] Recker, J. C. M., Jan. (2006). On the Translation
[Card 1983] Card S, Moran T, Newell A, 1983. The psychology between BPMN and BPEL: Conceptual Mismatch between
of human-computer interaction. Lawrence Erlbaum Associates Process Modeling Languages.
Inc., 1983 [Salimfard 2001] Salimifard K, Wright M. Petri net-based
[Dimitrov 2007] Dimitrov, M., Simov, A. Stein, S., Konstantinov, modelling of workflow systems: An overview. European journal
M. 2007 A BPMO Based Semantic Business Process Modelling of operational research. 2001;134(3):664–676.
Environment, Proceedings of the Workshop on Semantic Business [Sannella 1994] Sannella, M. J. 1994 Constraint Satisfaction and
Process and Product Lifecycle Management (SBPM-2007), Vol- Debugging for Interactive User Interfaces. Doctoral Thesis. UMI
251, CEUR-WS, June 2007, ISSN 1613-0073 Order Number: UMI Order No. GAX95-09398., University of
[Ding 1997] Ding, W. and Marchionini, G. 1997 A Study on Washington.
Video Browsing Strategies. Technical Report. University of [SmartProducts D6.2.1] D6.2.1: Initial Architecture and
Maryland at College Park. Specification of Platform Core Services, SmartProducts, 2010
[Dourish 1996] Dourish, P., Holmes, J., MacLean, A., [Spector 1989] Spector, A. Z. 1989. Achieving application
Marqvardsen, P., & Zbyslaw, A. (1996). Freeflow: mediating requirements. In Distributed Systems, S. Mullender, Ed. Acm
between representation and action in workflow systems. In Press Frontier Series. ACM Press, New York, NY, 19-33. DOI=
Proceedings of the 1996 ACM conference on Computer supported http://doi.acm.org/10.1145/90417.90738
cooperative work (p. 198). ACM. Retrieved from
http://portal.acm.org/citation.cfm?id=240252. [Tavel 2007] Tavel, P. 2007 Modeling and Simulation Design.
AK Peters Ltd.
[Forman 2003] Forman, G. 2003. An extensive empirical study of
feature selection metrics for text classification. J. Mach. Learn. [WfMC 2008] The Workflow Management Coalition
Res. 3 (Mar. 2003), 1289-1305. Specification, Workflow Management Coalition, Workflow
Standard Process Definition Interface-- XML Process Definition
[Fröhlich 2000] Fröhlich, B. and Plate, J. 2000. The cubic mouse: Language, Document Number WFMC-TC-1025, Document
a new device for three-dimensional input. In Proceedings of the Status – Final Approved, October 10, 2008, Version 2.1a
SIGCHI Conference on Human Factors in Computing Systems
(The Hague, The Netherlands, April 01 - 06, 2000). CHI '00. [Yu 1989] Y.T. Yu, M.F. Lau, "A comparison of MC/DC,
ACM Press, New York, NY, 526-531. DOI= MUMCUT and several other coverage criteria for logical
http://doi.acm.org/10.1145/332040.332491 decisions", Journal of Systems and Software, 2005, in press.
[Hendler 2003] On Beyond Ontology, Keynote talk, International
Semantic Web Conference 2003.
35