ISO/IEC 15944-1:2002

Information technology - Business agreement semantic descriptive techniques - Part 1: Operational aspects of Open-edi for implementation

Technologies de l'information — Techniques descriptives sémantiques des accords d'affaires — Partie 1: Aspects opérationnels de l'Edi ouvert pour application

General Information

• Status: Withdrawn
• Publication Date: 25-Sep-2002
• Withdrawal Date: 25-Sep-2002
• ICS: 35.240.60 - IT applications in transport
• ICS: 35.240.63 - IT applications in trade
• Technical Committee: ISO/IEC JTC 1/SC 32 - Data management and interchange
• Drafting Committee: ISO/IEC JTC 1/SC 32/WG 1 - eBusiness
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 21-Jul-2011
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15944-1:2011 - Information technology - Business operational view - Part 1: Operational aspects of open-edi for implementation
• Effective Date: 26-Sep-2009

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 15944-1
First edition
2002-08-15
Information technology — Business
agreement semantic descriptive
techniques —
Part 1:
Operational aspects of Open-edi for
implementation
Technologies de l'information — Techniques descriptives sémantiques des
accords d'affaires —
Partie 1: Aspects opérationnels de l'Edi ouvert pour application

Reference number
ISO/IEC 15944-1:2002(E)
©
ISO/IEC 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from 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 [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2002 – All rights reserved

Contents Page
Foreword . v
0 Introduction . vi
0.1 Purpose and overview . vi
0.2 Requirements on the business operational view aspects of Open-edi. viii
0.3 Business operational view (BOV), Open-edi and E-commerce, E-business, etc. . xi
0.4 Use of “Person”, “person”, and “party” in the context of business transactions and
commitment exchange . xii
0.5 Organization and description of the document . xii
0.6 Registration aspects of Open-edi scenarios, scenario attributes and scenario components. xiii
1 Scope. 1
2 Normative references. 2
3 Terms and definitions. 2
4 Symbols and abbreviated terms. 12
5 Characteristics of Open-edi . 12
5.1 Actions based upon following clear, predefined rules . 13
5.2 Commitment of the parties involved. 13
5.3 Communications among parties are automated.13
5.4 Parties control and maintain their states. 13
5.5 Parties act autonomously. 14
5.6 Multiple simultaneous transactions can be supported. 14
6 Components of a business transacation. 14
6.1 Introduction . 14
6.2 Rules governing person . 26
6.3 Rules governing the process component . 42
6.4 Rules governing the data component. 46
6.5 Business requirements on the FSV (Business demands on Open-Edi Support Infrastructure) . 51
6.6 Primitive classification and identification of Open-edi scenarios . 54
7 Guidelines for scoping open-edi scenarios . 64
7.1 Introduction and basic principles. 64
7.2 Rules for scoping Open-edi scenarios . 65
7.3 Template for specifying scope of an Open-edi scenario . 68
8 Rules for specification of Open-edi scenarios and their components. 73
8.1 Introduction and basic principles. 73
8.2 OES demands on interoperability . 76
8.3 Rules for specification of Open-edi scenarios and scenario attributes. 76
8.4 Rules for specification of Open-edi roles and role attributes . 81
8.5 Rules for specification of Open-edi Information Bundles (IBs) and IB attributes . 90
8.6 Business requirements on FSV (business demands on Open-edi Support Infrastructure) . 97
9 Primitive Open-edi scenario template. 98
9.1 Purpose . 98
9.2 Template Structure and Content . 99
10 Requirements on Open-edi description techniques. 102
10.1 General requirements on Open-edi description techniques . 102
10.2 Requirements on OeDTs for roles. 103
10.3 Requirements on OeDTs for Information Bundles . 104
11 References . 104
© ISO/IEC 2002 – All rights reserved iii

Annex A (normative) Consolidated list of terms and definitions with cultural adaptability: ISO English
and ISO French language equivalency . 106
Annex B (normative) Codes representing presence-type attributes: mandatory, conditionals, optionals
and not applicable. 121
Annex C (informative) Unambiguous identification of entities in (electronic) business transactions . 124
Annex D (informative) Existing standards for the unambiguous identification of persons in business
transactions (organizations and individuals) and some common policy and implementation
considerations. 132
Annex E (informative) Business transaction model: person component . 152
Annex F (informative) Business transaction model: process component . 189
Annex G (informative) Business transaction model: data component . 207
Annex H (informative) Effect of classification of scenario constructs. 223
Annex I (informative) Scenario descriptions using the Open-edi scenario template:
"Telecommunications Operations Map" example . 228
Annex J (informative) Open-edi and E-commerce: areas of activities and participation. 266

iv © ISO/IEC 2002 – 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 3.
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 15944 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 15944-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 32, Data management and interchange.
ISO/IEC 15944 consists of the following parts, under the general title Information technology — Business
agreement semantic descriptive techniques:
— Part 1: Operational aspects of Open-edi for implementation
— Part 2: Registration of scenarios and their components
— Part 3: Open-edi description techniques
— Part 4: Business transaction scenarios — Accounting and economic ontology
Annexes A and B form a normative part of this part of ISO/IEC 15944. Annexes C to J are for information only.

© ISO/IEC 2002 – All rights reserved v

0 Introduction
0.1 Purpose and overview
1)
ISO/IEC 14462 Open-edi Reference Model described the conceptual architecture necessary for carrying out
Open-edi. That architecture described the need to have two separate and related views of the business activities.
The first is the Business Operational View (BOV). The second is the Functional Service View (FSV). Figure 1 from
ISO/IEC 14662 illustrates the Open-edi environment (for definitions of the terms in Figure 1 use 3.1).

