Date: Reference number: 2013-01-15 ISO/JTC 1/SC 32N2282jtc1sc32.org/doc/N2251-2300/32N2282T-text_for_ballot-… · · 2013-01-16Part 5: Metamodel for process model registration

Committee Draft ISO/IEC CD5 19763-5

Date: 2013-01-15

Reference number: ISO/JTC 1/SC 32N2282

Supersedes document: 32N2258

THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. IT SHOULD NOT BE USED FOR REFERENCE PURPOSES.

ISO/IEC JTC 1/SC 32 Data Management and Interchange

Secretariat: USA (ANSI)

Circulated to P- and O-members, and to technical committees and organizations in liaison for voting (P-members only) by:

2013-04-15

Please return all votes and comments in electronic form directly to the SC 32 Secretariat by the due date indicated.

ISO/IEC CD5 19763-5:2011(E)

Title: Information technology - Metamodel framework for interoperability (MFI) Part 5: Metamodel for process model registration

Project: 1.32.22.01.05.00

Introductory note:

The attached document is hereby submitted for a 3-month letter ballot to the NBs of ISO/IEC JTC 1/SC 32. The ballot starts 2013-01-15.

Medium: E

No. of pages: 35

Dr. Timothy Schoechle, Secretary, ISO/IEC JTC 1/SC 32 Farance Inc *, 3066 Sixth Street, Boulder, CO, United States of America Telephone: +1 303-443-5490; E-mail: [email protected] available from the JTC 1/SC 32 WebSite http://www.jtc1sc32.org/ *Farance Inc. administers the ISO/IEC JTC 1/SC 32 Secretariat on behalf of ANSI

ISO/IEC CD5 19763-5:2013(E)

i © ISO/IEC 2013 – All rights reserved

ISO/IEC JTC1/SC32 Nxxxx

Date: 2013-1-8

ISO/IEC CD5 19763-5

ISO/IEC JTC1/SC32/WG2

Secretariat: ANSI

Information technology—Metamodel framework for interoperability (MFI) –

Part 5: Metamodel for process model registration

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change

without notice and may not be referred to as an International Standard. Recipients of this draft are invited to submit,

with their comments, notification of any relevant patent rights of which they are aware and to provide supporting

documentation.

Document type: International Standard

Document subtype:

Document stage: (28) Committee Draft

Document language: E

ISO/IEC CD5 19763-5:2013(E)

ii

Copyright notice

This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or otherwise, without prior written permission being secured.

Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's member body in the country of the requester.

ISO copyright office

Case postale 56 CH-1211 Geneva 20

Tel. + 41 22 749 01 11

Fax + 41 22 749 09 47

E-mail [email protected]

Web www.iso.ch

Reproduction may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

ISO/IEC CD5 19763-5:2013(E)

iii

Contents

Foreword ...................................................................................................................................................................... v

Introduction ................................................................................................................................................................ vi

1 Scope .............................................................................................................................................................. 1

2 Normative references .................................................................................................................................... 1

3 Terms, definitions and abbreviated terms................................................................................................... 2

3.1 Terms and definitions…………………………………………………………………………………………2

3.2 Abbreviated terms…………………………………………………………………………………………… 3

4 Conformance .................................................................................................................................................. 4

4.1 General………………………………………………………………………………………………………….4

4.2 Degree of conformance………………………………………………………………………………………4

4.3 Implementation Conformance Statement (ICS)………………………………………………………….4

5 Structure of MFI Process model registration ............................................................................................. .4

5.1 Overview of MFI Process model registration……………………………………………………………..4

5.2 Associations between MFI PMR and MFI Core and mapping………………………………………….6

5.3 Metaclasses in MFI Process model registration………………………………………………………….7

5.3.1 Process_Element………………………………………………………………………………………...7

5.3.2 Process………………………………………………………………………………………………….....8

5.3.3 Process_Model………………………………………………………………………………………….9

5.3.4 Process_Modeling_Language………………………………………………………………………..10

5.3.5 Event………………………………………………………………………………………………………11

5.3.6 Resource…………………………………………………………………………………………………11

5.3.7 Dependency……………………………………………………………………………………………..12

5.3.8 Sequence_Dependency……………………………………………………………………………… 12

5.3.9 Split_Dependency……………………………………………………………………………………...13

5.3.10 Join_Dependency……………………………………………………………………………………...13

5.3.11 Split_Dependency_Option……………………………………………………………………………14

5.3.12 Join_Dependency_Option……………………………………………………………………………15

5.3.13 Process_Involvement…………………………………………………………………………………15

Annex A (informative) Examples of MFI PMR registration…………………………………………………………….17

Annex B (informative) List of process modeling languages ................................................................................ 25

Bibliography .............................................................................................................................................................. 26

ISO/IEC CD5 19763-5:2013(E)

iv

Figures and Tables

Figure 1 – The scope of MFI PMR.............................................................................................................................. 1

Figure 2 –The metamodel of MFI PMR ...................................................................................................................... 6

Figure 3 – The associations between MFI PMR and MFI Core and mapping ....................................................... 6

Figure A.1 –The process model of Handle_Order in UML Activity Diagram ....................................................... 17

Figure A.2 – Registration information of process model Handle_Order in UML................................................ 19

Figure A.3 –The process model of Handle_Online_Car_Repair in BPMN ........................................................... 20

Figure A.4 – Registration information of process model Handle_Online_Car_Repair ...................................... 22

Figure A.5 – The process model of Make_Record in EPC .................................................................................... 23

Figure A.6 – Registration information of process model Make_Record ............................................................. 24

Figure A.7 – Query_Bus_Information process model in OWL-S.......................................................................... 25

Figure A.8 – Registration information of process model Query_Bus_Information ........................................... 26

Table A.1 – Examplary transformation for Case 1 ................................................................................................. 17



Table B.1 – List of Process_Modeling_Languages ............................................................................................... 25

ISO/IEC CD5 19763-5:2013(E)

v © ISO/IEC 2013 – All rights reserved

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form

the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in

the development of International Standards through technical committees established by the respective organization to

deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest.

Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in

the work. In the field of information technology, ISO and IEC have established a joint technical committee,

ISO/IEC JTC 1.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards

adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International

Standard requires approval by at least 75 % of the national bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this part of ISO/IEC CD 19763 may be the subject of

patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

ISO/IEC 19763 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee

SC 32, Data Management and Interchange.

ISO/IEC 19763 consists of the following parts, under the general title Information technology —Metamodel

