In business process modeling, semi-formal models typically rely on natural language used to express the labels of model elements. This can easily lead to ambiguities and misinterpretations. To mitigate this issue, the combination of process models with formal ontologies or predefined vocabularies has often been suggested. A cornerstone of such suggestions is to annotate elements from process models with ontologies or predefined vocabularies. Although annotation is suggested in such works, past and current approaches rarely discuss building blocks, parameters and strategies for automating the tedious and errorprone manual task. In this paper, we hence first describe the nature of the annotation task. We then identify building blocks and parameters for automated systems and describe an implementation of an annotation system we used to conduct first empirical studies on the effect of parameters. The paper at hand in sum presents design options and parameters for (semi-) automatically linking semi-formal process models with more formal knowledge representations. It hence may be a source of inspiration for further explorations and experiments on that topic.
In business process modeling, semi-formal modeling languages such as BPMN are used
to specify which activities occur in which order within business processes. Whereas the
order of the activities is specified using constructs of the respective modeling language,
the individual semantics of a model element such as “Check order” is bound to natural
language. However, if models have to be interpreted by machines, e.g. for offering
modeling support, querying on a semantic level [
The remainder is structured as follows. In Section 2, the annotation task is described and three major building blocks for semantic annotation are identified. In Section 3, these building blocks along with their parameters are described in more detail. In Section 4, first considerations and results for/of an empirical analysis are given. In Section 5, related work is discussed and in Section 6 the article is concluded.
Semantic annotation as investigated in this paper means linking process model tasks
(e.g. a task such as “Check order”) with elements of an ontology or vocabulary such as
“Order checking”). We denote these elements as “concepts”. In regard to the
characteristics of the ontology or vocabulary used for annotation, we assume that it is structured
in a hierarchical way, that semantics of the hierarchy is “part-of” and that there is a
partial ordering between siblings in the hierarchy. This assumption seems to be justified
when considering major examples of vocabularies or ontologies such as the PCF
(Process Classification Framework), a publicly available collection of approx. thousand
enterprise activities which is also available industry-specific versions [
In order to understand which building blocks are required for an automated annotation approach, it is helpful to observe and interview human annotators about their strategy. We did so by observing and interviewing students who manually annotated business process models as a part of a tutorial. Process models were specified in the BPMN language and annotated with elements of the PCF (Process Classification Framework) taxonomy. 50 undergraduate students with good knowledge in process modelling participated in small groups in the exercise in the years 2012-2014 and annotated 23 models in a group effort. Since this empirical work is not in the center of the article at hand, we only roughly report the insights we gained. A recurring pattern that has been observed both directly and by interviewing the students has been that annotation roughly followed a 3-step procedure: First, keyword search was performed to search for relevant elements of the PCF taxonomy. Second, in case that multiple relevant elements of the taxonomy were found, the context of these elements was considered and items of the taxonomy were preferred that better correspond to the overall topic of the process. For example, if the topic of the process was Human Resources (HR), participants preferred activities belonging to the category “6. Human Resources” of the PCF taxonomy. Third, in a last step, the selection of an item for annotation was reviewed considering the annotation of preceding and following model elements to verify that it is meaningful and fits the process context. In this step, the partial ordering of the activity taxonomy was taken into consideration meaning that if activities in the taxonomy appeared to occur in a meaningful order (e.g. check order, approve order, execute order), participants strived to not violate that order in the annotations. In this step, also activities that are on a similar hierarchy level (i.e. that are not more specific or detailed) than those selected for the surrounding model elements have been preferred, if possible. In sum, roughly three steps were executed: (1) retrieve annotation candidates by lexical matching, (2) put annotation candidates into context and select the most meaningful and (3) optimize annotation in regard to the annotations of surrounding model elements in terms of order and hierarchy level. These three steps inspire corresponding building blocks of an automated annotation approach which we refer to as element annotation, context detection and annotation fitting. They are described in the following along with adjustment parameters.
For annotating process model activities, relevant activity concepts in the taxonomy have to be found. It is thus necessary to match model element labels against activity concepts from the vocabulary as it is illustrated in Fig. 1. To match process labels against vocabulary concepts, we basically need a similarity function () that returns the similarity between a process activity ∈ and an activity concept ∈ between 0 and 1.
( , ) ∈ [
Using this function, a set of annotation candidates (for “metadata”) can be
computed containing process elements that match to vocabulary concepts with a
matching value ∈ [
= { ( , , ) | ∈ ∧ ∈ ∧ ≥ ℎ ∧ ℎ ≤ ℎ( ) ≤ ℎ }
(2) Confirm order to customer Send notification about
order acceptance
be assigned to a category): If the business topic such as e.g. “Human Resources” of a process model is known, then this knowledge can be leveraged to improve the annotation result. To do so, it could be used to discriminate between activity concepts with a comparable lexical matching value that are candidates for annotation. Hence it is required to detect the general topic of a model which we call category in the following. A category ∈ (for “domain”) can be interpreted as activity concepts that are sub-concepts of the taxonomy root, i.e. = { | ∈ ⋀( , ) ∈ } with
being the set of hierarchy relations of the concepts in the taxonomy. In the simplest form, a category may be specified for the whole model by the user. If that is not possible, a category for the whole model may be derived in an automated way. However, unfortunately there may be models with multiple categories (i.e. multiple topics in one model such as HR and financial planning) and hence it is not clear which category is dominating the model. Such an example is illustrated by Fig. 2. In order to cope with the possibility of multi-category models, the model needs to be partitioned into fragments ∈ containing subsets of activities ⊆ referring to the same category (with a default-subset for parts of the model that cannot = ∪ =1 ∪ where ∩ = ∅ , ≠ (3)
The function ( ) returns the category ∈ for a given fragment and function ( ) returns the corresponding fragment ∈ for a given activity ∈ . Each fragment is associated to exactly one category, i.e. ∀ ∈ ∶ ∃ ∈ ∧ | ( )| = 1. Likewise, each activity should be contained in exactly one fragment, i.e. ∀ ∈ ∶ ∃ ∈ ∧ | ( )| = 1.
About "Human Resources" About "Financial Planning"
The task of partitioning the model into fragments that are associated to a category is dependent on two parameters. First, a minimum size of a fragment has to be specified in order to prevent partitioning the model in activity fragments containing single activities and hence losing the usefulness of categories to discriminate between candidate activity concepts. Second, a lower threshold value for the minimum lexical matching value has to be set specifying the minimum average lexical similarity value between all activities contained in a fragment and sub-concepts in the category ∈ that may be assigned to the fragment. Hence a splitting function () takes the process model and these two parameters as input and generates a set of process fragments as output.
In order to use categories associated to fragments to augment element annotation, the implementation of the similarity function (a, c) has to be extended. Such an extended similarity function will give a higher similarity value if the category given by ( ( )), i.e. the category associated to the fragment an activity belongs to, matches the category of . In order to detect the latter, a function ′( ) which returns the category ∈ for a given activity concept ∈ is defined. In order to control the influence of category matches, i.e. if ( ( )) = ′( ), a weight is added to the refined similarity function ′ ().
′ ( , ,
) ∈ [
In order to increase the semantic quality of the annotation, annotations may be “fitted”. This in essence means to choose between activities that receive comparable matching values in the element annotation step according to notion of betweeness and differences in the hierarchy level. Fig. 3 illustrates this with a small example of three activities that are symbolized on the left side. The discrimination problem is considered for the middle activity. Comparably well matching activity concepts are depicted as grey shaded small circles on the right side. According to the notion of betweeness, the bottom most activity concept c3 can be neglected since it is not in the area of preferred annotation candidates (surrounded by a dotted line). This is due to the fact that it is not between the already selected best matching activity concepts for the previous and following process activity which are illustrated as solid black filled circles. Further, according to the principle of preferring a similar hierarchical level, c2 can also be skipped. Hence amongst similar lexical matches, c1 is superior to c2 and c3 and hence c1 is selected for annotation. ? c2 ?
Area of preferred annotation candidates c1 ? c3 ?
The procedure introduced so far to select activity concepts for annotation roughly resemble to interpolation routines in common image manipulation software where the color of a pixel is calculated according to its neighbors (e.g. Gaussian Filter). We stick to that analogy and call this procedure of fitting semantic interpolation. Analogously, the radius of interpolation may be more than just one pixel which in our case is one preceding and one following activity. The radius may be extended to all preceding and following elements which in literature is also referred to as the corona of a process model element. In this way, the size of the corona may range from 1 to n, i.e. from all preceding and following activities reachable via one step or n steps in the process graph. Beyond the radius parameter for semantic interpolation, it is important that a fitting function is able to adjust the influence of the lexical matching in relation to the influence of hierarchy. Taking this into account, we define a function () as follows: , ) = (6) where are the annotation candidates (cf. formula 2), is the radius used in semantic interpolation, the weight of the lexical matching result and is the weight of the hierarchy match. The latter refers to how the difference of the hierarchy levels of two activity concepts ∈ given by |ℎ( ) − ℎ( )| with ≠ affects the semantic interpolation. The function produces a fitted annotation set ⊆ with just one annotation per process activity, i.e. | | = | |. 3.4
The building blocks specified in in the previous sections may be combined leading to different configurations of the overall automatic annotation system. The following Table 1 describes these configurations. The first column provides a number for each configuration. The next three columns indicate if the building blocks (B1-B3) are used that are specified in the previous sections. The next column Configuration Description provides a short name (in bold) and description of this configuration variant. The next column Configuration Parameters provides a list of accumulated configuration parameters resulting from the different building blocks described in the previous sections. The configurations and parameters described in Table 1 may be used in the development, comparison and optimization of different implementation strategies and hence support a systematically evaluation of automated annotation approaches.
Configuration Parameters – ℎ – ℎ – ℎ similarity threshold min. hierarchy level of activity concepts max. hierar. level of activity concepts Parameters of configuration variant 1 plus the following additional parameters: minimum size of a fragment minimum average lexical similarity value weight of category matches Parameters of configuration variant 1 plus the following additional parameters: To gain first insights regarding the implementation of the building blocks introduced so far, a project was set up to create a simple algorithm. The goal of this algorithm is to match labels of process model activities to a similar or equal counterpart in a standardized framework. The standardized annotations are provided by the Process Classification Framework (PCF). It consists of twelve main hierarchies which are structured into sub-hierarchies of four levels. The hierarchies are in order of increased detail: Process category, process group, process and activity. The first five Process Categories contain operating process while the other describe management and support processes. The models were created by students in a non-related task. The labels were manually matched to the best corresponding concept in PCF thus creating a gold standard. This standard is the basis on testing the accuracy of the algorithm and offers valuable information by analyzing the characteristics of correct matches.
The algorithm is designed to apply a sequence of techniques that each individually affect the outcome. The workflow below shows each step the algorithm takes in order to find the best match for a label. The round-edged rectangles represent techniques. The sharp-edged rectangles indicate the resource data as well as the resulting outcome.
In the following, we describe how the implementation reflect the three building blocks introduced in the previous sections.
Element annotation. The process starts with the resources holding the information schemas of in this case a model and the PCF. For convenience the labels of the individual model elements are called activity labels and the annotations in the PCF are called PCF elements. Each step aims at deriving information about the activity label on different levels. The first method compares solely the characters of two strings. The result is an editing distance showing lexical similarity. In this algorithm, the method used is called the Sorensen-Dice Coefficient. The result of this comparison between activity labels and PCF elements are cross products stored in a similarity matrix. This matrix is the core of the algorithm holding a similarity value for all possible pairs thus enabling an analysis for the best match. As stated in Section 3.1, the scores range between 0 and 1 with 1 being a 100% match. The following steps aim at modifying this value to single out the best match. We did not restrict the similarity threshold ℎ , the min. hierarchy level ℎ was set to 1 and the max hierarchy level ℎ was set to unbounded.
Context detection. To identify the context of a model helps to narrow down the list of possible matches according to their domain. For this analysis the theory in Section 3.2 is taken and applied on the test case, although at the moment we identify the context of a process model only globally, i.e. not partitioning the model in fragments (parameters and hence are irrelevant). The PCF is already classified into 12 domain specific hierarchies with a total of 4 layers. The hierarchy level process group (layer 2) thereby serves as the reference hierarchy. To match an activity label to the correct process group means in this case that the results are narrowed down to a list of max 60 PCF elements. The method uses information extracted by an external tool to derive certain words from the activity labels called synonyms as well as from the process groups called keywords which indicate domain affiliations. Keywords are words that show representative value for a process group in the PCF list. A word suits a keyword if it is present more than 3 times in a sub hierarchy (Fig. 9). This application roughly corresponds to building block 2 from Section 3.4. The matching process compares words by lexical matching. Semantic matching does not take place yet.
The same procedure takes place to create the synonyms list. The synonyms are generated by analyzing the activity labels for representative words. Since a gold standard is provided, a list of representative words on the activity label side towards process groups can be extracted (Fig. 10). The further calculation is the same as with the keywords. The synonyms list is however furthermore in need of constant updating for application on other models. The list created in this case is solely based on the gold standard and still requires verification for other models. Both lists are a preliminary result and are stored as a reference table. Matching activity labels to this list enables a contextrelated comparison and highlights matches on a more abstract level. Controlling the influence of the these matches corresponds to parameter .
Annotation fitting. The last step implies on a theoretical level (cf. Section 3.2) analyzing the predecessors and successors (i.e. the semantic context) of an activity label in the respective model. The content of models can be affiliated to certain process groups. The aim of this step is to punish and reward similarity scores by manipulating the overall score of a model in a process group. This behavior encourages scores of certain process groups to increase more in order to narrow down the highest similarity scores onto few process groups. For instance this step should increase the scores in process group 2.1 and 2.2 for model “1” above all other process groups to reward similarity scores in this sub-matrix (Fig. 8). This pattern of models showing an affinity to certain process groups was discovered by analyzing the gold standard but the algorithm further assumes that the results of the previous steps create the same pattern. The algorithm therefore manipulates the calculated scores. In terms of parameters, radius is unbounded and weights and are implicitly set to 0.
After all methods are processed, an analysis is run to extract the best matches from the similarity matrix with the highest similarity score. Thus two scores are calculated showing the percentage of correct activity label to PCF element match and the percentage of correct activity label to process group match (for the sake of brevity, process group is also simply called hierarchy in Fig. 5-10).
The basic function of the algorithm is to create a matrix containing measures of similarity ranging between 0 and 1 across all possible matches and to manipulate these measures following each step. Each step can be adjusted on the amount of influence on the similarity measure. The testing phase was conducted in order to determine the effectiveness of each step at varying influence. The test set includes 430 annotations derived of 33 independent models. The base result for comparison consists solely on lexical matching. The results of the test is displayed in three graphs (Fig. 5, 6, 7) found in the appendix. In total synonym matching achieved the best results and has a big effect on matching a label to the correct PCF element. It manages to increase the percentage of correct matches from 12% to 18% for direct matches and from 25% to 57% for hierarchy matches, i.e. where at least the process group (level 2) is detected correctly. The other steps show little to no improvement.
The analysis and test are overall a first try at matching model labels. A test of the algorithm with combined influence of all steps is still missing and keyword and synonym matching step is heavily based on the characteristics of the gold standard. Furthermore steps like semantic matching that have not been implemented yet. The analysis could however confirm that semantic patterns such as the overall topic of a process model can be detected and that the PCF can in fact be leveraged as a valuable standard framework. The analysis moreover showed promising results concerning the creation and application of a synonym list.
Comparing our results to the method proposed by Leopold et al. [
Most approaches developed so far only suggest manual annotation (cf. an overview
[
However, the only approach that we are aware that considers context information
(e.g. in the form of preceding or following annotations) when calculating an annotation
suggestion is that of Leopold et al. [
As of today, annotation of process models is rarely automated. Also, rarely prototypes
are shown. Regarding the semantics of annotation, context information is (apart from
[
Selected results from the implementation (Fig. 5-7). Annotation quality (precision, yaxis) is shown in relation to various parameter values (x-axis). Direct Hit means correct annotation in regard to the gold standard. Hierarchy means correct annotation at the process group level (level 2) of the Process Classification Framework.