B
Open-edi Reference Model
U
S
Business Operational View
I
Comply with
N
BOV RELATED
Business aspects
E Covered by
STANDARDS
of
S
business transactions
S
Viewed as
T
Inter-related
R
A
Functional Service View
N
S
Information technology
Comply with
A
FSV RELATED
aspects of
C
Covered by
STANDARDS
Business transactions
T
I
O
N
S
Figure 1 — Open-edi environment
In the BOV, the requirements that the business puts on the exchange of information are described using a
modelling technique. ISO/IEC 14462 recognized that there was no single modelling technique identified whilst the
IS was in preparation that would satisfy all of the conditions which could be identified that the FSV would need as
input. It was also recognized that business users would need a selection of modelling tools since some tools
appear to be better suited to particular types of business specifications and descriptions than others.

1) ISO/IEC 14662 Information technology - Open-edi Reference Model/Technologies de l'information - Modèle de référence
EDI-ouvert. The English and French versions of this ISO/IEC standard are publicly available. {See }
vi © ISO/IEC 2002 – All rights reserved

To provide for a situation where business users may select from a range of modelling systems, selection criteria
identifying the characteristics which any suitable modelling system must be able to support have to be defined.
These criteria can be used in two ways. One is to be able to select a suitable modelling system. Another is to
identify shortcomings in a modelling system currently in use so that the users can provide the extra information
themselves if they prefer to use that modelling system.
The BOV is used to capture the business processes from the business perspective, but there are other things that
the BOV would not capture because they are part of the operation of the Open-edi architecture itself. One example
is that a process must be able to relate to specific Information Bundles. This relationship has to be precise
because any supporting computer application has to be able to respond to the information structure that it receives
as a result of a message from another Open-edi user. Another example is the need to provide for the ability to
trigger an action because an event has not occurred (a message has been sent but no response has taken place).
Therefore it is necessary to identify those characteristics which are not expected to be captured in the BOV but are
required by computer systems developers in their work on the FSV.
The FSV is used to express the technical methods by which the parts of the business processes used in Open-edi
are developed. The FSV has to address the definition, development and lifecycle management of Information
Bundles consisting of Semantic Components, together with any rules which are essential to their management and
operation.
The FSV is a specification of the way in which the exchange of information is managed. It does not specify the
syntax used to encode or represent information that is being exchanged. The selection of a suitable syntax is left
to the EDI implementers, just as the selection of the data interchange service on which messages are sent and
received is left to networking specialists. Appropriate specialists must ensure that these syntaxes and services are
able to satisfy overarching communications requirements such as security services if these are not to be supported
through the FSV.
In summary, this standard is the first of a multi-part standard that focuses on aspects of “What to do” as opposed to
“How to do it,” as shown in Figure 2. Existing standards/tools will be used to the extent possible for the “How to.”
The second part of this standard focuses on identification, registration, referencing and re-use of scenarios, their
attributes and components. {See further 0.6}
© ISO/IEC 2002 – All rights reserved vii