Framework for Interoperability:

Part 1: Reference Model

Part 3: Metamodel for ontology registration

Part 5: Metamodel for process model registration

Part 6: Registration summary

Part 7: Metamodel for service registration

Part 8: Metamodel for role and goal registration

Part 9: On demand model selection based on RGPS [Technical Report]

Part 10: Core model and basic mapping

Part 11: Structured model registering [Technical Report]

Part 12: Metamodel for information model registration

Part 13: Metamodel for forms registration

http://metadata-standards.org/19763/index.html#A6




ISO/IEC CD5 19763-5:2013(E)

vi © ISO/IEC 2013 – All rights reserved

Introduction

Business process collaboration and integration is growing due to worldwide economic pressures to streamline product

development and delivery and reduce operational costs. Enterprises are merging and forming partnerships to address

these issues. To promote interoperation within and across enterprises, providing registration of process models in a

standard repository so they can be discovered, understood and compared for use and integration will help to facilitate

this kind of collaboration.

Business process modeling languages and notations are widely used to represent processes for different purposes.

However, the differences in the syntax and semantics of process models hamper sharing and reusing them among

enterprises. Therefore, it is necessary to provide a generic mechanism to support registration of administrative

information and selected metadata about process models, and improve discovery of them.

This part of ISO/IEC 19763 intends to provide a metamodel to support the registration of selected metadata and

semantics of process models for process discovery and reuse. It offers a guidance which highlights the common

semantics of process models, helps people clarify the structure of a process and the relationship between processes,

and aids in discovering processes, regardless of the notation in which they were originally written. Any information

related to the details of process modeling languages or the platform for process execution is not taken into account. In

particular, although the registration information of process models can be used to support further discovery of web

services in terms of the associations between process and web services, the process representing either the execution

order within a web service or the orchestration of a set of web services is out of the scope of this part.

Note that in this part, ‟process‟ is meant to be ‟business process‟, and „process model‟ is meant to be ‟business process

model‟.

ISO/IEC CD5 19763-5:2013(E)

1

Information technology–Metamodel framework for interoperability (MFI) –Part 5: Metamodel for process model registration

1 Scope

The primary purpose of the multipart standard ISO/IEC 19763 is to specify a metamodel framework for interoperability.

This part of ISO/IEC 19763, Part 5: Metamodel for process model registration (PMR), specifies the metamodel that

describes a facility to register administrative information and selected metadata about process models. The metamodel

specified in this part is intended to promote semantic discovery and reuse of process models within/across process

model repositories. For this purpose, it provides selected metadata and common semantics of process models created

with a specific process modeling language, including Business Process Modeling Notation (BPMN) [1], UML (Unified

Modeling Language) Activity Diagram [5], and EPC (Event-driven Process Chain) [7], etc. The metamodel can help

discovery of function and composition of a process, and promote reuse of its components at different levels of

granularity. Figure 1 shows the scope of this part.

Figure 1 – The scope of MFI PMR

The following are outside the scope of this part of ISO/IEC 19763:

- details related to modeling notations or descriptive languages of process models;

- runtime environments or implementation platforms for executing processes.

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only

the edition cited applies. For undated references, the latest edition of the referenced document (including any

amendments) applies.

ISO/IEC 19763-1, Information technology – Metamodel framework for interoperability (MFI) – Part 1: Reference model

ISO/IEC 19763-3:2010, Information technology – Metamodel framework for interoperability (MFI) – Part 3: Metamodel

for ontology registration

ISO/IEC 19763-10, Information technology – Metamodel framework for interoperability (MFI) – Part10: Core model and

basic mapping

Process model

Registry based on MFI PMR

BPMN

UML EPC

…

registry

process model

model register

Legend

Scope of MFI PMR

metadata about

process models

NOTE: Not every model needs to exist in a repository before registration.

ISO/IEC CD5 19763-5:2013(E)

2

3 Terms, definitions and abbreviated terms

3.1 Terms and definitions

For the purpose of this part, the terms and definitions contained in ISO/IEC 19763-3:2010, ISO/IEC 19763-7, ISO/IEC

19763-8, and ISO/IEC 19763-10 and the following shall apply.

3.1.1

activity

set of cohesive tasks

NOTE adapted from ISO/IEC 12207:2008 4.3

3.1.2

task

specific piece of work to be done [ISO 16091:2022]

3.1.3

process

collection of related, structured activities or tasks that achieve a particular business goal

NOTE The activities and tasks are represented by the Process metaclass in this part.

3.1.4

process modeling language

special language used to represent processes

NOTE PSL, BPMN, UML Activities etc. are all process modeling languages.

NOTE special language [ISO 1087-1:2000 3.1.3]

3.1.5

process model

representation of a process, using a specific process modeling language

3.1.6

control constraint

restriction on the execution order for a given collection of processes

3.1.7 .

dependency

relationship between processes, specifying the control constraints followed by the processes in a process model

3.1.8

process element

abstraction of the modeling constructs that comprise a process, including processes and dependencies among them

3.1.9

resource

asset that is utilized, created or consumed during the execution of a process

NOTE The resources can be either physical or virtual.

3.1.10

event

occurrence of a particular set of circumstances

[ISO/IEC 16085:2006 3.2]

3.1.11

process involvement

set of specification, each of which specifies a particular role and how the role is involved in this process

http://www.iso.org/iso/en/CatalogueListPage.CatalogueList

ISO/IEC CD5 19763-5:2013(E)

3

3.1.12

precondition

state that exists before a process is invoked

NOTE adapted from ISO/IEC 19763-7:3.1.7

3.1.13

postcondition

state that exists after a process is successfully invoked

NOTE adapted from ISO/IEC 19763-7:3.1.8

3.1.14

sequence dependency

kind of control constraint between processes, specifying that the processes are executed in order

3.1.15

split dependency

kind of control constraint between processes, specifying that if the preceding process is completed, one or more of

the following processes will execute in parallel

3.1.16

join dependency

kind of control constraint between processes, specifying that the following process will start when the selected

preceding processes are completed

3.1.17

guard condition

condition that must be satisfied before an associated process can execute

3.2 Abbreviated terms

BPMN

Business Process Model and Notation

[OMG BPMN version 2, formal/2011-01-03]

EPC

Event-driven Process Chain

See Bibliography item [7]

MFI

Metamodel framework for interoperability

[ISO/IEC 19763-1:2007, 4.2]

MFI Core and mapping

ISO/IEC 19763-10, Information technology – Metamodel framework for interoperability (MFI) – Part 10: Core model

