4 CETIC, Charleroi, Belgium. Abstract. This paper discusses the use of ..... cal) used during the design/execution of BPs. This could be related to the satisfaction ...
Using Tags for Business Process Enrichment Zakaria Maamar1, Nanjangud C. Narendra2 Ejub Kajan3 , Aldina Pljaskovic3, and Mohamed Boukhebouze4 1
Zayed University, Dubai, U.A.E IBM India Software Lab, Bangalore, India State University of Novi Pazar, Novi Pazar, Serbia 4 CETIC, Charleroi, Belgium 2
3
Abstract. This paper discusses the use of tags for enriching business processes with various details obtained at design- and run-time. In addition to anchoring tags to tasks that constitute a business process, tags are connected to each other through specific data dependencies that in fact, already connect tasks to each other. These dependencies include prerequisite, parallel prerequisite, and parallel. Types of tags proposed during enrichment are social, resource, location, and temporal. Business process engineers and end-users (executors) fill out the tags with the necessary details and ensure that these details are forwarded from one tag to another, when appropriate. The objective is to help reduce time and efforts put into completing the remaining tags. At design time relations between tags include unidirectional-transfer-offinal-details, unidirectional-transfer-of-partial-details, and bidirectionaltransfer-of-partial-details. At run-time relations between tags include strong-trigger, weak-trigger, and meet-in-the-middle trigger. A running scenario along with a demo system are also discussed in this paper. Keywords. Business process, data dependency, tag, task.
1
Introduction
Simply put a business process is a set of tasks connected together with respect to a specific business logic (e.g., mortgage application) and a specific set of requirements (e.g., minimum income for mortgage approval). The research community has been studying business processes from different perspectives including engineering, performance, mining, re-engineering, to cite just a few [11,16]. Entreprises rely heavily on business processes to achieve their objectives and thus, have to ensure that these processes are well defined, streamlined with their development strategies, provided with the right resources, and adapted constantly. With the rapid growth of Internet and Web technologies, entreprises are facing the challenge of how to tap into the large volume of data (aka Big Data) that these technologies produce5 . Being aware of the market’s trends, gauging consumers’ acceptance levels of products, and tracking consumers’ habits will force entreprises to keep abreast of the latest technologies so they incorporate 5
mashable.com/2011/10/20/kirk-skaugen-web-2/.
them into their practices. In conjunction with the Internet and Web technologies growth, there is an increasing interest in blending social computing (exemplified by Web 2.0 applications such as social networks and blogs) with various disciplines. The social enterprise (aka Enterprise 2.0) is a typical example of this blend since maintaining contacts with customers, suppliers, competitors, and partners is highly rewarding [2]. Other domains that are benefiting from this blend include healthcare and commerce. In this paper we look into an additional source of data that enterprises can tap into. This source refers to tags that offer another positive facet of Web 2.0 acceptance. Tagging is defined “as the practice of creating and managing labels (or tags) that categorize content using simple keywords” [9]. There has been a surge in the use of tags with the advent of social applications such as Facebook, Google+, and Myspace. For instance tagging in Facebook gives members the ability to identify and reference people in photos, videos, and notes. While current practices for business process monitoring rely heavily on logs ([4,6]) that record details such as who executed a task, when a task was executed, and what the outcome of a task was, the user (or human) experience of those in charge of designing and executing tasks is simply overlooked or captured later using forms, for example. To address this limitation we propose capturing this experience with multiple tags ranging from social to temporal and technological. We foresee different uses of tags compared to logs that are structured. Indeed a social tag indicates if a person sought the recommendations of a peer when executing a task, which should help in the future maintain a proper support network of contacts for this person. A technological tag indicates the satisfaction level of a person with a certain technology when executing a task. In addition to categorizing tags we go one step further by establishing relations between tags, which should ease their management in the case of changes that affect dependent tags. Our contributions include (i) a set of specialized tags that permit to enrich business processes with various details such as social and technological; (ii) a set of relations supporting the connection between tags. These relations are dependent on the business logic that a process’s tasks implement; and (iii) a demo system showing the development of tags on top of an existing business process case-tool. Section 2 provides a literature review on tag use and suggests a case study. Section 3 presents our tag-based approach in terms of architecture, types of tags, tag connection, and future work. Prior to drawing conclusions in Section 5, a demo system is presented in Section 4.
2 2.1
Background Related work
Different popular Web sites (e.g., delicious.com and flickr.com) give users the opportunity of tagging Web resources. On top of these sites our literature review identified some research works on tagging [3,12] but only two, namely [8] and [14], advocate for connecting tag together.
In [8], Garcia-Castro et al. use tags to consolidate other tags and hence, connect tags together. The objective is to support the emergence of explicit relationships between tags, add meaning to numerical tags, build a “tagsonomy”, and carry out mining operations over tags. The authors define tagging as “assigning shirt lexical elements to resources in a collaborative environment, mainly for document retrieval ”. Garcia-Castro et al. also identify the limitations of tagging for instance, ambiguity and inconsistency across tag contents and across granularity levels. To address these limitations they attach tags to resources (which is the default practice) and tags to arbitrary pairs of tags. We proceed with the same by taking advantage of tasks’ dependencies to connect tags together. More on these dependencies is given in Section 3. In [14], Tanasescu and Streibel introduce extreme tagging as a way to tag two resources namely tags themselves and relations between tags. Users rely on Extreme Tagging System (ETS) that extends the capacities of Collaborative Tagging System (CTS). These capacities include marking content for future navigation, filtering, and/or search. Examples of extreme tagging include “car” tag that can also be tagged by possibly another user with “vehicle” tag. The authors justify the use of additional tags by the fact that they can have different meanings in different contexts. Connecting “vehicle” and “wheel” tags together using “has” tag also permits to develop semantic associations and knowledge paths at a later stage. In [15] Treude and Storey carry out an empirical study to look into how tagging helps in bridging the gap between social and technical aspects in software development. They argue that software development is teamwork by nature requiring intense collaboration and interaction among all stakeholders. On the one hand samples of questions in the study include how does the frequency of tag use vary over the lifetime of the project, why do developers tag work items, and what are the differences between work items and Web content. On the other hand samples of findings from the study include most frequently used tags (polish, testing, svt), reasons for tag use (mainly for categorization), and development of specifictags (lifecycle-related tags versus component-specific tags versus cross-cutting tags versus idiosyncratic tags). In [10] Gupta et al. provide an excellent discussion on why people tag and what tags mean. Motivations behind tag adoption include future retrieval, contribution and sharing, attention attraction, play and competition, self-presentation, opinion expression, task organization, social signalling, money, and technological ease. The authors also list types of tags including content-based, context-based, attribute, ownership, subjective, organizations, purpose, factual, personal, selfreferential, and finally tag bundles. 2.2
Case study
Our case study is an adaptation of the Telephone and Utility Invoice Processing Module (TUIPM) of the Enterprise Content Management (ECM) system6 . TU6
cod.nfc.usda.gov/publications/ECMAgencyDeskProcedures120208.pdf.
IPM process flow shown in Fig. 1 includes different tasks like assemble faxes and process payment and one decision referred to as invoice acceptable?. One of the benefits of TUIPM is that electronic images of telephone and utility invoices are stored in the ECM repository as soon as they are received. Faxed document assembly
Enter data into KeyFast
Assemble faxes
Process payment
END
Optical Character Recognition (OCR) generates PDF
START
Invoice folder
Index & process invoice
Invoice acceptable?
yes
yes
Invoice submitted via fax
no
Invoice submitted via U.S Postal service
Research invoice
Invoice acceptable? no
ECM repository
Cancel invoice
END
Fig. 1. TUIPM’s invoice processing flow-diagram (from [1])
While appearing to be straightforward at first glance, TUIPM process flow could experience several difficulties during execution, of which we list some: – Invoice receipt: if a scanned invoice is sent via email, the current process model does not have a facility to handle this exception. The clerk needs to know how to act. Perhaps the invoice can be printed out and then submitted to the OCR in order to generate the PDF; alternatively, the submitter can be informed to send the invoice via fax or post, only. – Invoice assembly: if the submitted invoice is incomplete because of some missing pages, the clerk could have several options. First, she can either get the invoice scanned via the OCR and pass it on to invoice acceptable? decision, where it will be rejected. Alternatively, she can ask the submitter to resend the missing pages. – Invoice acceptance: this is typically among the duties of the invoice department’s manager. In case she does not find the invoice acceptable, she may route it to subordinates who will execute research invoice task. However, there could be many reasons for an invoice to be unacceptable; depending on the reason, research invoice task would need to be implemented differently. The aforementioned difficulties highlight a well-known fact in business process management; it is usually quite impractical to design a business process with all possible variations/exceptions. Handling these variations/exceptions is usually stored as a tacit information (to become knowledge) in the minds of process engineers and users. It will be useful to provide them with a suitable tagging mechanism that will enable them to explicitly disclose this information so that it can be used for improving business process design and execution in the future. More crucially, since (most) tasks in a business process are dependent on each other as per the process flow (e.g., faxed document assembly then assemble faxes), we advocate that the tags can be connected and correlated using these dependencies.
Therefore, the following research questions arise from this case study. First, while designing the business process flows, how can engineers annotate the flows with the appropriate tags so as to inform users of any special characteristics of the business process that cannot be documented as part of the flow? Second, how can existing tags help users during process execution, and also assist users in providing further tags during process execution? Third, in the case of task failure in the business process, how can tagging information be used to do one or more of the following: help diagnose the cause of the failure, provide inputs on how to address the failure, and if needed, suggest alternative tasks to replace the failed task? We will be exploring these and other related research questions during the rest of this paper.
3
Our tag-based approach
Our approach assists engineers and executors (users in the rest of this paper) in tagging Business Processes (BPs) at both design- and run-time, respectively. Both produce various contents for tags as per the next sections. Our approach also supports administrators analyze the produced tags and correlate them with execution logs. However this is not discussed in this paper. 3.1
Overview
Our tag-based approach is built upon three main components (Fig. 2): BP Modeling (BPM), BP Execution (BPE), and Tag Analysis (TA). The three components connect to a repository of tags referred to as tagRepository.
Administrators
Engineers
Business Process Modeling (BPM)
Tag
Run time
Business processes Business Process Execution (BPE)
Tag Analysis (TA) Query
Design time
Business logic & requirements
Populate Query
Repository of tags
Tag Users
Fig. 2. Tag-based approach’s general architecture
BPM is meant for engineers so they create new BPs and/or edit and delete existing ones. The engineers access the tagRepository in two modes: (i) population mode that consists of creating (editing as well) tags when modeling BPs and (ii) query mode that consists of searching for specific details over the saved tags that could help model BPs. Referring to our case study, in the population mode,
a process engineer could suggest ways to better handle incomplete/incorrect invoices. In the query mode, the same engineer could search for tags created by a peer who advises on how to deal with rejected invoices. BPE is meant for users so they execute BPs upon receipt from the BPM. Like engineers users access the tagRepository in two modes: (i) population mode that consists of creating (editing as well) tags when executing the BPs and (ii) query mode that consists of searching for specific details over the saved tags that could help execute BPs. Referring to our case study, in the population mode, a user could use tags to record his experiences in executing a task such as assembling invoice faxes, for the benefit of future users. He could also record any issues he may have faced, such as handling large volumes of invoices at the same time. Additional duties of the BPE include monitoring the execution progress of BPs and collecting necessary indicators on BPs execution. TA is meant for administrators who run queries over the tagRepository so they can mine engineers and users’ tags. The mining could help identify patterns between BPs, prevent problems prior to BPs execution, develop design and/or execution recommendations, etc. We see differences between BP mining and tag mining. BP mining relies on logs that are well-structured and capture execution (not design) details automatically without human assistance. Contrarily tag mining relies on human assistance to populate tags with unstructured details related to BPs at both design- and run-time. Moreover, execution logs are typically analyzed after BP execution has been completed, whereas tags can be analyzed during and after BP execution; this could even provide guidance towards modifying BPs at run-time in response to actual or predicted failures (Section 3.4). In addition to the aforementioned components, the tagRepository stores tags that engineers and users produce. More on tag types are given in the next section. 3.2
Types of tags
Reflecting the widespread adoption of Web 2.0 applications, social is the mostly cited type of tag [5,7,17]. “Social tagging (aka social bookmarking) is a term to describe the marking, saving and archiving of certain websites. Internet users can use social tagging tools to track and organize their favorite websites, and access them from any computer with an Internet connection”7 . We propose a different description for the social tag that is independent from Web sites and also consider additional tags (other types could be considered without any impact on the proposed approach) for the sake for enriching the design and execution of BPs with various details: 1. Social tag (S-tag): it reports on the interactions that an engineer/user initiates with persons affiliated or not with the organization during the design/execution of BPs. We decompose these interactions into stronglycoupled and loosely-coupled with emphasis on the former in our approach. 7
www.hudsonhorizons.com/Our-Company/Internet-Glossary/Social-Tagging.htm.
The former interactions mean that engineers/users know in-advance the persons that they will interact with through their social networks, for example. The latter interactions mean reaching out to unknown persons using crowdsourcing.Any person is invited to contribute solving a problem and/or handling a task. Loosely-coupled interactions can become strongly-coupled upon the decision of engineers/users to invite persons to join their networks of contacts. 2. Resource tag (E-tag): it reports on the means (software, hardware, physical) used during the design/execution of BPs. This could be related to the satisfaction level with the resources in terms of performance, reliability, and availability. 3. Location tag (L-tag): it reports on where the design/execution of a BP takes place. Examples of locations could be at work, outside the office, shopping mall, etc. This tag suggests options on where a BP can be designed/executed. By tracking the location tag it is possible to tell if the necessary resources made available for engineers/users are accessible, reliable, etc. A recurrent outside-the-office location at run-time might lead into reinforcing the organization’s security and communication means. 4. T emporal tag (T -tag): it reports on when the design/execution of a BP takes place. Examples of times could be during business hours, after business hours, etc. Like with the location tag, the temporal tag is subject to the same analysis. On top of tag types, we differentiate between tags at design time (dTag) from those at execution time (eTag). Table 1 shows the application of the tags to faxed document assembly task with the assumption that Eng1 is in charge of designing the whole business process. To expedite the tagging of the rest of tasks and capitalize on the existing tags, the dependency between faxed document assembly and assemble faxes is taken into account. This will be demonstrated in Section 3.3. Some details on faxed document assembly’s tags could help complete and manage assemble faxes’s tags. Table 1. Tag application to invoice business-process at design-time Tasks faxed document ...
assemble faxes
Tag types Description S-dTag Eng1 posts a note on the organization’s bulletin board asking for the cut-off-date to receive invoices by fax. Accountant1 from financing responds to the note L-dTag Eng1 completes the design of the task outside the office when riding a taxi to a business meeting in downtown T -dTag Eng1 completes the design of the task during regular business hours R-dTag Eng1 does not provide comments on the resources used for designing the task S-dTag ··· . . . . . .
3.3
Operationalizing tag connection
Tag connection can happen in two ways: within same task (left for future work) and across tasks. The former shows how one information in one tag type can affect other tag types. The latter shows how connections between same tags but across different tasks can yield new insights that benefit BPs engineers/users. We connect same tags anchored to different tasks ti and tj using data dependencies that are classified as prerequisite (preReq), parallel prerequisite (parPreReq), and parallel (par); these dependencies are data-driven in the sense of treating one task’s outputs as inputs for other tasks. In a preReq dependency relevant outputs of ti are sent to tj , whereas in a parPreReq dependency intermediary outputs of ti are sent to tj . In a par dependency, ti and tj execute in parallel without an explicit dependency between them, but they may need to synchronize their executions at a certain stage. Design time. The most natural way of designing a BP is to understand the business logic that underpins this BP so that necessary (basic) tasks are defined, necessary inputs per task are identified, expected outputs per task are also identified, and appropriate chronology through input/output dependencies and branching decisions are established. - preReq(ti ,tj ) is mapped onto unidirectional-transfer-of-final-details (utofd) relation between dTagi and dTagj (Table 2). The design of tj begins after completing the design of ti and thus, can take advantage of the final details on ti that are included in dTagi . Table 2. Prerequisite-based tag connection at design time dTagi dTagj Purpose of utofd(dTagi ,dTagj ) specialized into specialized into S-dTagi S-dTagj final list of persons included in S-dTagi could be contacted again when the design of tj begins L-dTagi L-dTagj same location included in L-dTagi could be adopted unless the design is interrupted and resumed in a different location for tj T -dTagi T -dTagj same time frame included in T -dTagi could be adopted unless the design is interrupted and resumed at a later time for tj R-dTagi R-dTagj Same feedback in R-dTagi could be adopted for R-dTagj
Building upon Table 1 we now illustrate the tagging of assemble faxes task using the prerequisite dependency it has with faxed document assembly task. utofd relation is established between the respective tags of these two tasks, which means details included in faxed document assembly’s tags can help complete the design of assemble faxes task and filling out its tag (Table 3). - parPreReq(ti ,tj ) is mapped onto unidirectional-transfer-of-partial-details (utopd) relation between dTagi and dTagj (Table 4). The design of tj does not require the completion of the design of ti and thus, can only take advantage of the partial details (made available at that time) on ti that are included in dTagi .
Table 3. Illustration of utofd relation for tag connection Tasks assemble faxes
Tag types Description S-dTag Eng1 does not seek assistance when completing the design of this task L-dTag Eng1 uses the same location as reported in faxed document ...’s L-tag T -dTag Eng1 uses the same time as reported in faxed document ...’s T -tag R-dTag Same feedback reported in faxed document ...’s T -tag is adopted
Table 4. Parallel prerequisite-based tag connection at design time dTagi dTagj Purpose of utopd(dTagi ,dTagj ) specialized into specialized into S-dTagi S-dTagj partial list of persons included in S-dTagi could be contacted again when the design of tj begins L-dTagi L-dTagj same location included in L-dTagi could be adopted unless the design of tj occurs in a different location T -dTagi T -dTagj same time frame included in T -dTagi is adopted since the design of tj occurs in conjunction with the design of ti R-dTagi R-dTagj Same partial feedback in R-dTagi could be adopted for R-dTagj
- par(ti ,tj ) is mapped onto bidirectional-transfer-of-partial-details (btopd) relation between dTagi and dTagj as per Table 5. The design of ti and tj happens concurrently and partial details included in their respective tags, i.e., dTagi and dTagj , are exchanged mutually. Table 5. Parallel-based tag connection at design time dTagi dTagj Purpose of btopd(dTagi ,dTagj ) specialized into specialized into S-dTagi S-dTagj partial list of persons included in S-dTagi could be contacted while the design of tj is happening and vice-versa L-dTagi L-dTagj same location could be adopted for both L-dTagi and L-dTagj if the design of ti and tj happens in the same location T -dTagi T -dTagj same time frame is adopted in both L-dTagi and L-dTagj R-dTagi R-dTagj Not relevant
Execution time. The most natural way of executing a business process is to submit the different tasks to an engine using the chronology that is set at design time. The respective tags of tasks are filled out in conjunction with the execution of these tasks. Due to lack of space not all the relations are illustrated with tables. - preReq(ti ,tj ) is mapped onto strong-trigger (st) relation between eTagi and eTagj (Table 6). The execution of tj is dependent on the successful execution of ti taking advantage of the final details on ti that are included in eTagi . Strong means that eTagj is filled out after executing successfully ti and filling out successfully eTagi . The failure of ti is reported in eTagi and prevents both executing tj and filling out eTagj . - parPreReq(ti ,tj ) is mapped onto weak-trigger (wt) relation between eTagi and eTagj . The execution of tj is dependent on a certain stage that the
Table 6. Prerequisite-based tag connection at run time eTagi eTagj Purpose of st(eTagi ,eTagj ) specialized into specialized into S-eTagi S-eTagj final list of persons included in S-eTagi could be contacted again when the execution of tj begins L-eTagi L-eTagj same location included in L-eTagi could be adopted unless the execution is interrupted and resumed in a different location for tj T -eTagi T -eTagj same time frame included in T -eTagi could be adopted unless the execution is interrupted and resumed at a later time for tj R-eTagi R-eTagj to complete
execution of ti reaches and hence, certain details on ti (partial inputs) are submitted to tj . Weak means that eTagj is filled out without waiting for the outcome of executing ti and filling out eTagi . Any partial detail in eTagi is made available for the execution of tj . In the case of ti failure which is reported in eTagi , the execution of tj and filling out of eTagj may need to be reviewed. - par(ti ,tj ) is mapped onto meet-in-the-middle-trigger (mmt) relation between eTagi and eTagj (Table 7). Both tags are synchronized to ensure consistent exchange of their details. Table 7. Parallel-based tag connection at run time eTagi eTagj Purpose of mmt(eTagi ,eTagj ) specialized into specialized into S-eTagi S-eTagj partial list of persons included in S-eTagi could be contacted while the execution of tj is happening and vice-versa L-eTagi L-eTagj same location in L-eTagi and L-eTagj could be adopted if the execution of ti and tj happens in the same location T -eTagi T -eTagj same time frame is adopted in both L-eTagi and L-eTagj R-eTagi R-eTagj to complete
3.4
Future work
Connecting tags within same task is one of the points that we would like to look into in the future. Another point, which is described below, concerns the impact of tasks’ transactional properties on tag connection at run-time. This connection assumes the successful execution of tasks. However any execution can fail for multiple reasons like sudden breakdown of computing resources. Retrying an execution a certain number of times, canceling an execution outcome, and/or guaranteeing a successful execution are to be taken into account as per the restrictions featuring the business logics of processes. We associate these restrictions with transactional properties known as pivot, retriable, and compensatable [13]. A task is retriable if it is sure to complete successfully after several finite activations. A task is compensatable if its execution effects can be undone semantically. And, a task is pivot if once it completes successfully, its execution effects remain unchanged for ever and cannot be undone. Additionally,
a pivot task cannot be retried following failure. Briefly we analyze how pivot affects task tagging and tag connection. - preReq(ti ,tj ): as per Table 6, st(eTagi ,eTagj ) is established subject to ti successful execution. In the case of ti failure, this is reported in eTagi along with the consequences of this failure on other tasks, e.g., tj , and tag connection will not occur. - parPreReq(ti ,tj ): wt(eTagi ,eTagj ) is established although the execution outcome of ti is not known yet. In the case of successful outcome wt(eTagi ,eTagj ) is confirmed. In the case of failure the details sent by ti to tj will need to be withdrawn and the execution of tj might be stopped due to lack of these details. - par(ti ,tj ): as per Table 7, mmt(eTagi ,eTagj ) is established although the outcome of neither ti nor tj is known. In the case of successful outcome for ti mmt(eTagi ,eTagj ) is confirmed. In the case of failure the details sent by ti to tj will need to be withdrawn and the execution of tj might be stopped due to lack of these details.
4
Implementation
Fig. 3 shows our system’s architecture that extends Yaoqiang BPMN8 . These extensions permit to anchor tags to tasks, connect tags together, store tags persistently, etc. For demonstration purposes we anchor cut-off date for fax invoices to be taken into account tag to invoices submitted via fax task (shown in yellow box in the screenshot) and also needs access to invoice application tag to index & process invoice task. Afterwards we connect tags together as per one of the aforementioned design-time relations. In use case 1 (top part of Fig. 3) a Business Process Engineer (BPE) leaves the first tag to other BPEs in order to warn them that checking invoice acceptability is the next step in TUIPM modeling. This check might lead into different flows as per Section 2.2. Tags anchored to tasks are stored in appropriate repositories, i.e., BPMN and tag. Use case 2 (bottom part of Fig. 3) shows how a user may connect two tags anchored to different tasks using specific trigger relations. Concretely speaking a partial list of persons that are included in the first tag (i.e., Accountant1 as per Table 1) could be contacted again in order to complete the tag of faxed document assembly task. Depending on the type of trigger relation (whether strong, week, or meet-in-the middle) and content of the first tag the execution of assemble faxes task may be completed successfully or may need to be reviewed as per the cut-off date of receiving fax invoices. Through proper synchronization of tags anchored to faxed document assembly task and assemble faxes task it becomes possible to prevent TUIPM’s failure by ensuring that appropriate details are passed along. Having in mind that the execution of the same business process takes usually several instances at the same time 8
www.sourceforge.net/projects/bpmn.
Business logic & requirements Business Process Modeling
Query
Populate
Business Process Engineers
Tag
Query
bpmn repository
Populate Query
Repository of tags
TUIPMinvoice.bpmn Users
Tag
Tag Analysis
Administrators
Business Process Execution
Fig. 3. System’s architecture and screenshot
such as “on the fly tag synchronization” may significantly enrich business process execution reducing the time needed to solve difficulties that could occur at run-time.
5
Conclusion
In this paper a tag-based approach to manage business processes was presented and illustrated with a running example. Tags report on how the design and execution of tasks of processes by users and engineers, respectively, took place. Tag types are social, resource, location, and temporal. Because tasks are connected through dependencies namely prerequisite, parallel prerequisite, and parallel, tags can be connected together as well using specific relations built upon these dependencies. At design time the relations are unidirectional-transfer-offinal-details, unidirectional-transfer-of-partial-details, and bidirectional-transferof-partial-details. At run-time the relations are strong-trigger, weak-trigger, and meet-in-the-middle trigger. In term of future work we would like to look into the impact of tasks’ transactional properties on tag connection at run-time. Indeed it happens that task execution fails which could delay and even prevent tag connection.
References 1. Enterprise
Content
Management
(ECM)
System,
Telephone
and
2. 3.
4.
5.
6.
7.
8.
9.
10. 11.
12. 13. 14.
15.
16. 17.
Utility Invoice Processing Module, Agency Desk Procedures, 2008. http://cod.nfc.usda.gov/publications/ECMAgencyDeskProcedures120208.pdf, Visited June 2013. Y. Badr and Z. Maamar. Can Enterprises Capitalize on Their Social Networks? Cutter IT Journal, 22(10), October 2009. U. Chukmol, A. N. Benharkat, and Y. Amghar. Bringing Socialized Semantics into Web Services Based on User-centric Collaborative Tagging and Usage Experience. In Proceedings of the 2011 IEEE Aisa-Pacific Services Computing Conference (APSCC’2011), Jeju, South Korea, 2011. M. Comuzzi, S. Angelov, and J. Vonk. Patterns to Enable Mass-Customized Business Process Monitoring. In Proceedings of the 24th International Conference on Advanced Information Systems Engineering (CAiSE’2012), Gdansk, Poland, 2012. U. Cress, C Held, and J. Kimmerle. The Collective Knowledge of Social Tags: Direct and Indirect Influences on Navigation, Learning, and Information Processing. Computers & Education, 60(1), 2013. J. De Weerdt, A. Schupp, A. Vanderloock, and B. Baesens. Process Mining for the Multi-Faceted Analysis of Business Processes - A Case Study in a Financial Services Organization. Computers in Industry, 64(1), 2013. Y. Gao, M. Wang, Z.-J. Zha, J. Shen, X. Li, and X. Wu. Visual-Textual Joint Relevance Learning for Tag-Based Social Image Search. IEEE Transactions on Image Processing, 22(1), 2013. L. J. Garcia-Castro, M. Hepp, and A. Garca. Tags4Tags: Using Tagging to Consolidate Tags. In Proceedings of the 20th International Conference on Database and Expert Systems Applications (DEXA’2009), Linz, Austria, 2009. B. Getting. What Are “Tags” And What Is “Tagging?”, 2007. Practical ECommence - Insight for Online Merchants, http://www.practicalecommerce.com/articles/589-What-Are-Tags-And-What-IsTagging-. M. Gupta, R. Li, Z. Yin, and J. Han. Survey on Social Tagging Techniques. ACM SIGKDD Explorations Newsletter, 12(1), 2010. F. Johannsen and S. Leist. Wand and Weber’s Decomposition Model in the Context of Business Process Modeling. Business & Information Systems Engineering, 4(5), 2012. A. Koschmider, M. Song, and H. A. Reijers. Social Software for Modeling Business Processes. Journal of Information Technology, 25(3), 2010. M. Little. Transactions and Web Services. Communications of the ACM, 46(10), October 2003. V. Tanasescu and O. Streibel. Extreme Tagging: Emergent Semantics through the Tagging of Tags. In Proceedings of the First International Workshop on Emergent Semantics and Ontology Evolution (ESOE’2007), Busan, Korea, 2007. C. Treude and M. A. Storey. How Tagging helps bridge the Gap between Social and Technical Aspects in Software Development. In Proceedings of the 31st International Conference on Software Engineering (ICSE’2009), Vancouver, Canada, 2009. D. Van Nuffel and M. De Backer. Multi-Abstraction Layered Business Process Modeling. Computers in Industry, 63(2), 2012. W. Wei and S. Ram. Using a Network Analysis Approach for Organizing Social Bookmarking Tags and Enabling Web Content Discovery. ACM Transactions on Management Information Systems, 3(3), 2012.