WHAT TO DO
ISO/IEC 15944-2
ISO/IEC 15944-1
Registration of
scenarios and
Concepts of
OeDTs
their
scenario and its
components: components
FDTx
Business Semantic
Descriptive
Open- edi
FDTy
Techniques
Reference
UML
Model
ABSTRACT CONCRETE
ISO/IEC
Implementation
HOW TO DO IT
Figure 2 — Aspects of ISO/IEC 15944
0.2 Requirements on the business operational view aspects of Open-edi
The evolution of information and communications technologies has created a need and opportunity for different
user groups to engage in business relationships using these technologies. This requires automated methods to
carry out EDI among organizations.
Standards required for Open-edi cover a large spectrum of areas and include commercial aspects, support for
national and international laws and regulations, information technology perspectives, telecommunications and
interconnections, security service, etc. To these are added public policy requirements of a generic and horizontal
nature such as consumer protection, privacy, etc. Annex A in the ISO/IEC 14662 describes how the Open-edi
Reference Model serves as the basis for coordination of work of different standardization areas and types of
standardization for Open-edi.
In addition, the widespread adoption and use of Internet and World Wide Web (WWW)-based technologies by
organizations as well as individuals has added urgency to the need to identify and specify the key components of a
business transaction. For such specifications to be carried out as electronic business transactions supported by
automated methods of the functional support services (FSV) requires a standards-based approach for business
semantic descriptive techniques in support of the Business Operational View of Open-edi.
viii © ISO/IEC 2002 – All rights reserved

The sources of requirements on the Business Operational View (BOV) aspects which need to be integrated and/or
taken into account in the development of business descriptive techniques for Open-edi based business
2)
transactions include :
 commercial frameworks and associated requirements;
 legal frameworks and associated requirements;
 public policy requirements particularly those of a generic nature such as consumer protection, privacy, etc.;
 sectorial and cross-sectorial requirements;
 requirements arising from the need to support cultural adaptability requirements. This includes meeting
localization and multilingualism requirements, i.e., as may be required to meet requirements of a particular
3)
jurisdiction or desired for providing a good, service, and/or right in a particular market. Here distinguishing
between information technology (IT) interfaces and their multiple human interface equivalents is the
recommended approach. (For an example, see Annex B below.)
Figure 3 provides an integrated view of the business operational requirements.

2) This list of sources of requirements is a summary of Annexes A and B of ISO/IEC 14662:1997 Open-edi Reference Model;
(titles in English and French):
 Annex A (Informative) Standardization areas and types of standardization activities [ISO/IEC 14662 (E) pages 25-
29]./Annexe A (Informative) Domaines de normalisation et types d'activités de normalisation pour l'EDI-ouvert
[ISO/IEC 14662 (F) pages 26-30];

Annex B (Informative) Requirements for Open-edi standards [ISO/IEC 14662 (E) pages 30-33]/Annexe B (Informative)

Exigences portant sur les normes d'EDI-ouvert. [ISO/IEC 14662 (F) pages 31-35].
3) See further the Chapter 6 "Horizontal Aspects" (pages 22-28) of the "Report of the ISO/IEC JTC1 Business Team on
Electronic Commerce" (ISO/IEC JTC1 N5296).
© ISO/IEC 2002 – All rights reserved ix

Sources of Requirements on the Business Operational View (BOV)

aspects of Open-edi which need to be integrated and/or taken into account in

Business Transactions
Legal
Commercial
(Open-edi based)
Framework &
Framework &
Requirements
Requirements
• Characteristics of Open-edi
- Rule-Based
- Commitment Exchange
- Unambiguous Identification
- Business Transaction Model:
Key Components
Person
Information
Process
Technology
Data
Public Policy Requirements &
• Business Transaction Model:
Req’mts Standards
Classes of Constraints
(Privacy,
• Specification, Identification &
Consumer,
Classification of Open-edi
etc.)
scenarios (and components)
• FSV Business Demands on Telecom-
Open-edi Support Infrastructure munications

Req’mts &
• Open-edi Scenario Templates
Standards
(For use in various applications areas
such as: e-commerce, e-
Sectorial (&
administration, e-business, e-
Cross-Sectorial)
logistics, e-government, e-learning, e-

Req’mts
medicine etc.)
ISO & Other
Standards
Environments
Cultural Adaptability
Localization &
Multilingualism
(IT vs Human Interface)
Functional Services View (FSV)