and basic mapping

MFI Role and Goal registration

ISO/IEC 19763-8, Information technology –Metamodel framework for interoperability (MFI) – Part 8: Metamodel for role

and goal registration

MFI Ontology registration

ISO/IEC 19763-3:2010, Information technology – Metamodel framework for interoperability (MFI) – Part 3: Metamodel

Editor's note:

If this part becomes DIS, the definitions of the following terms will be copied here: role, goal, service, exit condition

and involvement type.

ISO/IEC CD5 19763-5:2013(E)

4

for ontology registration

[ISO/IEC 19763-3:2010, 3.2]

MFI PMR

ISO/IEC 19763-5, Information technology –Metamodel framework for interoperability (MFI) – Part 5: Metamodel for

process model registration

MFI Service registration

ISO/IEC 19763-7, Information technology –Metamodel framework for interoperability (MFI) – Part 7: Metamodel for

service registration

UML

Unified Modeling Language

[ISO/IEC 19505-2]

4 Conformance

4.1 General

An implementation claiming conformance with this part of ISO/IEC 19763 shall support the metamodel specified in

Clause 5, depending on a degree of conformance as described below.

4.2 Degree of conformance

4.2.1 General

The distinction between „strictly conforming„ and ‟conforming„ implementations is necessary to address the

simultaneous needs for interoperability and extensions. This part of ISO/IEC 19763 describes specifications that

promote interoperability. Extensions are motivated by needs of users, vendors, institutions and industries, but are not

specified by this part of ISO/IEC 19763.

A strictly conforming implementation should be limited in usefulness but is maximally interoperable with respect to this

part of ISO/IEC 19763. A conforming implementation may be more useful, but may be less interoperable with respect

to this part of ISO/IEC 19763.

4.2.2 Strictly conforming implementation

A strictly conforming implementation

a) shall support the metamodel specified in 5;

b) shall not support any extensions to the metamodel specified in 5.

4.2.3 Conforming implementation

A conforming implementation

a) shall support the metamodel specified in 5;

b) may support extensions to the metamodel specified in 5.

4.3 Implementation Conformance Statement (ICS)

An implementation claiming conformance with this part of ISO/IEC 19763 shall include an Implementation

Conformance Statement stating

a) whether it is a strictly conforming implementation or a conforming implementation (4.2);

b) what extensions are supported if it is a conforming implementation.

5 Structure of MFI Process model registration

5.1 Overview of MFI Process model registration

MFI PMR provides a generic metamodel to register selected metadata about process models described by a specific

modeling language. Figure 2 shows the metamodel for process model registration.

ISO/IEC CD5 19763-5:2013(E)

5

In this part, process model is used as a representation of a process, and it describes the process elements contained

in using a specified process modeling language. The process elements include processes and dependencies between

processes. For each process, there are some events that can be used to trigger a process or produced by a process.

In order to achieve a particular business goal, some resources are used, created or consumed during the execution of

a process, and a set of particular roles are involved in to help the execution of the process.

ProcessEvent

Resource

Service_Operation

Precondition

Postcondition

Process_Involvement

Goal

0..* 0..*

0..* 0..*

0..* 0..*

0..* 0..*

0..* 0..*

0..*

0..*

0..1 1..1

0..1 1..1

0..* 1. .1

0..1 0..*

Process_Model

Process_Element

Dependency

Split_Dependency

Join_Dependency

Sequence_Dependency

Process_Modeling_Language0..* 1..1

1..1

1..1

1..1

1..1

preceding_element

following_element

following_element

preceding_element

0..*

0..*

describing_model

described_process

successor

0..*

1..1

precedent

precedent

0..*

1..1

successor

1..1

precedent

0..*

1..1

preceding_process

0..*

Join_Dependency_Option2..*preceding_option

Split_Dependency_Option2..*

following_option

0..*

1..*

containing_model

contained_process_element

trigger triggered_process

produced_event producer

consumed_resource consumer

created_resource

used_resource user

creator

fully_realizing_service_operation

fully_realized_process

constraint constrained_process

constraint constrained_process

involved_process_involvement involving_process

achieved_goal achieving_process

0..*following_option

0..*preceding_option

split_dependency_type[1..1]:String

is_synchronous[0..1]:Boolean

join_dependency_type[1..1]:String

is_synchronous[0..1]:Boolean

guard_condition[0..1]:String

guard_condition[0..1]:String

describing_languageexpressed_model

NOTE Metaclasses whose names are italicized are abstract metaclasses

following_process

successor

Registered_Ontology_Atomic_Construct

0..*0..*0..*

0..*0..*

0..*

annotated_process

annotationannotation

annotated_event

annotation

annotated_resource

Metaclasses defined in MFI Role and Goal registration, MFI Service registration, and MFI Ontology registration

annotation

annotated_process_model

0..*

0..*

Involvement_Type

decomposed_process

composing_process_element

0..*

0..*

0..*

1..1

described_involvment_type

describing_type

Exit_Condition 0..1 0..*

containing_exit_condition contained_process

Role

1. .1

0..* involved_process_involvement

involving_role

Figure 2 – The metamodel of MFI PMR

Dependencies represent the control constraints among processes represented by a process model. In this part, it can

be specialized as sequence dependency, split dependency, and join dependency. More specifically, sequence

dependency shows that the processes are executed in order. Split dependency specifies that when the preceding

process is completed, one or more of the following processes will execute in parallel. Join dependency designates that

the following process will start when the selected preceding processes are completed. In split dependency, split

dependency type is used to specify a logical gate for the following processes. In join dependency, similarly, join

dependency type is used to specify a logical gate for the preceding processes. In this part, the values of both split

dependency type and join dependency type can be XOR, OR and AND. For split dependency type XOR means that

one and only one of the succeeding processes is allowed to execute, OR means that one or more of the succeeding

processes are allowed to execute and AND means that all of the succeeding processes must execute. For join

dependency type, XOR means that the succeeding process executes if one and only one of the preceding processes

completes successfully, OR means that the succeeding process executes if one or more of the preceding processes

completes successfully and AND means that the succeeding process executes if, and only if, all of preceding

ISO/IEC CD5 19763-5:2013(E)

6

processes completes successfully. In addition, split dependency option represents the guard conditions of the following

processes to be executed after the value of split dependency type is decided. Similarly, join dependency option

specifies the guard conditions of the preceding processes to be executed after the value of join dependency type is

decided. Figure 2 also shows the associations between MFI PMR and MFI Ontology registration, MFI Role and Goal