Figure 3 — Integrated View — Business Operational Requirements
x © ISO/IEC 2002 – All rights reserved

0.3 Business operational view (BOV), Open-edi and E-commerce, E-business, etc.
The purpose of this part of the introduction is to provide users with an understanding of the relationship between
concepts/terms in this standard and concepts/terms such as “electronic commerce”, “electronic administration”,
“electronic business”, etc.
Concepts/terms such as “edi”, and now e-commerce, (and its compatriots such as e-administration,
e-business, e-government, e-logistics, e-travel, e-tailing, etc.), have a high profile among users and suppliers alike
including those working in standardization. These concepts/terms have many different meanings in various
4)
contexts and perspectives. In addition, marketing people and those seeking to raise investment funds do and will
continue to use “e-“ words in a variety of ways.
The underlying principles and characteristics of e-commerce and e-administration, e-business etc., include:
 being business transaction-based (of both a financial and non-financial nature);
 using information technology (computers and telecommunications);
5)
 interchanging electronic data involving establishment of commitments among Persons .
From a commercial, legal and standardization perspective, one can view electronic commerce as:
electronic commerce
a category of business transactions, involving two or more Persons, enacted through electronic data interchange,
based on a monetary and for profit basis. (Persons can be individuals, organizations, and/or public administrations)
Consequently, interpretations and use of the concepts/terms, “e-commerce”, “e-business”, “e-administration”, etc.,
which do not require:
1) a clearly understood purpose, mutually agreed upon goal(s), explicitness and unambiguity;
2) pre-definable set(s) of activities and/or processes, pre-definable and structured data;
3) commitments among persons being established through electronic data interchange;
4) computational integrity and related characteristics; and,
6)
5) the above being specifiable through Formal Description Techniques (FDTs) and executable through
information technology systems for use in real world actualizations;
are not considered a priority for this standard and are likely to be outside its scope.
These five requirements are essential for achieving interoperability from a BOV perspective (just as existing
computer and telecommunication standards have as a key objective interoperability from an IT perspective).

4) The ISO/IEC JTC1 Business Team on Electronic Commerce (BT-EC) in its Report to JTC1 stated (p.9)
"BT-EC recognizes that Electronic Commerce (EC) can be defined in many different ways. But rather than attempting to
provide a satisfactory definition, the Team has chosen to take a more heuristic approach to EC and to do so from a global
perspective, i.e., world-wide, cross-sectorial, multilingual, various categories of participants (including consumers)".

ISO/IEC JTC1 N5296 "Report to JTC1: Work on Electronic Commerce Standardization to be initiated". 4 May 1998, 74 p.
5) In this standard the term “party(ies)” is used in its generic context independent of roles or categories of “Person”. It assumes
that a party has the properties of a “Person”.
6) The Formal Description Technique (FDT) used in support of this standard is "Unified Modelling Language (UML). UML is
being progressed as new international standard ISO/IEC 19501 by ISO/IEC JTC1/SC7 titled "Information technology — Unified
Modeling Language (UML) — Part 1: Specification [Technologies de l'information — Langage de modélisation unifié (UML) —
Partie 1: Spécification].
© ISO/IEC 2002 – All rights reserved xi

0.4 Use of “Person”, “person”, and “party” in the context of business transactions and
commitment exchange
When the ISO/IEC 14662 Open-edi Reference Model standard was being developed, the “Internet” and “WWW”
were an embryonic stage and their impact on private and public sector organizations was not fully understood. The
Business Operational View (BOV) was therefore initially defined as:
 “a perspective of business transactions limited to those aspects regarding the making of business decisions
and commitments among organizations which are needed for the description of a business transaction”.
The existing and widely-used ISO/IEC 6523 standard definition of “organization” was used in ISO/IEC 14662. The
fact that today Open-edi through the Internet and WWW also involves “individuals” has now been taken into
account in this standard. Further, ISO/IEC 14662 did not define “commitment”, nor the discrete properties and
behaviors an entity must have to be capable of making a “commitment” as well as bridging legal and IT
perspectives in the dematerialized world of the Internet.
During the development of ISO/IEC 15944-1 the term “commitment” was defined. At the same time it was
recognized that in order to be able to make a commitment, the term Open-edi Party was not specific enough to
satisfy scenario specifications when the legal aspects of commitment were considered. In many instances
commitments were noted as being actually made between and among machines (automata or computer programs)
acting under the direction of those legally capable of making commitment, rather than the individuals in their own
capacities. It was also recognized that in some jurisdictions commitment could be made by ‘artificial’ persons such
as corporate bodies. Finally, it was recognized that there are occasions where agents act, either under the
instruction of a principal or as a result of requirement(s) laid down by a jurisdiction, or where an individual is
prevented by a relevant jurisdiction from being able to make commitment.
To address these extended requirements an additional term: Person, was defined. The construct of Person has
been defined in such a way that it is capable of having the potential legal and regulatory constraints applied to it.
The reader should understand that:
 the use of the Person with a capital “P” represents Person as a defined term in this standard, i.e., as the entity
within an Open-edi Party that carries the legal responsibility for making commitment(s);
 “individual”, “organization” and “public administration” are defined terms representing the three common sub-
types of “Person”;
 the words “person(s)” and/or “party(ies)” are used in their generic contexts independent of roles of “Person” as
defined sub-types in this standard. A “party to a business transaction” has the properties and behaviors of a
“Person”. {See further below Clause 6, and in particular 6.1.3 and 6.2}.
0.5 Organization and description of the document
This document describes the key concepts required for developing the BOV of a business transaction and
scenario. It considers how a scenario may be decomposed into functions and how the different classes of
constraints to be applied shall be identified and documented. It provides for methods of modeling processes, work
flow and information flow. This standard provides methods for identifying primitive or common components so that
there is a) high likelihood of reusability and b) ability to locate suitable components in registries. A key purpose of
this standard is to enable support of legal and regulatory requirements in business transactions.
The document provides two checklists to guide the reader through the mechanics of determining the scope of a
business transaction and determining the adequacy of the scenario definition as well as those of scenario
components. The definitions of scenarios and scenario components must be accessible to all organizations in
order to minimize resources needed to communicate between parties in a clear and unambiguous manner.
Designers must therefore ensure that scenarios and components are designed to be interoperable and re-useable.
They must also be clearly described such that a recipient can interpret them without external information.
xii © ISO/IEC 2002 – All rights reserved

This standard focuses on addressing horizontal, generic issue common to all Open-edi applications and does so
from the BOV perspective on business transactions. The diversity of sources of requirements that need to be
integrated is illustrated in Figure 3. In addition, this standard is also intended to be used by those not that familiar
with formal ISO/IEC standards.
To address these requirements and to ensure understandability and thus widespread use of this standard, a series
of informative annexes has been developed and is included. The purpose of these informative annexes is to
provide added informative and explanatory text to the normative part of this standard. They have been organized
to mirror the sequence of the clauses of the normative part. Users who have difficulty in understanding the
necessary short, explicit text of the normative part of this standard are advised to read the related informative and
explanatory text in the Annexes.
0.6 Registration aspects of Open-edi scenarios, scenario attributes and scenario components
Part 1 of the standard serves as the methodology and tool for building and defining scenarios, scenario attributes,
and scenario components. It identifies these basic or primitive components of a business transaction, provides
guidelines for scoping Open-edi scenarios as well as rules for specification of Open-edi scenarios and their
components. It consolidates these through a "Primitive Open-edi Scenario Template". {See further Clause 9}.
Registration aspects of Open-edi, including requirements, procedures, etc. are covered in Part 2 of the ISO/IEC
15944 standard titled "Information technology - Business Agreement Semantic Descriptive Techniques - Part 2:
Registration of Scenarios, Scenario Attributes and Scenario Components". Part 2 supports the registration of
scenarios, scenario attributes and scenario components as "objects". The objective of Part 2 here is the
identification, registration, referencing and re-useability of common objects in a business transaction. Re-useability
of scenarios and scenario components is an achievable objective because existing (global) business transactions,
whether conducted on a for-profit or not for profit basis, already consist of reusable components unambiguously
understood among participating parties. However, such existing "standard" components have not yet been formally
specified and registered. Part 2 fills this gap.
© ISO/IEC 2002 – All rights reserved xiii