registration, and MFI Service registration.

The association between MFI PMR and MFI Role and Goal registration specifies that each process achieves zero or

one goal, and each goal is achieved by zero, one or more processes. A goal may exist that is not specified to be

achieved by a process, and a process may exist which is not applied to achieve a specific goal. Similarly, each process

involves zero, one or more process involvements, and each process involvement is involved in one and only one

process. A process involvement may exist with no associated process. Particularly, each process involvement is

described by one and only one involvement type, stating that the process involvement can be performer, beneficiary,

customer, etc. Each role may consist of several process involvements, and each process involvement is involved only

one role.

The association between MFI PMR and MFI Service registration specifies that each process is fully realized by zero,

one or more service operations, and each service operation can fully realize zero, one or more processes. A process

may exist that is not specified to be realized by a service, and a service may exist that is not applied to realize a

process. Each process has one precondition or postcondition. A process may exist with no associated precondition or

postcondition. Each process has zero or one exit condition to state a set of conditions that will exist to cause a process

to terminate before its completion.

In order to add semantics to a process and its elements, a registered ontology atomic construct based on MFI Ontology

registration can be added as the annotations for each process, process model, event and resource as necessary.

5.2 Associations between MFI PMR and MFI Core and mapping

The associations between the metaclasses in MFI PMR and the metaclasses in MFI Core and mapping are shown in

Figure 3.

EventResourceProcess_Model

Process Dependency

Join_DependencySplit_Dependency

Sequence_Dependency

NOTE Metaclasses whose names are italicized are abstract metaclasses

Modeling_Language

(from MFI Core and

mapping)

Model

(from MFI Core and

mapping)

Model_Element

(from MFI Core and

mapping)

Join_Dependency_OptionSplit_Dependency_Option

1..1 0..*

1..1 0..*

0..*0..*

0..* 1..* Process_ElementProcess_Modeling_Language

Process_Involvement

specialization

between associations

subClassOf

Legend

Figure 3 – The associations between MFI PMR and MFI Core and mapping

On one hand, the metaclasses Process_Modeling_Language in MFI PMR is the subclass of Modeling_Language in

MFI Core and mapping. Process_Model in MFI PMR is the subclass of Model in MFI Core and mapping. All the

remaining metaclasses are the subclasses of Model_Element in MFI Core and mapping. On the other hand, the

association between Process_Model and Process_Modeling_Language is a specialization of the association between

Model and Modeling_Language in MFI Core and mapping. The association between Process_Model and

Process_Element is a specialization of the association between Model and Model_Element in MFI Core and mapping.

ISO/IEC CD5 19763-5:2013(E)

7

5.3 Metaclasses in MFI Process model registration

5.3.1 Process_Element

Process_Element is an abstract metaclass each instance of which represents a specific process element, which is an abstraction

of the modeling constructs that comprise a process, including processes and dependencies among them.

Superclass

Model_Element (defined in MFI Core and mapping)

Attribute DataType Multiplicity Description

[None]

Reference Class Multiplicity Description Inverse Precedence

containing_

model

Process_Model 0..* The set of process models which

include this process element. This is a

specialization of „contained_by‟ in MFI

Core and mapping

contained_

process_

element

No

decomposed_p

rocess

Process 0..* The set of processes which decompose

into this process element

composing_pro

cess_element

Yes

successor Split_Dependency 0..* The set of split dependencies each of

which, if appropriate, follows this

process element

preceding_

element

Yes

preceding_

option

Split_Dependency_

Option

0..* The set of split dependency options

each of which specifies the guard

condition, if any, that is used to

determine whether this process

element is to be executed

following_

element

Yes

precedent Join_Dependency 0..* The set of join dependencies each of

which, if appropriate, precedes this

process element

following_

element

Yes

following_

option

Join_Dependency_

Option

0..* The set of join dependency options



determine whether this process

element is to be joined with another

process element in the associated join

dependency

preceding_

element

Yes

Constraints

[None]

ISO/IEC CD5 19763-5:2013(E)

8

5.3.2 Process

Process is a metaclass each instance of which represents a specific process, which is a collection of related, structured activities

or tasks that achieve a particular business goal.

Superclass

Process_Element


[None]


describing_

model

Process_Model 0..* The set of process models, each of

which may describe the composition of

this process

described_

process

No

composing_pro

cess_element

Process_Element 0..* The set of process elements, including

processes and dependencies among

them, each of which composes a

process

decomposed_p

rocess

No

created_

resource

Resource 0..* The set of resources, each of which

may be created by this process

creator Yes

consumed_

resource

Resource 0..* The set of resources, each of which

may be consumed by this process

consumer Yes

used_resource Resource 0..* The set of resources, each of which

may be used in the execution of this

process

user Yes

produced_

event

Event 0..* The set of events, each of which may

be produced by this process

producer Yes

trigger Event 0..* The set of events, each of which may

trigger (i.e. activate) this process

triggered_

process

No

precedent Sequence_

Dependency

0..* The set of sequence dependencies,

each of which specifies that this

process follows the process that is the

preceding process for the particular

sequence dependency

following_

process

No

successor Sequence_

Dependency

0..* The set of sequence dependencies,

each of which specifies that this

process precedes the process that is

the following process for the particular

sequence dependency

preceding_

process

No

ISO/IEC CD5 19763-5:2013(E)

9

5.3.3 Process_Model

fully_realizing_

service_operati

on

Service_Operation 0..* The set of service operations, each of

which may fully realize the process. In

the case that a process is fully realized

by a set of service operations, the

process should be decomposed into a

certain level such that each subprocess

of the process can be fully realized by a

service operation

fully_realized_

process

No

involved_

process_

involvement

Process_

Involvement

0..* The set of process involvements, each

of which designates how a particular

role is involved in this process

involving_

process

Yes

achieved_goal Goal 0..1 The goal that can be achieved by this

process

achieving_

process

Yes

constraint Precondition 0..1 The set of conditions that must exist

before this process is invoked

constrained_

process

Yes

constraint Postcondition 0..1 The set of conditions that must exist

after this process is invoked

successfully

constrained_

process

Yes

annotation Registered_Ontology

_Atomic_Construct

0..* The set of registered ontology atomic

constructs that can be used to annotate

this process, each of which identifies a

concept in a domain ontology that

expresses the meaning or scope of this

process

annotated_

process

Yes

containing_exit

_condition

Exit_Condition 0..1 The set of conditions that will exist to

cause a process to terminate before its

completion

contained_proc

ess

No

Constraints

[None]

Process_Model is a metaclass each instance of which represents a specific process model, which is a representation of a process,

using a specific modeling language.

Superclass



[None]


ISO/IEC CD5 19763-5:2013(E)

10

5.3.4 Process_Modeling_Language

describing_

language

Process_Modeling_

Language

1..1 The process modeling language that is

used to represent this process model.

This is a specialization of

„described_by‟ defined in MFI Core and

mapping

expressed_

model

Yes

contained_

process_

element

Process_Element 1..* The set of process elements that are

described in this process model. This is

a specialization of „contains‟ defined in

MFI Core and mapping

containing_

model

Yes

described_

process

Process 0..* The process whose decomposition is

described using this process model

describing_

model

Yes

annotation Registered_Ontology

_Atomic_Construct


constructs that can be used to annotate

this process model, each of which

identifies a concept in a domain

ontology that expresses the meaning or

scope of this process model

annotated_proc

ess_model

Yes

Constraints

[None]

Process_Modeling_Language is a metaclass each instance of which represents a specific process modeling language, which is a

special language used to represent processes.

Superclass



[None]


expressed_

model

Process_Model 0..* The set of process models that are

expressed using this process modeling

language. This is a specialization of

„describes‟ defined in MFI Core and

mapping

describing_

language

No

Constraints

[None]

ISO/IEC CD5 19763-5:2013(E)

11

5.3.5 Event

5.3.6 Resource

Event is a metaclass each instance of which represents a specific event, which is an occurrence of a particular set of

circumstances.

Superclass



[None]


triggered_

process

Process 0..* The set of processes, each of which is

triggered by this event

trigger Yes

producer Process 0..* The set of processes, each of which

can produce this event

produced_

event

No

annotation Registered_Ontolog

y_Atomic_Construct


constructs that can be used to

annotate this event, each of which


ontology that expresses the meaning

or scope of this event

annotated_

event

Yes

Constraints

[None]

Resource is a metaclass each instance of which represents a specific resource, which is an asset that is utilized, created or

consumed during the execution of a process. Resources can be either physical or virtual.

Superclass



[None]


consumer Process 0..* The set of processes, each of which

can consume this resource in the

execution of the process

consumed_

resource

No

creator Process 0..* The set of processes, each of which

can create this resource in the


created_

resource

No

ISO/IEC CD5 19763-5:2013(E)

12

5.3.7 Dependency

5.3.8 Sequence_Dependency

user Process 0..* The set of processes, each of which

can use this resource in the execution

of the process

used_

resource

No

annotation Registered_Ontolog

y_Atomic_Construct


constructs that can be used to

annotate this resource, each of which


ontology that expresses the meaning

or scope of this resource

annotated_res

ource

Yes

Constraints

The 'consumer', 'creator' and 'user' references are mutually exclusive for any one process; i.e. a process can consume a particular

resource or create a particular resource or use a particular resource.

Dependency is an abstract metaclass each instance of which represents a specific dependency, which is a relationship between

processes, specifying the control constraints followed by the processes in a process model.

Superclass

Process_Element


[None]


[None]

Constraints

[None]

Sequence_Dependency is a metaclass each instance of which represents a specific sequence dependency, which is a kind of

control constraint between processes, specifying that the processes are executed in order.

Superclass

Dependency


[None]


following_

process

Process 1..1 The process that follows this

sequence dependency

precedent Yes

ISO/IEC CD5 19763-5:2013(E)

13

5.3.9 Split_Dependency

5.3.10 Join_Dependency

preceding_

process

Process 1..1 The process that precedes this

sequence dependency

successor Yes

Constraints

[None]

Split_Dependency is a metaclass each instance of which represents a specific split dependency, which is a kind of control

constraint between processes, specifying that if the preceding process is completed, one or more of the following processes will

execute in parallel.

Superclass

Dependency


split_

dependency_

type

String 1..1 The statement that specifies whether this split dependency is an „AND‟

split dependency, an „OR‟ split dependency or an „XOR‟ split dependency.

„XOR‟ means that one and only one of the succeeding processes is

allowed to execute, „OR‟ means that one or more of the succeeding

processes are allowed to execute, and „AND‟ means that all of the

succeeding processes must execute.

is_synchronous Boolean 0..1 The indication that specifies whether the process elements to be split

must be synchronous or not. The value of „TRUE‟ means synchronous

and the value of „FALSE‟ means not synchronous.


following_

option

Split_Dependency_

Option

2..* The set of split dependency options



determine whether the associated

process element is to be executed

precedent No

preceding_

element

Process_Element 1..1 The process element that precedes this

split dependency.

successor No

Constraints

[None]

Join_Dependency is a metaclass each instance of which represents a specific join dependency, which is a kind of control

constraint between processes, specifying that the following process will start when the selected preceding processes are

completed.

Superclass

ISO/IEC CD5 19763-5:2013(E)

14

5.3.11 Split_Dependency_Option

Dependency


join_

dependency_

type

String 1..1 The statement that specifies whether this join dependency is an „AND‟

join dependency, an „OR‟ join dependency or an „XOR‟ join dependency.

„XOR‟ means that the succeeding process executes if one and only one of

the preceding processes completes successfully, „OR‟ means that the

succeeding process executes if one or more of the preceding processes

completes successfully, and „AND‟ means that the succeeding process

executes if, and only if, all of preceding processes completes

successfully.

is_synchronous Boolean 0..1 The indication that specifies whether the process elements to be joined

must be synchronous or not. The value of „TRUE‟ means synchronous

and the value of „FALSE‟ means not synchronous.


preceding_

option

Join_Dependency_

Option

2..* The set of join dependency options



determine whether the associated

process element is to be joined with the

other process elements associated with

this join dependency through join

dependency options

successor No

following_

element

Process_Element 1..1 The process element that follows this

split dependency

precedent No

Constraints

[None]

Split_Dependency_Option is a metaclass each instance of which represents a specific split dependency option, which is a kind of

constraint to specify the guard condition that determines whether the following process element is to be executed or not.

Superclass



guard_

condition

String 0..1 The specification of the condition that must be true for the following

process element to be executed. The following process element will be

executed if no guard condition is specified.


precedent Split_Dependency 1..1 The split dependency for which this split

dependency option specifies the guard

following_option Yes

ISO/IEC CD5 19763-5:2013(E)

15

5.3.12 Join_Dependency_Option

5.3.13 Process_Involvement

condition for one of the associated