INTERNATIONAL STANDARD ISO/IEC 15944-1:2002(E)

Information technology — Business agreement semantic
descriptive techniques —
Part 1:
Operational aspects of Open-edi for implementation
1 Scope
Integrated business operational view (BOV)
The Open-edi Reference Model (ISO/IEC 14662, Section 4) states:
"The intention is that the sending, by an Open-edi Party, of information from a scenario, conforming to Open-
edi standards, shall allow the acceptance and processing of that information in the context of that scenario by
one or more Open-edi Parties by reference to the scenario and without the need for agreement. However, the
legal requirements and/or liabilities resulting from the engagement of an organization in any Open-edi
transaction may be conditioned by the competent legal environment(s) or the formation of a legal interchange
agreement between the participating organizations. Open-edi Parties need to observe rule-based behavior and
possess the ability to make commitments in Open-edi (e.g., business, operational, technical, legal and/or audit
perspectives)."
This BOV-related standard addresses the fundamental requirements of the commercial and legal frameworks and
their environments on business transactions, and also integrates the requirements of the information technology
and telecommunications environments.
In addition to the existing strategic directions of "portability" and "interoperability", the added strategic direction of
ISO/IEC JTC1 of "cultural adaptability" is supported in this standard. This BOV standard also supports
requirements arising from the public policy/consumer environment, cross-sectorial requirements and the need to
7)
address horizontal issues. This BOV standard integrates these different sets of requirements. See above
Figure 3.
This standard allows constraints (which include legal requirements, commercial and/or international trade and
contract terms, public policy (e.g. privacy/data protection, product or service labelling, consumer protection), laws
and regulations) to be defined and clearly integrated into Open-edi through the BOV. This means that terms and
definitions in this standard serve as a common bridge among these different sets of business operational
requirements allowing the integration of code sets and rules defining these requirements to be integrated into
business processes electronically.
This standard contains a methodology and tool for specifying common business practices as parts of common
business transactions in the form of scenarios, scenario attributes, roles, Information Bundles and Semantic
Components. It achieves this by 1) developing standard computer processable specifications of common business
rules and practices as scenarios and scenario components; and thus 2) maximizing the re-use of these components
in business transactions.
7) See further on these requirements the Recommendations of the ISO/IEC JTC1 Business Team on Electronic Commerce
(BT-EC) [Ref: ISO/IEC JTC1 N5296].
© ISO/IEC 2002 – All rights reserved 1

2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 15944. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC 15944 are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC 14662:1997, Information technology — Open-edi reference model
ISO/IEC 11179-1:1999, Information technology — Specification and standardization of data elements — Part 1:
Framework for the specification and standardization of data elements
ISO/IEC 11179-3:1994, Information technology — Specification and standardization of data elements — Part 3:
Basic attributes of data elements
ISO/IEC 10181-2:1996, Information technology — Open Systems Interconnection — Security frameworks for open
systems: Authentication framework
ISO/IEC TR 13335-1:1996, Information technology — Guidelines for the management of IT Security — Part 1:
Concepts and models for IT security
ISO/IEC Directives, Part 1, Section 2.5.6, 1998
ISO/IEC Guide 2:1996, Standardization and related activities — General vocabulary
ISO/IEC 2382 (all parts), Information technology — Vocabulary
ISO/IEC 9798-1:1997, Information technology — Security techniques — Entity authentication — Part 1: General
ISO 1087 (all parts), Terminology work — Vocabulary
ISO/IEC 6523 (all parts), Information technology — Structure for the identification of organizations and organization
parts
ISO/IEC 10646-1:2000, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1:
Architecture and Basic Multilingual Plane
ISO 639-1:2001, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 639-2:1998, Codes for the representation of names of languages — Part 2: Alpha-3 code
ISO 19108, Geographic information — Temporal schema
ISO 8601:2000, Data element and interchange — Information interchange — Representation of dates and times
3 Terms and definitions
For the purposes of this part of ISO/IEC 15944, the following terms and definitions apply.
3.1
agent
a Person acting for another Person in a clearly specified capacity in the context of a business transaction
2 © ISO/IEC 2002 – All rights reserved