following process elements

following_

element

Process_Element 1..1 The process element that follows this

split dependency option

successor No

Constraints

[None]

Join_Dependency_Option is a metaclass each instance of which represents a specific join dependency option, which is a kind of

constraint to specify the guard condition that determines whether the preceding process element is to be joined or not.

Superclass



guard_

condition

String 0..1 The specification of the condition that must be true for the preceding

process element to be joined with the other process elements associated

through the other join dependency options associated with the same join

dependency


successor Join_Dependency 1..1 The join dependency for which this join

dependency option specifies the guard

condition for one of the associated

preceding process elements

preceding_

option

Yes

preceding_

element

Process_Element 1..1 The process element that precedes this

join dependency option

successor No

Constraints

[None]

Process_Involvement is a metaclass each instance of which represents a specific process involvement, which is a set of

specification, each of which designates a particular role and how the role is involved in a process.

Superclass



[None]


ISO/IEC CD5 19763-5:2013(E)

16

involving_proce

ss

Process 1..1 The process that is specified by this

involvement on how a particular role is

involved in it

involved_

process_

involvement

No

describing_type Involvement_Type 1..1 The involvement type that is the

corresponding description of this

involvement

described_invol

vement_type

Yes

involving_role Role 1..1 The role that is involved in to help the


involved_proces

s_involvement

Yes

Constraints

[None]

ISO/IEC CD5 19763-5:2013(E)

17

Annex A

(informative)

Examples of MFI PMR registration

In this section, four cases are provided to illustrate how to register various kinds of process models based on MFI PMR.

In detail, the process models in the four cases use UML Activity Diagram, BPMN, EPC and OWL-S respectively. The

corresponding registration information is listed to show that MFI PMR can be used to register heterogeneous process

models. It also means that MFI PMR can harmonize with existing specifications related to process modeling.

Case 1: Train_Ticket_Reservation process in UML Activity Diagram.

Train Ticket Reservation process is expressed in UML Activity Diagram to illustrate the process of online train ticket

reservation. In Figure A.1, the ticket reservation process consists of a set of sub-processes which are used to handle

the details of booking train tickets. The process will start if the user login successfully. Then the user can select the

train information according to his or her travel itinerary. If the available ticket is not sold out, the user needs to fill and

save detailed reservation information. After that, the system will automatically send reservation information to customer

by Email and SMS (Short Message Service) to facilitate user confirmation.

Login Check_Certification Select_Itinerary Display_Available_Train_Info

Get_Desired_Train_Details

Fill_Reservation_OrderSave_Reservation_Order

Login_Fail

legal_user

illegal_user

Send_Email

Send_SMS

Confirm_Ticket

Figure A.1 –The process model of Train_Ticket_Reservation in UML Activity Diagram

Table A.1 lists the uniform transformation from the elements in Figure A.1 to the corresponding metaclasses in MFI

PMR. It supports registering the process model of Train_Ticket_Reservation in UML Activity Diagram in a MFI PMR

registry.

Table A.1 – Examplary transformation for Case 1

Notation of UML Activity

Diagram Metaclass in MFI PMR

Notation of UML Activity

Diagram Metaclass in MFI PMR

Event

Split_Dependency

Process

Join_Dependency

Sequence_Dependency

R

e

c

e

i

v

e

_

M

a

k

e

_

P

a

y

m

e

n

t

ISO/IEC CD5 19763-5:2013(E)

18

Process_Model_01

name Train_Ticket_Prebooking_Model

describing_language UML

described_process Process_00

contained_process_el

ement

Process_01

Process_02

Process_03

Process_04

Process_05

Process_06

Process_07

Process_08

Process_09

Process_10

Sequence_Dependency_01





Split_Dependency_01

Split_Dependency_02

Join_Dependency_01

Process_Modeling_Language

name UML

version 2.1.2

Event_01

name Prebooking_Ticket_From_Customer

trigger_process Process_01

Process_00

name Handle_Ticket_Reservation

describing_model Process_Model_01

Process_01

name Login

containing_model Process_Model_01

trigger Event_01

following_element Check _Certification

Process_02

name Check _Certification


preceding_element Process_01

successor Split_Dependency_01

Process_03

name Fail_Login


preceding_option Split_Dependency_Option_02

produced_event Event_02

Process_04

name Select _Itinerary



following_element Process_05

Process_05

name Display_Available_Train_Info




Process_06

name Get_Desired_Train_Details




Process_07

name Fill_Reservation_Order




Process_08

name Save_Reservation_Order


precedent Join_Dependency_02


Process_09

name Send_SMS


preceding_Option Split_Dependency _Option_03

following_Option Join_Dependency_Option_01

Process_10

name Send_Email



following_option Join_Dependency_Option_02

ISO/IEC CD5 19763-5:2013(E)

19

Process_11

name Confirm_Ticket




Split_Dependency_01

split_dependency_typ

e

XOR

is_synchonous FALSE


following_option Split_Dependency_Option_01

Split_Dependency_Option_02


guard_condition legal_user


precedent Split_Dependency_01


guard_condition illegal_user



Split_Dependency_02

split_dependency_type AND

is_synchonous TRUE











preceding_process Process_01

following_process Process_02













Join_Dependency_01

join_dependency_type AND

is_synchonous TRUE


preceding_option Join_Dependency_Option_01

Join_Dependency_Option_02



successor Join_Dependency_01




Event_02

name User_Exit

producer Process_03

Event_03

name Order_Closed

producer Process_11

Figure A.4 – Registration information of process model Train_Ticket_Reservation in UML Activity Diagram

ISO/IEC CD5 19763-5:2013(E)

20

Case 2: Handle_Online_Car_Repair process in BPMN

Handle_Online_Car_Repair process is expressed in BPMN to indicate the process of how to deal with the online order

of repairing cars. In Figure A.3, the Handle_Online_Car_Repair process will start when a repair request is registered.

Then, the credit card will be charged for the payment of repairing cars. If the credit card is declined, Handle_Fault

process will be invoked to return an error and terminate prematurely; if accepted, the customer will schedule a garage

appointment. Next, Order_Tow_Truck process may be executed to transport the broken-down car. Meanwhile, the

customer can rent a car by invoking Order_Temporary_Car and evaluate whether it meets his requirements or not. To

rent a desirable car, Order_Temporary_Car and Evaluate_Temporary_Car will be executed repeatedly till the

appropriate car is recommended. After that, the customer confirms the order of handle processes, and the

Handle_Online_Car_Repair process completes successfully.

Charge_Credit_

Card

Order_Tow_

Truck

Order_Temporary_

Car

Evaluate_Temporary_

CarDoneDone

Check againCheck again

Handle_Fault

Schedule_Gara

ge_Appointment

Confirm_OrderRegister_Rep

air_Request

Figure A.3 –The process model of Handle_Online_Car_Repair in BPMN

Table A.2 lists the uniform transformation from the elements in Figure A.3 to the corresponding metaclasses in MFI

PMR. It supports registering the process model of Handle_Online_Car_Repair in BPMN in a MFI PMR registry.


Notation of BPMN Metaclass in MFI PMR

Notation of BPMN Metaclass in MFI PMR

Event

Split_Dependency

Process

Join_Dependency

Sequence_Dependency

[

o

r

d

e

r

_

r

e

j

e

c

t

e

d

]

ISO/IEC CD5 19763-5:2013(E)

21

Process_Model_02

name Handle_Online_Car_Repair_Process_Model

describing_languag

e

BPMN

described_process_ Process_00

contained_process_

element

Process_01

Process_02

Process_03

Process_04

Process_05

Process_06

Process_07

Process_08



Split_Dependency_01

Split_Dependency_02

Split_Dependency_03

Join_Dependency_01

Join_Dependency_02


name BPMN

version 2.0

Event_01

name Repair_Request_From_Customer


Process_00

name Handle_Online_Car_Repair


Process_01

name Register_Repair_Request


trigger Event_01

successor Sequence_Dependencdy_01

Process_02

name Charge_Credit_Card


precedent Sequence_Dependency_01


Process_03

name Schedule_Garage_Appointment




Process_04

name Handle_Fault




Process_05

name Order_Tow_Truck




Process_06

name Order_Temporary_Car



successor Sequence_Dependency_02

Process_07

name Evaluate_Temporary_Car




Process_08

name Confirm_Order







Split_Dependency_01

split_dependency_type XOR

is_synchonous FALSE





guard_condition charge_credit_card_successed



guard_condition charge_credit_card_failed


ISO/IEC CD5 19763-5:2013(E)

22

Split_Dependency_02

split_dependency_type OR

is_synchonous FALSE





guard_condition need_tow_truck




guard_condition need_temporary_car






Split_Dependency_03


is_synchonous FALSE





guard_condition satisfied_temporary_car




guard_condition unsatisfied_temporary_car



Join_Dependency_01

join_dependency_type OR

is_synchonous FALSE





guard_condition temporary_car_confirmed

preceding_option Split_Dependency_03


guard_condition tow_truck_confirmed


Join_Dependency_02

join_dependency_type OR

is_synchonous FALSE




Event_02

name Credit_Card_Fault_Event

producer Process_04

Event_03

name Car_Repair_Closed

producer Process_08

Figure A.4 – Registration information of process model Handle_Online_Car_Repair

ISO/IEC CD5 19763-5:2013(E)

23

Case 3: Make_Record process in EPC

Make_Record process is expressed in EPC to express the process of how to deal with the song record making. As the

following figure shows, the recording process is triggered by the event Start. After the equipment is prepared, you can

choose the songs to be recorded. Next, you can record the selected songs. After that, if you want to record more songs,

you can choose and record songs repeatedly; if not, the record will be sent to marketing, and Make_Record process is

completed.

Start Choose_SongRecord_ Song

Song_ Chosen

Song_ Recorded

Send_ Record_

MarketingEnd

XOR

EventFunction XOR Operator

XOR

XOR

Prepare_Equipment

Equipment_Prepared

More_Song_Needed

Figure A.5 – The process model of Make_Record in EPC

Table A.3 lists the examplary transformation from the elements in case 3 to the corresponding metaclasses in MFI

PMR. It supports registering the process model of Make_Record in EPC in a MFI PMR registry. In Figure A.5, the start

event and end event is taken as event in MFI PMR. The event directly connected to split dependency and join

dependency is taken as split dependency option or join dependency option. And the event between two functions is

registered as sequence dependency. The detailed illustration is shown in Table A.3.


Notation of EPC Metaclass in MFI PMR

Notation of EPC Metaclass in MFI PMR

Start End

Event

XOR

Join_Dependency

Process

Sequence_Dependency

XOR

Split_Dependency

ISO/IEC CD5 19763-5:2013(E)

24

Process_Model_03

name Make_Record_Process_Model

describing_language EPC


contained_process_element Process_01

Process_02

Process_03

Process_04

Join_Dependency_01


Split_Dependency_01


name EPC

version None

Event_01

name Start_Make_Record


Process_00

name Make_Record


Process_01

name Prepare_Equipment


trigger Event_01


Process_02

name Choose_Song



successor Sequence_Dependency_01

Process_03

name Record_Song




Process_04

name Send_Record_Market




Join_Dependency_01

join_dependency_type XOR

is_synchonous FALSE





guard_condition equipment_prepared




guard_condition need_more_song

preceding_element Split_Dependency_01





Split_Dependency_01


is_synchonous FALSE





guard_condition need_more_song




guard_condition record_completed



Event_02

name End_Event

producer Process_04

Figure A.6 – Registration information of process model Make_Record

ISO/IEC CD5 19763-5:2013(E)

25

Case 4: Query_Bus_Information process in OWL-S

Query_Bus_Information process is expressed in OWL-S to designate how to deal with the bus information query. In

this case, the processes described in OWL-S have almost the same structure, such as input, output, and execution

between them. So Figure A.7 only illustrates part of the OWL-S code. The process is triggered by an event “Start”. You

can query the Bus information by location name or by route number. The output of this process is the result from the

query as information to be provided to the user.

…………<process:AtomicProcess rdf:ID="Query_With_Location_AP">

<process:comment>No Comments</process:comment>

<process:hasInput>

<process:Input rdf:ID="Location_Name">

<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#string"/>

</process:Input>

</process:hasInput>

<process:hasOutput>

<process:Output rdf:ID="Bus_Information_Query_With_Location">

<process:parameterType rdf:datatype="http://www.owl-ontologies.com/UrbanTransportation.owl#Bus_Information"/>

</process:Output>

</process:hasOutput>

</process:AtomicProcess>

<process:AtomicProcess rdf:ID="Query_With_Route_AP">

<process:comment>No Comments</process:comment>

<process:hasInput><process:Input rdf:ID="Route_Number">

<process:parameterType rdf:datatype="http://www.w3.org/2001/XMLSchema#string"/>