NOTE Excluded here are agents as "automatons" (or robots, bobots, etc.) In ISO/IEC 14662, "automatons" are recognized
and provided for but as part of the Functional Service View (FSV) where they are defined as an "Information Processing Domain
(IPD)".
3.2
Application Program Interface (API)
a boundary across which application software uses facilities of programming languages to invoke services
[ISO/IEC 14662:1997 (3.1.1)]
3.3
authentication
the provision of assurance of the claimed identity of an entity
[ISO/IEC 10181-2:1996]
3.4
authenticity
the property that ensures that the identity of a subject or resource is the one claimed. Authenticity applies to
entities such as users, processes, systems and information
[ISO/IEC TR 13335-1:1996 (3.3) monolingual (English) only]
3.5
business
a series of processes, each having a clearly understood purpose, involving more than one organization, realized
through the exchange of information and directed towards some mutually agreed upon goal, extending over a
period of time
[ISO/IEC 14662:1997 (3.1.2)]
3.6
Business Operational View (BOV)
a perspective of business transactions limited to those aspects regarding the making of business decisions and
commitments among organizations, which are needed for the description of a business transaction
[ISO/IEC 14662:1997 (3.1.3)]
3.7
business transaction
a predefined set of activities and/or processes of organizations which is initiated by an organization to accomplish
an explicitly shared business goal and terminated upon recognition of one of the agreed conclusions by all the
involved organizations although some of the recognition may be implicit
[ISO/IEC 14662:1997 (3.1.4)]
3.8
buyer
a Person who aims to get possession of a good, service, and/or right through providing an acceptable equivalent
value, usually in money, to the Person providing such a good, service, and/or right
3.9
commitment
the making or accepting of a right, obligation, liability or responsibility by a Person that is capable of enforcement in
the jurisdiction in which the commitment is made
© ISO/IEC 2002 – All rights reserved 3

3.10
consensus (standardization perspective)
general agreement, characterized by the absence of sustained opposition to substantial issues by any important
part of the concerned interests and by a process that involves seeking to take into account the views of all parties
concerned and to reconcile any conflicting arguments
NOTE Consensus need not imply unanimity. [Based on ISO/IEC Directives, Part 1, Section 2.5.6, 1998; see also ISO/IEC
Guide 2: 1996 (1.7)]
3.11
constraint
a rule, explicitly stated, that prescribes, limits, governs or specifies any aspect of a business transaction
NOTE 1 Constraints are specified as rules forming part of components of Open-edi scenarios, i.e., as scenario attributes, roles,
and/or Information Bundles.
NOTE 2 For constraints to be registered for implementation in Open-edi, they must have unique and unambiguous identifiers.
NOTE 3 A constraint may be agreed to among parties (condition of contract) and is therefore considered an "internal
constraint". Or a constraint may be imposed on parties, (e.g., laws, regulations, etc.), and is therefore considered an "external
constraint".
3.12
consumer
a buyer who is an individual to whom consumer protection requirements are applied as a set of external constraints
on a business transaction
NOTE 1 Consumer protection is a set of explicitly defined rights and obligations applicable as external constraints on a
business transaction.
NOTE 2 The assumption is that a consumer protection applies only where a buyer in a business transaction is an individual. If
this is not the case in a particular jurisdiction, such external constraints should be specified as part of scenario components as
applicable.
NOTE 3 It is recognized that external constraints on a buyer of the nature of consumer protection may be peculiar to a
specified jurisdiction.
3.13
data
a reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or
processing
NOTE Data can be processed by humans or by automatic means [ISO/IEC 2382:1993]
3.14
data (in a business transaction)
representations of recorded information that are being prepared or have been prepared in a form suitable for use in
a computer system
3.15
data element
a unit of data for which the definition, identification, representation and permissible values are specified by means
of a set of attributes
[ISO/IEC 11179-3:1994 (3.3)]
3.16
data element (in organization of data)
a unit of data that is considered in context to be indivisible
EXAMPLE The data element "age of a person" with values consisting of all combinations of 3 decimal digits.
4 © ISO/IEC 2002 – All rights reserved

NOTE Differs from the entry 17.06.02 in ISO/IEC 2382-17. [ISO/IEC 2382-04:1998 (04.07.01)]
3.17
Decision Making Application (DMA)
the model of that part of an Open-edi system that makes decisions corresponding to the role(s) that the Open-edi
Party plays, as well as originating, receiving and managing data value
...