</process:Input>

</process:hasInput>

<process:hasOutput>

<process:Output rdf:ID="Bus_Information_Query_With_Route">

<process:parameterType rdf:datatype="http://www.owl-ontologies.com/UrbanTransportation.owl#Bus_Information"/>

</process:Output>

</process:hasOutput>

</process:AtomicProcess>

<process:CompositeProcess rdf:ID="Query_Bus_Information_CP">

<process:composedof>

<process:Choice><process:components>

<process:ControlConstructList>

<list:first>

<process:Perform rdf:ID="Perform_Query_With_Route_AP">

<process:process rdf:resource="Query_With_Route_AP"/>

</process:Perform>

</list:first><list:rest>

<process:ControlConstructList>

<list:first>

<process:Perform rdf:ID="Perform_Query_With_Location_AP">

<process:process rdf:resource="Query_Bus_With_Location_AP"/>

</process:Perform>

</list:first><list:rest>

<list:rest rdf:resource="http://www.daml.org/services/owl-s/1.1/generic/ObjectList.owl#nil"/>

</list:rest></process:ControlConstructList></list:rest>

</process:ControlConstructList></process:components>

</process:Choice>

</process:composedof>

</process:CompositeProcess>

</rdf:RDF>

……….

Figure A.7 – Query_Bus_Information process model in OWL-S

While an OWL-S based process model is transformed for MFI PMR, at least one start and multiple ends will be

automatically added in. In case 4, only one start and one end are added.

There is no examplary transformation table for OWL-S based Query_Bus_Information process model temporally. For

the OWL-S is not graph-oriented, and emphases on the functional closure for describing properties and capabilities,

rather than structuring fragments used in most graph notations, so the typical and simple transformation used in the

ISO/IEC CD5 19763-5:2013(E)

26

previous 3 cases is not the accurate representation for the so-called mapping between OWL-S and metaclasses of MFI

PMR, then compound structures of metaclasses of MFI PMR are used to interpret the control structures of OWL-S,

such as Choice in this case is interpreted as a block of alternative branches between a split dependency with XOR type

and a join dependency with XOR type.

Process_Model_04

name Query_Bus_Information_Process_Mod

el describing_language OWL-S


contained_process_el

ement

Process_01

Process_02

Process_03

Process_04

Split_Dependency_01

Join_Dependency_01


name OWL-S

version 1.2

Event_01

name Query_Bus_Information_Started

triggered_process Process_01

Process_00

name Query_Bus_Information

trigger

Event_01

Process_01

name Query_Information


trigger Event_01


Process_02

name Query_With_Location




Process_03

name Query_With_Route




Process_04

name Provide_Information




Split_Dependency_01


is_synchonous FALSE





guard_condition know_location_address




guard_condition know_route_number



Join_Dependency_01

join_dependency_type XOR

is_synchonous FALSE





guard_condition get_bus_information




guard_condition get_bus_information



Event_02

name Bus_Information_Query_Closed

producer Process_04

Figure A.8 – Registration information of process model Query_Bus_Information

ISO/IEC CD5 19763-5:2013(E)

27

Annex B

(informative)

List of process modeling languages

It is advisable that the instance of ‟Process_Modeling_Language‟ be one of the values in column ‟name‟ of Table B.1.

Table B.1 – List of Process_Modeling_Languages

Name Description

BPMN Business Process Modeling Notation, Object Management Group, 2011 [1].

BPEL Business Process Execution Language for Web Service (BPEL/BPEL4WS), 2003-05-03, Version 1.1 [2]

UML A language that conforms to ISO/IEC 19505-2 Information technology – OMG Unified Modeling

Language (OMG UML) Version 2.1.2 – Part 2: Superstructure.

PSL A language that conforms to ISO/IEC 18629 Process Specification Language [3].

IDEF3 IDEF3 (Integrated DEFinition for Process Description Capture Method) is a business process modeling

method. It is a scenario-driven process flow description capture method intended to capture the

knowledge about how a particular system works [4].

EPC Event-driven Process Chain (EPC) is a type of flowchart used for business process modeling. It was

developed in the early nineties in a joint effort between researchers at the University of Saarland and

SAP [6]. It is used to describe business processes at the informal business level [7].

OWL-S Ontology Web Language for Services supplies Web service providers with a core set of markup

language constructs for describing the properties and capabilities of their Web services in unambiguous,

computer-interpretable form [8].

Other

http://en.wikipedia.org/wiki/Flowchart

http://en.wikipedia.org/wiki/Business_process_modelling

ISO/IEC CD5 19763-5:2013(E)

28

Bibliography

[1] Business Process Model and Notation (BPMN) Version 2.0, OMG Document Number: formal/2011-01-03, January,

2011. Available at: http://www.omg.org/spec/BPMN/2.0.

[2] Business Process Execution Language for Web Services (BPEL 1.1), 2003-05-05. Available at:

http://xml.coverpages.org/BPELv11-May052003Final.pdf.

[3] ISO 18629-1:2004, Industrial automation systems and integration -- Process specification language -- Part 1:

Overview and basic principles.

[4] IDEF3 Process Description Capture Method Report, September 1995. Available at:

http://www.idef.com/pdf/Idef3_fn.pdf.

[5] ISO/IEC 19505-2 Information technology -- OMG Unified Modeling Language (OMG UML) Version 2.1.2 -- Part 2:

Superstructure, at 2 Normative reference.

[6] Keller, G; Nüttgens, M, Scheer, A.-W, “Semantische Prozebmodellierung auf der Grundlage”, publication of the

Institut für Wirtschaftsinformatik, paper 89, Saarbrucken, 1992.

[7] Hafedh Mili, Guitta Bou Jaoude, Éric Lefebvre, et al., “Business Process Modeling Languages: Sorting Through the

Alphabet Soup”, ACM Computing Surveys, Springer, Volume 43 Issue 1, 2010.

[8] Ontology Web Language for Service.OWL-S1.2 2008-12, available at: http://www.daml.org/services/owl-s/.

http://www.omg.org/spec/BPMN/2.0

http://xml.coverpages.org/BPELv11-May052003Final.pdf

http://xml.coverpages.org/BPELv11-May052003Final.pdf

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35431

http://www.idef.com/pdf/Idef3_fn.pdf

Documents

Date: Reference number: 2013-01-15 ISO/JTC 1/SC 32N2282jtc1sc32.org/doc/N2251-2300/32N2282T-text_for_ballot-… · · 2013-01-16Part 5: Metamodel for process model registration