Core Components Technical Specification 29 September 2009
Core Components Technical Specification 29 September 2009
Core Components Technical Specification 29 September 2009
Abstract
The Core Components Technical Specification defines a meta model and rules
necessary for describing the structure and contents of conceptual and logical data
models and information exchange models. The CCTS is described using the Unified
Modeling Language (UML). It does not require UML in its implementation.
Page 2 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Table of Contents
Abstract .................................................................................................... 2
Table of Contents ............................................................................................. 3
1 Status of This Document ........................................................................ 12
2 Core Components Technical Specification Project Team Participants... 13
2.1 Disclaimer....................................................................................13
2.2 Contact Information .....................................................................13
3 Introduction ............................................................................................ 14
3.1 Summary of Contents of Document ............................................14
3.1.1 Notation .......................................................................................15
3.2 Audience .....................................................................................15
3.3 Related Documents .....................................................................16
4 Objectives .............................................................................................. 17
4.1 Goals of the Technical Specification ...........................................17
4.2 Requirements ..............................................................................17
4.2.1 Conformance ...............................................................................17
4.3 Caveats and Assumptions ...........................................................17
5 Overview ................................................................................................ 18
5.1 Core Components .......................................................................18
5.1.1 Aggregate Core Component........................................................19
5.1.2 Association Core Component ......................................................20
5.1.3 Basic Core Component ...............................................................21
5.2 Core Data Types .........................................................................22
5.3 Business Information Entities ......................................................23
5.3.1 Aggregate Business Information Entity........................................24
5.3.2 Association Business Information Entity ......................................25
5.3.3 Basic Business Information Entity ...............................................27
5.4 Business Data Types...................................................................27
5.5 Relationship between ISO 11179 Data Element Concepts
and Core Components Constructs ..............................................28
5.6 Relationship between UN/CEFACT Modelling Methodology
and Core Components Constructs ..............................................29
6 Core Component Model ......................................................................... 30
6.1 Overview .....................................................................................30
6.2 Core Component Naming and Definition Conventions ................31
Page 3 of 162
UN/CEFACT CCTS V3.0 2009-09-29
6.3 Core Component Registry Class .................................................32
6.4 Core Component Common Information .......................................32
6.4.1 Core Component Dictionary Entry Names...................................32
6.4.2 Core Component Definitions .......................................................34
6.4.3 Core Component Business Terms ..............................................34
6.5 Core Component Localized Information Class ............................34
6.6 Aggregate Core Components ......................................................35
6.6.1 Aggregate Core Component Object Class Term .........................35
6.6.2 Aggregate Core Component Usage Rule ....................................36
6.6.2.1 Aggregate Core Component Usage Rule
Identification Metadata ................................................................37
6.6.2.2 Aggregate Core Component Usage Rule
Localized Metadata .....................................................................37
6.6.3 Aggregate Core Component Identifiers .......................................38
6.6.4 Aggregate Core Component Common Information .....................38
6.6.4.1 Aggregate Core Component Dictionary Entry Names .................38
6.6.4.2 Aggregate Core Component Definitions ......................................38
6.6.4.3 Aggregate Core Component Business Terms .............................39
6.6.5 Aggregate Core Component Localized Information.....................39
6.7 Aggregate Core Component Properties ......................................39
6.8 Association Core Components ....................................................40
6.8.1 Association Core Component Association Type..........................40
6.8.2 Association Core Component Usage Rule ..................................41
6.8.2.1 Association Core Component Usage Rule
Identification Metadata ................................................................41
6.8.2.2 Association Core Component Usage Rule
Localized Metadata .....................................................................42
6.8.3 Association Core Component Cardinality ....................................42
6.8.4 Association Core Component Sequencing Key ...........................42
6.8.5 Association Core Component Common Information....................43
6.8.5.1 Association Core Component Dictionary Entry Names ...............43
6.8.5.2 Association Core Component Definitions ....................................44
6.8.5.3 Association Core Component Business Terms ...........................44
6.8.6 Association Core Component Localized Information ...................44
6.9 Association Core Component Properties.....................................45
6.9.1 Association Core Component Property – Property Term.............45
6.9.2 Association Core Component Property Identifiers .......................46
Page 4 of 162
UN/CEFACT CCTS V3.0 2009-09-29
6.9.3 Association Core Component Property
Common Information ...................................................................46
6.9.3.1 Association Core Component Property
Dictionary Entry Names ...............................................................46
6.9.3.2 Association Core Component Property Definitions......................46
6.9.3.3 Association Core Component Property Business Terms .............47
6.9.4 Association Core Component Property Localized Information ....47
6.10 Basic Core Components..............................................................48
6.10.1 Basic Core Component Usage Rules ..........................................48
6.10.1.1 Basic Core Component Usage Rule Identification Metadata .......49
6.10.1.2 Basic Core Component Usage Rule Localized Metadata ............49
6.10.2 Basic Core Component Cardinality .............................................49
6.10.3 Basic Core Component Sequencing Key ....................................50
6.10.4 Basic Core Component Common Information .............................50
6.10.4.1 Basic Core Component Dictionary Entry Names .........................50
6.10.4.2 Basic Core Component Definitions..............................................51
6.10.4.3 Basic Core Component Business Terms .....................................51
6.10.5 Basic Core Component Localized Information ............................51
6.11 Basic Core Component Properties ..............................................52
6.11.1 Basic Core Component Property – Property Term ......................52
6.11.2 Basic Core Component Property Representation Term ..............53
6.11.3 Basic Core Component Property Identifiers ................................53
6.11.4 Basic Core Component Property Common Information ..............53
6.11.4.1 Basic Core Component Property Dictionary Entry Names ..........54
6.11.4.2 Basic Core Component Property Definitions ...............................54
6.11.4.3 Basic Core Component Property Business Terms ......................54
6.11.5 Basic Core Component Property Localized Information ..............54
7 Business Information Entity Model ......................................................... 56
7.1 Overview .....................................................................................56
7.2 Business Information Entity
Naming and Definition Conventions ............................................58
7.3 Business Information Entity Registry Class .................................58
7.4 Business Information Entity Common Information .......................59
7.4.1 Business Information Entity Dictionary Entry Names...................59
7.4.2 Business Information Entity Definitions .......................................61
7.4.3 Business Information Entity Business Terms ..............................61
7.5 Business Information Entity Localized Information Class ............62
Page 5 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.6 Aggregate Business Information Entities .....................................62
7.6.1 Aggregate Business Information Entity Object Class Term .........62
7.6.2 Aggregate Business Information Entity
Object Class Term Qualifier ........................................................63
7.6.3 Aggregate Business Information Entity Usage Rule ....................64
7.6.3.1 Aggregate Business Information Entity
Usage Rule Identification Metadata.............................................65
7.6.3.2 Aggregate Business Information Entity
Usage Rule Localized Metadata..................................................65
7.6.4 Aggregate Business Information Entity Identifiers .......................65
7.6.5 Aggregate Business Information Entity Common Information .....66
7.6.5.1 Aggregate Business Information Entity
Dictionary Entry Names ...............................................................66
7.6.5.2 Aggregate Business Information Entity Definitions ......................66
7.6.5.3 Aggregate Business Information Entity Business Terms .............66
7.6.6 Aggregate Business Information Entity Localized Information.....67
7.7 Aggregate Business Information Entity Properties ......................67
7.8 Association Business Information Entities ...................................68
7.8.1 Association Business Information Entity Association Type..........68
7.8.2 Association Business Information Entity Usage Rule ..................69
7.8.2.1 Association Business Information Entity
Usage Rule Identification Metadata.............................................69
7.8.2.2 Association Business Information Entity
Usage Rule Localized Metadata..................................................70
7.8.3 Association Business Information Entity Cardinality ....................70
7.8.4 Association Business Information Entity Sequencing Key ...........71
7.8.5 Association Business Information Entity Common Information ...71
7.8.5.1 Association Business Information Entity
Dictionary Entry Names ...............................................................71
7.8.5.2 Association Business Information Entity Definitions ....................72
7.8.5.3 Association Business Information Entity Business Terms ...........72
7.8.6 Association Business Information Entity Localized Information ...72
7.9 Association Business Information Entity Properties ....................73
7.9.1 Association Business Information Entity Property –
Property Term .............................................................................73
7.9.2 Association Business Information Entity Property
Qualifier Terms ............................................................................74
7.9.3 Association Business Information Entity Property Identifiers .......75
Page 6 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.9.4 Association Business Information Entity Property
Common Information ...................................................................75
7.9.4.1 Association Business Information Entity Property
Dictionary Entry Names ...............................................................75
7.9.4.2 Association Business Information Entity Property Definitions......75
7.9.4.3 Association Business Information Entity Property
Business Terms ...........................................................................76
7.9.5 Association Business Information Entity Property
Localized Information ..................................................................76
7.10 Basic Business Information Entities ............................................77
7.10.1 Basic Business Information Entity Usage Rules ..........................77
7.10.1.1 Basic Business Information Entity Usage Rule
Identification Metadata ................................................................78
7.10.1.2 Basic Business Information Entity Usage Rule
Localized Metadata .....................................................................78
7.10.2 Basic Business Information Entity Cardinality .............................79
7.10.3 Basic Business Information Entity Sequencing Key ....................79
7.10.4 Basic Business Information Entity Common Information .............79
7.10.4.1 Basic Business Information Entity Dictionary Entry Names .........80
7.10.4.2 Basic Business Information Entity Definitions ..............................80
7.10.4.3 Basic Business Information Entity Business Terms .....................80
7.10.5 Basic Business Information Entity Localized Information ............81
7.11 Basic Business Information Entity Properties ..............................81
7.11.1 Basic Business Information Entity Property – Property Term ......82
7.11.2 Basic Business Information Entity Property –
Property Term Qualifiers .............................................................82
7.11.3 Basic Business Information Entity Property
Representation Term ...................................................................83
7.11.4 Basic Business Information Entity Property Identifiers ................83
7.11.5 Basic Business Information Entity Property
Common Information ...................................................................84
7.11.5.1 Basic Business Information Entity Property
Dictionary Entry Names ...............................................................84
7.11.5.2 Basic Business Information Entity Property Definitions ...............84
7.11.5.3 Basic Business Information Entity Property Business Terms ......84
7.11.6 Basic Business Information Entity Property
Localized Information ..................................................................85
8 Data Types ............................................................................................. 86
8.1 Overview .....................................................................................87
Page 7 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.2 Data Type Naming and Definition Conventions ...........................87
8.3 Data Type Registry Class ............................................................87
8.4 Data Type Common Information .................................................88
8.4.1 Data Type Dictionary Entry Names .............................................88
8.4.2 Data Type Definitions ..................................................................89
8.4.3 Business Terms ...........................................................................89
8.5 Data Type Localized Information Class .......................................89
8.6 Core Data Types .........................................................................90
8.6.1 Core Data Type – Data Type Terms ...........................................90
8.6.2 Core Data Type Usage Rules......................................................92
8.6.2.1 Core Data Type Usage Rule Identification Metadata ..................92
8.6.2.2 Core Data Type Usage Rule Localized Metadata .......................93
8.6.3 Core Data Type Identifiers...........................................................93
8.6.4 Core Data Type Common Information .........................................93
8.6.4.1 Core Data Type Dictionary Entry Names.....................................94
8.6.4.2 Core Data Type Definitions .........................................................94
8.6.4.3 Core Data Type Business Terms ................................................94
8.6.5 Core Data Type Localized Information ........................................94
8.6.6 Core Data Type Content Component ..........................................95
8.6.6.1 Core Data Type Content Component Property Term ..................95
8.6.6.2 Core Data Type Content Component Usage Rules.....................95
8.6.6.2.1 Core Data Type Content Component
Usage Rule Identification Metadata............................................. 96
8.6.6.2.2 Core Data Type Content Component
Usage Rule Identification Metadata Localized Metadata ............. 97
8.6.6.3 Core Data Type Content Component Common Information ........97
8.6.6.3.1 Core Data Type Content Component Dictionary Entry Names .... 97
8.6.6.3.2 Core Data Type Content Component Definition .......................... 98
8.6.6.3.3 Core Data Type Content Component Business Terms ............... 98
8.6.6.4 Core Data Type Content Component Localized Information .......98
8.6.6.5 Core Data Type Content Component Core Value Domain ..........99
8.6.6.5.1 Core Data Type Content Component
Core Value Domain Primitive ...................................................... 99
8.6.6.5.2 Core Data Type Content Component
Core Value Domain Scheme or List .......................................... 101
8.6.6.5.3 Core Data Type Content Component
Core Value Domain Usage Rule ............................................... 102
Page 8 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.6.7 Core Data Type Supplementary Components ...........................104
8.6.7.1 Core Data Type Supplementary Component Property Term .....104
8.6.7.2 Core Data Type Supplementary Component
Representation Term .................................................................105
8.6.7.3 Core Data Type Supplementary Component Cardinality ...........105
8.6.7.4 Core Data Type Supplementary Component Usage Rules .......105
8.6.7.4.1 Core Data Type Supplementary Component Usage Rule
Identification Metadata .............................................................. 106
8.6.7.4.2 Core Data Type Supplementary Component Usage Rule
Identification Metadata Localized Metadata .............................. 107
8.6.7.5 Core Data Type Supplementary Component
Common Information .................................................................107
8.6.7.5.1 Core Data Type Supplementary Component
Dictionary Entry Names ............................................................. 108
8.6.7.5.2 Core Data Type Supplementary Component Definition ............. 108
8.6.7.5.3 Core Data Type Supplementary Component Business Terms .. 108
8.6.7.6 Core Data Type Supplementary Component
Localized Information ................................................................108
8.6.7.7 Core Data Type Supplementary Component
Core Value Domain ...................................................................109
8.6.7.7.1 Core Data Type Supplementary Component
Core Value Domain Primitive .................................................... 110
8.6.7.7.2 Core Data Type Supplementary Component
Core Value Domain Scheme or List .......................................... 111
8.6.7.7.3 Core Data Type Supplementary Component
Core Value Domain Usage Rule ............................................... 113
8.7 Business Data Types.................................................................115
8.7.1 Business Data Type – Data Type Term.....................................115
8.7.2 Business Data Type Qualifier Term...........................................115
8.7.3 Business Data Type Usage Rule...............................................118
8.7.3.1 Business Data Type Usage Rule Identification Metadata ..........119
8.7.3.2 Business Data Type Usage Rule Localized Metadata...............119
8.7.4 Business Data Type Identifiers ..................................................119
8.7.5 Business Data Type Common Information ................................119
8.7.5.1 Business Data Type Dictionary Entry Names ............................120
8.7.5.2 Business Data Type Definitions.................................................120
8.7.5.3 Business Data Type Business Terms ........................................120
8.7.6 Business Data Type Localized Information ...............................120
8.7.7 Business Data Type Content Component .................................121
Page 9 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.7.7.1 Business Data Type Content Component Property Term..........121
8.7.7.2 Business Data Type Content Component Usage Rules ............121
8.7.7.2.1 Business Data Type Content Component Usage Rule
Identification Metadata .............................................................. 122
8.7.7.2.2 Business Data Type Content Component Usage Rule
Identification Metadata Localized Metadata .............................. 123
8.7.7.3 Business Data Type Content Component
Common Information .................................................................123
8.7.7.3.1 Business Data Type Content Component
Dictionary Entry Names ............................................................. 124
8.7.7.3.2 Business Data Type Content Component Definition ................. 124
8.7.7.3.3 Business Data Type Content Component Business Terms ....... 124
8.7.7.4 Business Data Type Content Component
Localized Information ................................................................124
8.7.7.5 Business Data Type Content Component
Business Value Domain ............................................................125
8.7.7.5.1 Business Data Type Content Component
Business Value Domain – Domain Restrictions ........................ 126
8.7.7.5.2 Business Data Type Content Component
Business Value Domain Primitive.............................................. 127
8.7.7.5.3 Business Data Type Content Component
Business Value Domain Scheme or List.................................... 128
8.7.7.5.4 Business Data Type Content Component
Business Value Domain Usage Rule ......................................... 130
8.7.8 Business Data Type Supplementary Components ....................132
8.7.8.1 Business Data Type Supplementary Component
Property Term ...........................................................................133
8.7.8.2 Business Data Type Supplementary Component
Representation Term .................................................................133
8.7.8.3 Business Data Type Supplementary Component
Cardinality .................................................................................133
8.7.8.4 Business Data Type Supplementary Component
Usage Rules ..............................................................................134
8.7.8.4.1 Business Data Type Supplementary Component
Usage Rule Identification Metadata........................................... 135
8.7.8.4.2 Business Data Type Supplementary Component
Usage Rule Identification Metadata Localized Metadata ........... 135
8.7.8.5 Business Data Type Supplementary Component
Common Information .................................................................136
8.7.8.5.1 Business Data Type Supplementary Component
Dictionary Entry Names ............................................................. 136
Page 10 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.7.8.5.2 Business Data Type Supplementary Component Definitions .... 136
8.7.8.5.3 Business Data Type Supplementary Component
Business Terms ......................................................................... 137
8.7.8.6 Business Data Type Supplementary Component
Localized Information ................................................................137
8.7.8.7 Business Data Type Supplementary Component
Business Value Domain ............................................................138
8.7.8.7.1 Business Data Type Supplementary Component
Business Value Domain – Domain Restrictions ........................ 139
8.7.8.7.2 Business Data Type Supplementary Component
Business Value Domain Primitive.............................................. 140
8.7.8.7.3 Business Data Type Supplementary Component
Business Value Domain Business Scheme or List .................... 141
8.7.8.7.4 Business Data Type Supplementary Component
Business Value Domain Usage Rule ......................................... 143
9 Context ................................................................................................ 146
9.1 Overview ...................................................................................146
9.2 Business Context ......................................................................147
9.3 Context Values ..........................................................................147
9.4 Context Classification Scheme ..................................................147
9.5 Categories .................................................................................148
9.5.1 Business Process Context.........................................................149
9.5.2 Product Classification Context...................................................149
9.5.3 Industry Classification Context ..................................................150
9.5.4 Geopolitical Context ..................................................................150
9.5.5 Official Constraints Context .......................................................151
9.5.6 Business Process Role Context ................................................152
9.5.7 Supporting Role Context ...........................................................152
9.5.8 System Capabilities Context ......................................................152
9.6 Context Values ..........................................................................152
10 Definition of Terms ............................................................................... 153
11 References ........................................................................................... 160
12 Disclaimer ............................................................................................ 161
Copyright Statement..................................................................................... 162
Page 11 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 12 of 162
UN/CEFACT CCTS V3.0 2009-09-29
2.1 Disclaimer
The views and specification expressed in this document are those of the authors and
are not necessarily those of their employers. The authors and their employers
specifically disclaim responsibility for any problems arising from correct or incorrect
implementation or use of this technical specification.
Page 13 of 162
UN/CEFACT CCTS V3.0 2009-09-29
3 Introduction
This specification describes and specifies a semantic-based approach to the well
understood problem of the lack of information interoperability within and between
applications and data bases in the e-business arena. Traditionally, data has been
designed for specific applications and databases without regard to interoperability.
Standards for the exchange of that business data between applications and
databases have been focused on static message definitions that have not enabled a
sufficient degree of interoperability or flexibility. A more flexible and interoperable
way of standardizing business semantics has long been required.
The UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic
Business) core component solution described in this technical specification presents
just such a methodology. This Core Component Technical Specification (CCTS)
describes a revolutionary approach for developing a common set of semantic
building blocks that represent the general types of business data in use today. This
approach provides for the creation of new business vocabularies as well as
restructuring of existing business vocabularies to achieve semantic interoperability of
data.
The Abstract, Table of Contents, and Sections 1, 2, 3, 4 and 5 are informative – with
the exception of Section 4.2.1 Conformance which is normative. Sections 6, 7, 8 and
9 are normative, complementary and interdependent. Section 10 is normative.
In addition, the UN/CEFACT Forum will prepare supplemental documents that may
be used in conjunction with this specification. These supplemental documents
constitute the CCTS common methodologies standards stack and include:
Page 14 of 162
UN/CEFACT CCTS V3.0 2009-09-29
UN/CEFACT Context Methodology (UCM) –The context methodology
provides a mechanism for business driven customization of business
information entities.
Data Type Catalogue – The collection of UN/CEFACT permissible
representation terms, primitives, facets, and core data types.
UML Profile for Core Components – Defines a Unified Modeling
Language (UML) profile for expressing core components in UML
models.
Core Components Library (CCL) – represents the work of various
organizations working in a joint endeavour to develop and publish core
component artefacts.
3.1.1 Notation
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in Internet Engineering Task Force
(IETF) Request For Comments (RFC) 2119.1
[Definition] – A formal definition of a term. Definitions are normative.
[Example] – A representation of a definition or a rule. Examples are informative.
[Note] – Explanatory information. Notes are informative.
[Rn] – Identification of a rule that requires conformance to ensure discovered core
components (CCs) are properly defined, named and stored. The value R is a prefix
to categorize the type of rule where R=A for Conformance rule, R=B for BIE rule,
R=C for CC rule, R=X for Context rule, or R=D for Data Type (DT) rule. The value n
(1..n) indicates the sequential number of the rule. Rules are normative.
Italics – All words appearing in italics, when not titles or used for emphasis, are the
first occurrences of special terms defined in Section 10.
Courier – All words appearing in bolded 10 point courier font are values or
objects.
3.2 Audience
The CCTS can be employed wherever data is being defined, stored, used, shared or
exchanged. It is especially well suited for defining data models and for creating data
exchange standards for information flows amongst and between enterprises,
governmental agencies, and/or other organizations in an open, global environment.
This specification forms the basis for international cross-industry standards
development work of business analysts, business users and information technology
specialists. The user community is drawn from both business and government, to
include: data modellers, business document modellers, business process modellers,
and application developers of different organizations that require common
understanding and interoperability of information.
1
Key words for use in RFCs to Indicate Requirement Levels - Internet Engineering Task Force, Request For
Comments 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt?number=2119
Page 15 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 16 of 162
UN/CEFACT CCTS V3.0 2009-09-29
4 Objectives
4.1 Goals of the Technical Specification
The CCTS has been developed to provide for standards based semantic modelling
of business information. CCTS complements traditional data modelling techniques.
The component models produced using CCTS may form the basis for syntax specific
business information exchanges, but are independent of any specific technology
platform or implementation language.
4.2 Requirements
Users of this specification should have an understanding of basic data modelling
concepts and basic business information exchange concepts.
4.2.1 Conformance
Applications will be considered to be in full conformance with this technical
specification if they comply with the content of normative sections, rules and
definitions.
[A1] Conformance shall be determined through adherence to the content of
normative sections, rules and definitions.
Page 17 of 162
UN/CEFACT CCTS V3.0 2009-09-29
5 Overview
This Core Components Technical Specification (CCTS) provides a way to identify,
capture and maximize the re-use of business information to support and enhance
information interoperability. It focuses both on human-readable and machine-
processable representations of this information.
The CCTS approach is more flexible than current data and information exchange
standards because the semantic standardization is done in a syntax-neutral
fashion. This syntax-neutral semantic based methodology allows for the richness
inherent in natural language to be used to create data and information exchange
models that are devoid of computer-driven syntax limitations and requirements.
UN/CEFACT business process and core component solutions capture a wealth of
information about the business reasons for variation in data model and message
semantics and structure. In the past, these variations have led to incompatible
models and a subsequent lack of interoperability. The core components
mechanism will allow identification of similarities and differences between these
models.
The CCTS key concepts are based on two levels of abstraction — core
components and business information entities.
Page 18 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 19 of 162
UN/CEFACT CCTS V3.0 2009-09-29
2
UML Association – A UML association defines a relationship between classes of objects. UML associations include
AggregationKind=shared and AggregationKind=composite.
3
UML Aggregation – An aggregation is a special form of UML association that specifies a whole-part relationship
between the aggregate (whole) and a component part.
Page 20 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 21 of 162
UN/CEFACT CCTS V3.0 2009-09-29
For the CDT Amount. Type, the primitive is decimal. A CDT has a content
component and zero or more supplementary components. The CDT content
component Amount. Content carries the value of 12. This value has no meaning
on its own. But 12 EUR has a meaning: EUR represents the Euro currency and is
the value of the supplementary component Amount. Currency. Code defined for
the CDT Amount. Type. The supplementary component adds essential extra
information about the content component and gives extra meaning to the CDT
value domain.
A CDT represents the full range of values that can be used for representing an
instance of a BCC. Every CDT has a content component and zero or more
supplementary components. Every CDT content and supplementary component
has a value domain. These value domains can be expressed by either a primitive
type or a scheme or list. The value domain of the CDT is defined by the value
domain (set of permissible values) for the CDT content component (the actual
value of the data element) and the value domain of the additional constraints
expressed by the supplementary components. Supplementary components give
meaning to the value domain by adding essential extra information about the
Page 22 of 162
UN/CEFACT CCTS V3.0 2009-09-29
content component. The number of defined supplementary components varies by
CDT, and is determined by the number of attributes necessary to fully define the
value domain of the CDT.
CDTs form the bedrock for interoperability of CC’s. UN/CEFACT defines a formal
set of CDTs as part of the overall CCTS common methodology standards stack.
Other users are encouraged to adopt the UN/CEFACT Data Type Catalogue to
ensure maximum interoperability across implementations.4
Business Core
In Business Context
May Specify
ABIE Restrictions ACC
On
Aggregated Aggregated
In In
May Specify
ASBIE Restrictions ASCC
Aggregated On Aggregated
In In
Derived From Derived From
Define Define
Values of Values of
4
Approved CDTs and their corresponding data type terms, representation terms, allowed restrictions, and
supplementary components are published in the UN/CEFACT Data Type Catalogue.
Page 23 of 162
UN/CEFACT CCTS V3.0 2009-09-29
account any necessary qualification and refinement needed to support the use of
the underlying CC in the given business context.5
5.3.1 Aggregate Business Information Entity
An Aggregate Business Information Entity (ABIE) is derived from an ACC and
refines the business semantic definition for a specific business context. Just as an
ACC is the representation of an object class, so too are its derived ABIEs. An ABIE
may be qualified at the object class level, and its properties may be qualified at the
[Example] – Aggregate Business Information Entity with context driven
restrictions and qualifications
For the ABIE Trade_ Contract. Details, business context has been applied to
the ACC of Contract. Details. This context has resulted in qualification of the
object class, qualification of selected property terms, and restriction on the
content model.
property term level. The ABIE can reflect restrictions on the content model of the
ACC through:
Restrictions on the cardinality of the BCCs and ASCCs as shown in
figure 5-3.
Use and non-use of individual BCCs and ASCCs
Qualification of individual ASCC and BCC properties
Restrictions on the content model of an associated ACC for an
ASCC
Restrictions on the data type of the BCC
Restrictions on the concept or conceptual domain of the ASCC or
BCC property as reflected in the definition and usage rules.
BIE cardinality does not define how many BIEs may be derived from a basis CC.
Rather it describes the allowed occurrences of a specific BIE. For example, If a
BCC or ASCC has the cardinality [0..1], the derived BBIE or ASBIE may have the
same cardinality [0..1], or it may have a restricted cardinality of [1..1]. If a BCC or
ASCC has the cardinality [0..*], the derived BBIE or ASBIE may have the same
cardinality [0..*], or it may have a restricted minimum occurrence or maximum
occurrence.
5
The Core Components’ Context mechanism provides the more detailed linkage between specific business
data and the exact circumstances of its business use.
Page 24 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 25 of 162
UN/CEFACT CCTS V3.0 2009-09-29
• no complex properties
The ABIE Trade_ Contract. Details has:
• two simple properties:
• Identification. Identifier
• Issue. Date Time
6
Composition – A composition is a strong form of aggregation association that requires that the component
part only belongs to a single parent object, and only exists as long as that parent object exists.
Page 26 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Every BBIE property is derived from a BCC property. Like their BCC property
counterparts, BBIE properties are reusable across object classes. However, once it
has been given the object class of a parent ABIE, it becomes a BBIE that is unique
to the object class to which it is assigned. Each BBIE property has a Business Data
Type (BDT) that describes its value domain. BBIE BDTs are derived from the CDT
of the BCC.
Page 27 of 162
UN/CEFACT CCTS V3.0 2009-09-29
component or supplementary components. Additional business data types may
also be created that include restrictions of the set of values of its basis CDT’s
content component and/or supplementary component(s). The restrictions represent
a qualification of the BDT similar to the qualification of BIEs. Both the content
component and supplementary component(s) have allowed component restrictions
that provide all information necessary to understand the value domain for a specific
BBIE.
Example – Business Data Type with BDT Content Component and BDT
Supplementary Component Restrictions
The qualified BDT Price_ Amount. Type is derived from the BDT Amount. Type
which is derived from the CDT Amount. Type.
For the BDT Price_ Amount. Type, the primitive is decimal. The BDT qualifier
Price semantically conveys the data type value domain restrictions being
applied to the basis BDT Amount. Type for its specific use as the value domain
for a type of payment.
The BDT has both BDT content and BDT supplementary components.
In the example, the BDT content component Amount. Content carries the value
of 12. The allowed value range for the content component has been restricted
using the BDT content component restriction Decimal Fractional Digits = 0.
In the example, the BDT Amount. Currency. Code supplementary component
carries the value EUR, where EUR represents the Euro currency. The BDT
Amount. Currency. Code supplementary component has been restricted using
the enumeration component restriction to allowed values USD or EUR.
In addition to allowed component restrictions, BDTs may restrict the content model
(only use a subset) of the allowed supplementary components from its basis CDT.
Restricted BDTs may be further restricted in hierarchical fashion through additional,
more restrictive, content and/or supplementary component restrictions.
Page 28 of 162
UN/CEFACT CCTS V3.0 2009-09-29
11179, these generic data elements are reusable across object classes, and inherit
the name of the object class in which they occur. Similarly, in CCTS, these
properties are reusable to create BCCs or BBIEs in multiple ACCs and ABIEs.
However, once a property is used to create a BCC or BBIE, to include refinements
to the value domain at the BBIE level, the BCC or BBIE creates an unchangeable
part of the ACC or ABIE to which it belongs. This concept has been extended in
CCTS to include ASCC and ASBIE properties as well.
7
The UN/CEFACT Modelling Methodology (UMM) is a methodology for modelling collaborative Business
Processes that is based on the Object Management Group’s Unified Modelling Language.
Page 29 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Registry Class
+ Unique Identifier
+ Version Identifier
«abstract»
Core Component (CC)
«abstract»
Aggregate Core Component (ACC)
ACCProperty
+ Object ClassTerm Localized Information
1..* + Cardinality
+ Sequencing Key
+ Language Code
1 + Other Language Business Term [0..*]
+ Other Language Definition
0..* + Other Language DEN[0..1]
Usage Rule Basic Core Component (BCC) 0..*
0..*
+ Condition Type 1
+ Constraint
+ Constraint Type 0..* Common Information
+ Unique Identifier + Business Term [0..*]
+ Definition
0..*
1 + Dictionary Entry Name (DEN)
6.1 Overview
A core component is a building block for the development of a semantically correct
and meaningful business information exchange ‘parcel’ containing the information
pieces needed to describe a specific concept.
[Definition] – Core Component (CC)
A core component is a semantic building block for creating clear and meaningful
data models, vocabularies, and information exchange packages. Core components
are used as the basis for creating business information entities.
There are five categories of Core Components (CCs):
Page 30 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Aggregate Core Component (ACC)
Association Core Component (ASCC)
Basic Core Component (BCC), and
ASCC Property
BCC Property
[C1] A CC shall be an ACC, ASCC, BCC, ASCC property, or BCC property.
[Note] – ACC Property
An ACC property is a generalization of a BCC or an ASCC, and not a property in its
own right.
ACCs, ASCCs, BCCs, ASCC properties, and BCC properties are collectively called
CCs and are typically stored in a registry, database, or other mechanism to
maximize their reuse.
8
Implementers are encouraged to use the UN/CEFACT controlled vocabulary as the authoritative source for
terms and definitions.
Page 31 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 32 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Object Class Term: a part of the dictionary entry name of a
component which represents the object class to which it belongs.
Property Term: represents a distinguishing characteristic of the object
class and shall occur naturally in the definition.
Representation Term: an element of the component name which
describes the form in which the component is represented.
[C1] All terms used in CC DENs shall be in the English language following the
latest version of the Oxford English Dictionary. Where conflicting spellings
exist, the spelling listed as the primary British spelling shall be used.
[Note] – Oxford English Dictionary
Users may choose to utilize any version of the Oxford English Dictionary to create
the spelling and definitions of CCs; however the complete Oxford English Dictionary
will be the authoritative source for conflict resolution between competing spellings of
component names or definitions.
[C4] A CC DEN shall be unique amongst all DENs within the library of which it is a
part.
[C5] A CC DEN shall be extracted from the CC definition.
[C6] A CC DEN shall not include consecutive identical words or terms.
[C7] A CC DEN and all its components shall be in singular form unless the concept
itself is plural.
[C8] A CC DEN shall only use alphabetic characters plus the dot and space
characters.
[C9] A CC DEN shall only contain verbs, nouns, adverbs and adjectives unless a
different part of speech is part of an official title, part of a term listed in the
Oxford English Dictionary, or part of a controlled vocabulary.
[Note] – Parts of Speech
Articles, prepositions and related parts of speech that are not verbs, nouns, adverbs
and adjectives normally add no semantic clarity and should not be used unless as
part of an official title or in a controlled vocabulary as part of a common business
term that cannot otherwise be expressed.
Page 33 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C13] Each word in a CC DEN shall start with a capital letter.
[C14] The dots after CC object class and property terms shall be followed by a
space character.
[C15] Each CC DEN shall remain unique when its separators are removed.
6.4.2 Core Component Definitions
CC definitions are based on the requirements for data element definitions defined in
ISO 11179-4.
[C16] Each CC shall have its own unique semantic definition within the library of
which it is a part.
[Note] – Order of Development of Definition and DEN
In the interest of quality, it is recommended that the CC definition be developed first
and the DEN extracted from it.
[C17] The CC definition shall be in the English language following the latest version
of the Oxford English Dictionary. Where conflicting spellings exist, the spelling
listed as the primary British spelling shall be used.
[C18] The CC definition shall be consistent with the requirements of ISO 11179-4.
[C19] The CC definition shall take into account the fact that the users of the CC
library are not necessarily native English speakers. It shall therefore contain
short sentences, using common terms. Wherever alternative terms exist for a
word in the definition, the definition shall use the preferred term as identified
in the Oxford English Dictionary or a controlled vocabulary if one exists.
[Example] – Use of Synonym Terms
ACC – Contract Line Item. Details
Definition – A contract line item is a distinct, separately defined line item
specified in a contract.
Alternative terms for distinct include distinctive and distinguishable. The term
distinct is a more easily understood common term for differentiating a
contract line item amongst a group of line items.
[C20] Whenever both the definite (i.e. the) and indefinite article (i.e. a) are possible
in a definition, preference shall be given to an indefinite article (i.e. a).
[Note] – Definition Quality
To verify the quality of the definition, place the DEN followed by the word is before
the definition to ensure that it is not simply a repetition of the DEN.
Page 34 of 162
UN/CEFACT CCTS V3.0 2009-09-29
definitions and business terms. The CC localized information class contains the
relevant information necessary to associate the native language expressions to their
normative English language counterparts. Other language CC DENs will only consist
of alphabetic, ideographic characters, plus the dot, the underscore and the space
characters unless required by language rules. In addition to other language DEN,
definition, and business term(s), a mandatory language code identifies the language
in which the components are being expressed for storage in the registry. The
localized information class contains:
Language Code: A code which identifies the language being used.
Tags for the Identification of Languages, Internet Engineering Task
Force (IETF) RFC 3066 of January 2001 will be used as the
authoritative source for code values.
Dictionary Entry Name: The official name of the component in a
language other than English.
Definition: the semantic meaning of the component in a language
other than English.
Business Term: A synonym term in another language under which
the component is commonly known and used in a business expression
in that language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language and locale code. The business terms must
only be expressed in the language identified by the language and locale code, or a
recognized dialect of the language.
Page 35 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Currency Exchange. Details does not represent the same thing as Exchange.
Details
Thus the term Currency Exchange represents a different object than either
Currency or Exchange.
Page 36 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 37 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C36] ACC usage rule localized metadata shall be in the language identified by the
language and locale code.
6.6.3 Aggregate Core Component Identifiers
Every ACC is a registry class. In order to ensure uniqueness, every ACC will have
assigned a:
Unique Identifier: The identifier that references an ACC in a unique
and unambiguous way.
Version Identifier: An indication of the evolution over time of an ACC.
[C37] Each ACC shall have a unique identifier within the library of which it is a part.
[C38] Each version of an ACC shall have a unique version identifier within the
library of which it is a part.
6.6.4 Aggregate Core Component Common Information
[C39] Each ACC shall have a common information class.
[C40] The ACC common information class shall conform to all CC common
information rules.
[C41] The ACC common information class shall consist of:
DEN (mandatory): The official name of the ACC.
Definition (mandatory): The semantic meaning of the ACC.
Business Term (optional, repetitive): A synonym term under which
the ACC is commonly known and used in business.
[Example] – ACC Common Information
DEN – Contract. Details
Definition – A contract is an agreement between two or more parties, especially
one that is written or spoken and enforceable by law.
Business Term – Purchasing Agreement
Page 38 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 39 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C53] An ACC shall contain at least one ACC property.
[C54] An ACC property shall be either a BCC or an ASCC.
[Definition] – ACC Property
An aggregate core component property is a unique property of the aggregate core
component that must be related to the concept of the aggregate core component.
An aggregate core component property is either an association core component or
a basic core component.
[C55] Within an ACC, all embedded BCCs and ASCCs shall be related to the
concept of the aggregate.
ACC properties must be unique within the ACC.
[C56] An ASCC DEN and a BCC DEN shall never be identical when used in an
ACC.
An ACC property that is an ASCC must be devoid of mandatory circular references.
[C57] An ACC shall never contain – directly or at any nested level – a mandatory
ASCC whose associated ACC is the same as the top level ACC.
[Note] – Recursion
The objective of the above rule is to prevent endless nesting in component models.
The rule does not prevent an ACC containing an ASCC reference to itself. However,
it must be optional, making it possible to stop the nesting at a finite number of levels.
Page 40 of 162
UN/CEFACT CCTS V3.0 2009-09-29
6.8.2 Association Core Component Usage Rule
ASCCs may have usage rules. Each usage rule defines a constraint that describes
specific conditions that are applicable to the ASCC. ASCC usage rules clarify (or
constrain) the use of an ASCC as an ACC property. ASCC usage rules can be either
unstructured – expressed as free form text, or structured – expressed in a formal
language.
[C59] An ASCC shall have zero or more usage rules.
Usage rules will be applied at the lowest possible level of the hierarchical structure to
which they apply.
[C60] ASCC usage rules shall not replicate ACC, BCC, or CDT usage rules.
[C61] An ASCC usage rule shall have an identifier that is unique amongst all usage
rules for the library of which it is a part.
[Note] – Usage Rule Identifier Structure
There are no specific rules for the structure of usage rule identifiers. Implementers
are free to choose any structure providing it guarantees uniqueness within the group
of usage rules of a library.
The ASCC usage rule constraint is the formal expression of the usage rule. The
constraint can be structured or unstructured. An unstructured constraint will be
expressed as free form text.
[C62] An unstructured ASCC usage rule constraint shall have a free form text
expression that fully details the usage rule.
A structured constraint is a constraint that is expressed in a formal constraint
language such as the UML OCL or OMG SBVR.
[C63] A structured ASCC usage rule constraint shall have a formal constraint
language expression.
ASCC usage rule constraint types must also be specified. The constraint type value
is taken from a formal constraint type code list.
[C64] Every ASCC usage rule shall have a constraint type taken from a constraint
type code list.
[Note] – Constraint Type Code List
UN/CEFACT will publish and make freely available a Constraint Type Code List for
use in support of this rule.
ASCC usage rules expressed as formal constraints will also have a condition type
that identifies when the constraint should be applied.
[C65] Every ASCC usage rule shall have a condition type
[C66] Every ASCC usage rule condition type shall be one of pre-condition, post-
condition, or invariant.
Page 41 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C67] An ASCC usage rule shall have zero or one identification metadata classes.
The ASCC usage rule identification metadata may contain a unique name that
semantically differentiates the usage rule from all other named usage rules for the
ASCC.
[C68] An ASCC usage rule shall have zero or one names that is unique within the
group of usage rules of an ACC.
The ASCC usage rule identification metadata may contain several business terms.
ASCC usage rule business terms are synonym terms under which the ASCC usage
rule is commonly known and used in business.
[C69] Each ASCC usage rule shall have zero or more business terms.
6.8.2.2 Association Core Component Usage Rule Localized Metadata
ASCC usage rules may have localized metadata that is used to provide other
language expressions of its name and business term or terms.
[C70] An ASCC usage rule shall have zero or more localized metadata classes.
[C71] Each occurrence of an ASCC usage rule localized metadata class shall
contain:
Language Code (mandatory): A code which identifies the language
being used. Tags for the Identification of Languages, Internet
Engineering Task Force RFC 3066 of January 2001 shall be used as
the authoritative source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[C72] ASCC usage rule localized metadata shall be in the language identified by the
language and locale code.
6.8.3 Association Core Component Cardinality
Each ASCC, in its role as an ACC property, will have its cardinality explicitly
expressed.
[C73] Each ASCC shall have a cardinality that consists of a set of values consisting
of a minimum occurrence and a maximum occurrence.
[C74] ASCC cardinality values shall be non-negative integers of zero or greater, or
– only in the case of maximum occurrence – the token unbounded if no limit
applies.
6.8.4 Association Core Component Sequencing Key
Software and storage applications may have unique sequencing algorithms that
change the normatively defined order of the ASCC within an ACC. To ensure the
desired order is preserved, each ASCC within an ACC will be assigned a unique
sequencing key only for the aspects of presentation.
Page 42 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 43 of 162
UN/CEFACT CCTS V3.0 2009-09-29
6.8.5.2 Association Core Component Definitions
[C81] Each ASCC definition shall conform to all CC definition rules.
[C82] The definition of an ASCC shall include the object class term of the
associating ACC, and the definition of the ASCC property the ASCC includes.
[Example] – ASCC Definition
Contract. Effective. Period
A period within which the provisions of this contract are, or will be, in force or
effective. It constitutes a specific period of time such as the length of time
between two known date/time points, from a start date onwards, or up to an end
date that constitutes an effective period.
Where the ASCC Property
Effective. Period definition is:
A specific period of time such as the length of time between two known date/time
points, from a start date onwards, or up to an end date that constitutes an
effective period.
Page 44 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C87] Each ASCC localized information definition shall adhere to all ASCC definition
rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[C88] Each ASCC localized information DEN and definition shall be in the language
identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[C89] Each ASCC localized information business term shall be in the language
identified by the language and locale code, or a recognized dialect of the
language.
Trade Line Item. Additional Information. Note is not the same as Trade
Line Item. Additional. Note
Trade Line Item. Additional Information. Note is not the same as Trade
Line Item. Information. Note
Trade Line Item. Additional Information. Note is not the same as Trade
Line Item. Information Additional. Note
Page 45 of 162
UN/CEFACT CCTS V3.0 2009-09-29
6.9.2 Association Core Component Property Identifiers
Every ASCC property is a registry class. In order to ensure uniqueness, every ASCC
property will have assigned a:
Unique Identifier: The identifier that references an ASCC property in
a unique and unambiguous way.
Version Identifier: An indication of the evolution over time of an
ASCC property.
[C94] Each ASCC property shall have a unique identifier within the library of which it
is a part.
[C95] Each version of an ASCC property shall have a unique version identifier
within the library of which it is a part.
6.9.3 Association Core Component Property Common Information
[C96] Each ASCC property shall have a common information class.
[C97] The ASCC property common information class shall conform to all CC
common information rules.
[C98] The ASCC property common information class shall consist of:
DEN (mandatory): The official name of the ASCC property.
Definition (mandatory): The semantic meaning of the ASCC
property.
Business Term (optional, repetitive): A synonym term under which
the ASCC property is commonly known and used in business.
[Example] – ASCC Property Common Information
DEN – Effective. Period
Definition – A specific period of time such as the length of time between two
known date/time points, from a start date onwards, or up to an end date that
constitutes an effective period.
Business Term – Effective Duration, In Force Period.
Page 46 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 47 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C109] Each ASCC property localized information business term shall be in the
language identified by the language and locale code, or a recognized dialect
of the language.
Page 48 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 49 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C124] Each BCC shall have a cardinality that consists of a set of values consisting
of a minimum occurrence and a maximum occurrence.
[C125] BCC cardinality values shall be non-negative integers of zero or greater, or –
only in the case of maximum occurrence – the token unbounded if no limit
applies.
6.10.3 Basic Core Component Sequencing Key
Business requirements may exist for BCCs to occur in a specific order within an
ACC. Software and storage applications may have unique sequencing algorithms
that change the normatively defined order of the BCC within an ACC. To ensure the
desired order is preserved, each BCC within an ACC will be assigned a unique
sequencing key.
[Note] – Sequencing Key
The sequence of ASCCs and BCCs can be interwoven in the content model of an
ACC, thus sequencing keys of the ASCCs and BCCs within an ACC are inter-
dependent. Each identifies the sequence of the individual ASCC or BCC within the
overall content model of the ACC.
[C126] Each BCC shall be assigned a unique sequencing key within the ACC of
which it is a part.
Note – Sequencing Key Structure
There are no specific rules for the structure of the sequencing keys. Implementers
are free to choose any structure providing it guarantees uniqueness within the ACC
to which it belongs and the structuring scheme is readily available for anyone
accessing or using the ACC.
Page 50 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C131] The DEN of a BCC shall consist of the following parts in the order specified:
the object class term of the owning ACC, followed by a dot and space
character.
the DEN of the included BCC property.
Example – BCCs
Period. Start. Date Time; Contract. Price. Amount
The date, time, date time or other date time value for the start of this period of
time.
Page 51 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[C138] Each BCC localized information definition shall adhere to all BCC definition
rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[C139] Each BCC localized information DEN and definition shall be in the language
identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[C140] Each BCC localized information business term shall be in the language
identified by the language and locale code, or a recognized dialect of the
language.
Page 52 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 53 of 162
UN/CEFACT CCTS V3.0 2009-09-29
A date, time, date time or other date time value that marks the start or initiation
of an event.
Page 54 of 162
UN/CEFACT CCTS V3.0 2009-09-29
DEN (optional): The official name of the BCC property in a language
other than English.
Definition (mandatory): The semantic meaning of the BCC property
in a language other than English.
Business Term (optional, repetitive): A synonym term in another
language under which the BCC property is commonly known and used
in a business expression in that language.
BCC property localized information DENs should follow, as much as possible, all
BCC property DEN rules.
[C163] Each BCC property localized information DEN shall only consist of alphabetic
characters, ideographic characters, plus the dot, the underscore and the
space characters unless required by language rules.
[C164] Each BCC property localized information definition shall adhere to all BCC
definition rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[C165] Each BCC property localized information DEN and definition shall be in the
language identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[C166] Each BCC property localized information business term shall be in the
language identified by the language and locale code, or a recognized dialect
of the language.
Page 55 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Registry Class
+ Unique Identifier
«abstract» 1 + Version Identifier
Business Information Entity (BIE) Business Context
Usage Rule 1
0..1
0..*
0..*
0..* 1 1 0..*
Figure 7-1. UML Diagram of Business Information Entity Basic Definition Model
7.1 Overview
Business information entities represent the real world application of core
components for a specific context of use. BIEs are used to create logical models that
may be implemented as a data model or in a specific syntax as document models for
business information exchanges. A BIE is a context specific instantiation of a
conceptual core component. A BIE will be part of a package within a library. The
package represents a set of BIEs being used in a specific context and tailored to
meet the unique requirements for the package. BIEs are semantically unique within a
package, but may be semantically similar in name and definition to, albeit with a
different content model than, BIEs in other packages.
Page 56 of 162
UN/CEFACT CCTS V3.0 2009-09-29
1 Business Context
+basis
«abstract» «abstract»
Business Information Entity (BIE) Core Component (CC)
+basis
«abstract» «abstract»
ABIE Property 0..* 1 ACCProperty
1..* 1..*
+basis
Aggregate BusinessInformation Aggregate Core Component
Entity (ABIE) 0..* 1 (ACC)
1 1
0..* 0..*
+basis
ASBIE Property ASCCProperty
0..* 1
1 1
0..* 0..*
+basis
Association BusinessInformation Association Core Component
Entity (ASBIE) 0..* 1 (ASCC)
+basis
Basic BusinessInformation Entity
Basic Core Component (BCC)
(BBIE) 0..* 1
0..*
0..*
1 1
+basis
BBIE Property BCC Property
0..* 1
0..* 0..*
1 1
+basis
BusinessData Type (BDT) Core Data Type (CDT)
1..* 1
Figure 7-2. UML Diagram of Relationship Between Business Information Entities and
Core Components
[Note] – Figure 7-2
For completeness, figure 7-2 includes CDTs and BDTs (See Section 8).
Just as with ACCs, there are five categories of BIEs:
Aggregate Business Information Entity (ABIE). An ABIE is based on
an (has one and only one basis) ACC.
Association Business Information Entity (ASBIE). An ASBIE is based
on an (has one and only one basis) ASCC.
Basic Business Information Entity (BBIE). A BBIE is based on a (has
one and only one basis) BCC.
Page 57 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Association Business Information Entity Property. An ASBIE property
is based on an (has one and only one basis) ASCC property.
Basic Business Information Entity Property. A BBIE property is based
on a (has only one basis) BCC property.
[B1] A BIE shall be an ABIE, ASBIE, BBIE, ASBIE property or a BBIE property.
[B2] A BIE shall be defined by one or more individual business context category
values that together constitute a unique business context.
[Definition] – Business Context
Business context is the formal description of a specific business circumstance as
identified by the values of a set of context categories, allowing different business
circumstances to be uniquely distinguished.
ABIEs, ASBIEs, BBIEs, ASBIE properties, and BBIE properties are collectively called
BIEs and are typically stored in a registry, database, or other mechanism to
maximize reuse.
Page 58 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 59 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Where the Office Of Surface Mining is a formal title that contains the
preposition Of, and removal of the preposition would identify a different
organization; and Free On Board Value where Free On Board is a recognized
expression and removal of the preposition On would change the semantic
meaning of the property term.
[B11] Abbreviations and acronyms that are part of the BIE DEN shall be expanded
or explained in the definition.
[B12] BIE DEN object class terms, property terms, and representation terms shall
be separated by dots.
[B13] The space character shall separate words in multi-worded BIE object class,
property, and representation terms.
[B14] Each word in a BIE DEN shall start with a capital letter.
[B15] The dots after BIE object class and property terms shall be followed by a
space character.
[B16] Each BIE DEN shall remain unique when its separators are removed.
[B17] Multi-worded object classes and property terms shall be used in lieu of
qualifier terms when the concept the multi worded object class or property
term represents exists in three or more dissimilar business domains.
Page 60 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B18] The order of qualifier terms shall have semantic meaning.
[Example] – Qualifier Order
The BBIE Electronic_ Trade_ Contract. Issue. Date Time has a different
semantic meaning than Trade_ Electronic_ Contract. Issue. Date Time.
[B19] Qualifier terms shall reflect the semantic restriction of the object class or
property term that they are used with.
[Example] – Semantic Restrictions
Trade_ Contract. Details semantically restricts Contract. Details. The
qualifier term of Trade is allowed even though it also may exist as a separate
object class, property term, or representation term.
Page 61 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 62 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B27] An ABIE object class term shall be identical to its basis ACC object class
term.
7.6.2 Aggregate Business Information Entity Object Class Term Qualifier
The ABIE object class term qualifier is a word or words which help define and
differentiate an ABIE from its associated CC and other BIEs. The ABIE object class
term qualifier enhances the semantic meaning of the ABIE DEN to reflect a
restriction to the BIE concept, conceptual domain, content model or data value. ABIE
object class terms can have one or more qualifier terms.
[B28] A qualified ABIE shall be a restriction of its basis ACC or its higher level ABIE
in an ABIE hierarchy.
[Example] – Multi-qualified ABIEs
The Multi-qualified ABIE
Electronic_ Trade_ Contract. Details
[B29] ABIE object class qualifier terms shall precede the object class term.
[B30] Each ABIE object class qualifier term shall be followed by an underscore and
a space character (_ ).
[B31] A multi-worded object class qualifier term shall have a unique semantic
meaning compared to the words separately.
[B32] A qualifying ABIE hierarchy shall be established when multiple qualifiers are
used.
Note – BIE Hierarchy
A BIE hierarchy is a tree like structure that reflects the order of the qualifiers for a set
of qualified BIEs derived from the same unqualified BIE in a graph like form. The first
level in a BIE hierarchy is the unqualified BIE construct, and each succeeding lower
level is a more qualified BIE construct than its preceding BIE construct.
Page 63 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B33] A qualified object class name shall be unique amongst the set of qualified
object class names in the library of which it is a part.
[B34] A qualified object class name may be applied in its entirety as a qualifier for
another object class to convey a semantic relationship between the objects
providing the qualifier hierarchy is preserved.
7.6.3 Aggregate Business Information Entity Usage Rule
ABIEs may have usage rules. Each usage rule defines a constraint that describes
specific conditions that are applicable to the ABIE. ABIE usage rules represent the
specific application of an ABIE in its role as an object class. ABIE usage rules can be
either unstructured – expressed as free form text, or structured – expressed in a
formal language.
[B35] An ABIE shall have zero or more usage rules.
Usage rules will be applied at the lowest possible level of the hierarchical structure to
which they apply.
[B36] ABIE usage rules shall not replicate BBIE, ASBIE, or BDT usage rules.
[B37] An ABIE usage rule shall have an identifier that is unique amongst all usage
rules for the library of which it is a part.
[Note] – Usage Rule Identifier Structure
There are no specific rules for the structure of usage rule identifiers. Implementers
are free to choose any structure providing it guarantees uniqueness within the group
of usage rules of a library.
The ABIE usage rule constraint is the formal expression of the usage rule. The
constraint can be structured or unstructured. An unstructured constraint will be
expressed as free form text.
[B38] An unstructured ABIE usage rule constraint shall have a free form text
expression that fully details the usage rule.
A structured constraint is a constraint that is expressed in a formal language such as
the UML OCL or OMG SBVR.
[B39] A structured ABIE usage rule shall have a formal constraint language
expression.
ABIE usage rule constraint types must also be specified. The constraint type value is
taken from a constraint type code list.
[B40] Every ABIE usage rule shall have a formal constraint type taken from a
constraint type code list.
[Note] – Constraint Type Code List
UN/CEFACT will publish and make freely available a Constraint Type Code List for
use in support of this rule.
ABIE usage rules will also have a condition type that identifies when the constraint
should be applied.
[B41] Every ABIE usage rule shall have a condition type.
[B42] Every ABIE usage rule condition type shall be one of pre-condition, post-
condition, or invariant.
Page 64 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.6.3.1 Aggregate Business Information Entity Usage Rule Identification Metadata
Although the unique identifier is sufficient to differentiate one usage rule for a given
ABIE from all other usage rules in a library, an ABIE usage rule may also have an
identification metadata class that provides additional information.
[B43] An ABIE usage rule shall have zero or one identification metadata classes.
The ABIE usage rule identification metadata may contain a unique name that
semantically differentiates the usage rule from all other named usage rules for the
ABIE.
[B44] An ABIE usage rule shall have zero or one names that is unique within the
group of usage rules of an ABIE.
The ABIE usage rule identification metadata may contain business terms. ABIE
usage rule business terms are synonym terms under which the ABIE usage rule is
commonly known and used in business.
[B45] Each ABIE usage rule shall have zero or more business terms.
7.6.3.2 Aggregate Business Information Entity Usage Rule Localized Metadata
ABIE usage rules may have localized metadata that is used to provide other
language expressions of its name and business term or terms.
[B46] An ABIE usage rule shall have zero or more localized metadata classes.
[B47] Each occurrence of an ABIE usage rule localized metadata class shall
contain:
Language Code (mandatory): A code which identifies the language
being used. Tags for the Identification of Languages, Internet
Engineering Task Force RFC 3066 of January 2001 shall be used as
the authoritative source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[B48] ABIE usage rule localized metadata shall be in the language identified by the
language and locale code.
7.6.4 Aggregate Business Information Entity Identifiers
Every ABIE is a registry class. In order to ensure uniqueness, every ABIE will have
assigned a:
Unique Identifier: The identifier that references an ABIE in a unique
and unambiguous way.
Version Identifier: An indication of the evolution over time of an
ABIE.
[B49] Each ABIE shall have a unique identifier within the library of which it is a part.
[B50] Each version of an ABIE shall have a unique version identifier within the
library of which it is a part.
Page 65 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.6.5 Aggregate Business Information Entity Common Information
[B51] Each ABIE shall have a common information class.
[B52] The ABIE common information class shall conform to all BIE common
information rules.
[B53] The ABIE common information class shall consist of:
DEN (mandatory): The official name of the ABIE.
Definition (mandatory): The semantic meaning of the ABIE.
Business Term (optional, repetitive): A synonym term under which
the ABIE is commonly known and used in business.
[Example] – ABIE Common Information
DEN – Trade_ Contract. Details
Definition – A trade contract is a contractual agreement between two or more
parties for trade purposes.
Business Term – Service Agreement
[B58] An ABIE with an unqualified object class shall have the same definition as the
ACC the ABIE is based on.
[B59] An ABIE with a qualified object class term shall have a definition that
semantically restricts the definition of the less qualified ABIE or ACC that the
ABIE is based on.
7.6.5.3 Aggregate Business Information Entity Business Terms
An ABIE may have several business terms. ABIE business terms are synonym terms
under which the ABIE is commonly known and used in business.
[B60] Each ABIE shall have zero or more business terms.
Page 66 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.6.6 Aggregate Business Information Entity Localized Information
The ABIE localized information class contains the relevant information necessary to
associate native language expressions of ABIE attributes to the ABIE.
[B61] Each ABIE shall have zero or more localized information classes.
[B62] Each occurrence of an ABIE localized information class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
DEN (optional): The official name of the ABIE in a language other
than English.
Definition (mandatory): The semantic meaning of the ABIE in a
language other than English.
Business Term (optional, repetitive): A synonym term in another
language under which the ABIE is commonly known and used in a
business expression in that language.
ABIE localized information DENs should follow, as much as possible, all ABIE DEN
rules.
[B63] Each ABIE localized information DEN shall only consist of alphabetic
characters, ideographic characters, plus the dot, the underscore and the
space characters unless required by language rules.
[B64] Each ABIE localized information definition shall adhere to all ABIE and
definition rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[B65] Each ABIE localized information DEN and definition shall be in the language
identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[B66] Each ABIE localized information business term shall be in the language
identified by the language and code.
Page 67 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Because an ABIE is an independent class, it is important that all listed properties are
in fact conceptually related to the concept of the BIE, and not just added for
convenience.
[B70] Within an ABIE, all embedded BBIEs and ASBIEs shall be related to the
concept of the aggregate.
ABIE properties must be unique within the ABIE.
[B71] An ASBIE DEN and a BBIE DEN shall never be identical when used in an
ABIE.
An ABIE property that is an ASBIE must be devoid of mandatory circular references.
[B72] An ABIE shall never contain – directly or at any nested level – a mandatory
ASBIE whose associated ABIE is the same as the top level ABIE.
[Note] – Recursion
The objective of the above rule is to avoid endless loops in the content model of an
ABIE. The rule allows an ABIE to contain an ASBIE property that references itself.
The fact that the ASBIE property is not mandatory makes it possible to stop the loop
after a finite number of iterations.
Page 68 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.8.2 Association Business Information Entity Usage Rule
ASBIEs may have usage rules. Each usage rule defines a constraint that describes
specific conditions that are applicable to the ASBIE. ASBIE usage rules clarify (or
constrain) the use of an ASBIE as an ABIE property. ASBIE usage rules can be
either unstructured – expressed as free form text, or structured – expressed in a
formal language.
[B75] An ASBIE shall have zero or more usage rules.
Usage rules will be applied at the lowest possible level of the hierarchical structure to
which they apply.
[B76] ASBIE usage rules shall not replicate ABIE, BBIE, or BDT usage rules.
[B77] An ASBIE usage rule shall have an identifier that is unique amongst all usage
rules for the library of which it is a part.
[Note] – Usage Rule Identifier Structure
There are no specific rules for the structure of usage rule identifiers. Implementers
are free to choose any structure providing it guarantees uniqueness within the group
of usage rules of a library.
The ASBIE usage rule constraint is the formal expression of the usage rule. The
constraint can be structured or unstructured. An unstructured constraint will be
expressed as free form text.
[B78] An unstructured ASBIE usage rule constraint shall have a free form text
expression that fully details the usage rule.
A structured constraint is a constraint that is expressed in a formal language such as
the UML OCL or OMG SBVR.
[B79] A structured ASBIE usage rule constraint shall have a formal constraint
language expression.
ASBIE usage rule constraint types must also be specified. The constraint type value
is taken from a constraint type code list.
[B80] Every ASBIE usage rule shall have a constraint type taken from a constraint
type code list.
[Note] – Constraint Type Code List
UN/CEFACT will publish and make freely available a Constraint Type Code List for
use in support of this rule.
ASBIE usage rules will also a have condition type that identifies when the constraint
should be applied.
[B81] Every ASBIE usage rule shall have a condition type.
[B82] Every ASBIE usage rule condition type shall be one of pre-condition, post-
condition, or invariant.
Page 69 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B83] An ASBIE usage rule shall have zero or one identification metadata classes.
The usage rule identification metadata may contain a unique name that semantically
differentiates it from all other named usage rules for the ASBIE.
[B84] An ASBIE usage rule shall have zero or one names that is unique within the
group of usage rules of an ASBIE.
The ASBIE usage rule metadata may contain business terms. ASBIE usage rule
business terms are synonym terms under which the ASBIE usage rule is commonly
known and used in business.
[B85] Each ASBIE usage rule shall have zero or more business terms.
7.8.2.2 Association Business Information Entity Usage Rule Localized Metadata
ASBIE usage rules may have localized metadata that is used to provide other
language expressions of its name and business term or terms.
[B86] An ASBIE usage rule shall have zero or more localized metadata classes.
[B87] Each occurrence of an ASBIE usage rule localized metadata class shall
contain:
Language Code (mandatory): A code which identifies the language
being used. Tags for the Identification of Languages, Internet
Engineering Task Force RFC 3066 of January 2001 shall be used as
the authoritative source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[B88] ASBIE usage rule localized metadata shall be in the language identified by
the language and locale code.
7.8.3 Association Business Information Entity Cardinality
Each ASBIE, in its role as an ABIE property, will have its cardinality explicitly
expressed.
[B89] Each ASBIE shall have a cardinality that consists of a set of values consisting
of a minimum occurrence and a maximum occurrence.
[B90] ASBIE cardinality values shall be non-negative integers of zero or greater, or
– only in case of maximum occurrence – the token unbounded if no limit
applies.
The ASBIE minimum occurrence will never be smaller than the ASCC minimum
occurrence and the ASBIE maximum occurrence will never be larger than the ASCC
maximum occurrence.
[B91] ASBIE cardinality values shall never be an extension of its basis ASCC
cardinality values.
Page 70 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.8.4 Association Business Information Entity Sequencing Key
Business requirements may exist for ASBIEs to occur in a specific order within an
ABIE. Software and storage applications may have unique sequencing algorithms
that change the normatively defined order of the ASBIE within an ABIE. To ensure
the desired order is preserved, each ASBIE within an ABIE will be assigned a unique
sequencing key.
[Note] – Sequencing Key
The sequence of ASBIEs and BBIEs can be interwoven in the content model of an
ABIE, thus sequencing keys of the ASBIEs and BBIEs within an ABIE are inter-
dependent. Each identifies the sequence of the individual ASBIE or BBIE within the
overall content model of the ABIE.
[B92] Each ASBIE shall be assigned a unique sequencing key within the ABIE of
which it is a part.
[Note] – Sequencing Key Structure
There are no specific rules for the structure of the sequencing keys. Implementers
are free to choose any structure providing it guarantees uniqueness within the ABIE
to which it belongs and the structuring scheme is readily available for anyone
accessing or using the ABIE.
Since ASBIEs represent contextualized expressions of their basis ASCCs, the
sequencing requirements of an ASBIE in an ABIE might be different from the
sequencing key of the corresponding ASCC in an ACC.
[B93] An ASBIE sequencing key may be different from its corresponding ASCC
sequencing key.
7.8.5 Association Business Information Entity Common Information
In its role as an ABIE property, each ASBIE has a common information class.
[B94] Each ASBIE shall have a common information class.
[B95] The ASBIE common information class shall conform to all BIE common
information rules.
[B96] The ASBIE common information class shall consist of:
DEN (mandatory): The official name of the ASBIE.
Definition (mandatory): The semantic meaning of the ASBIE.
Business Term (optional, repetitive): A synonym term under which
the ASBIE is commonly known and used in business.
[Example] – ASBIE Common Information
DEN – Trade_ Contract. Effective. Measurement_ Period
Definition – A period within which the measurement of provisions of this trade
contract are, or will be effective.
Page 71 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B98] The DEN of an ASBIE shall consist of the following components in the
specified order:
the object class term and qualifiers, if any, of the associating BIE,
the DEN of the included ASBIE property.
[Example] – Association Business Information Entity DEN
Trade_ Contract. Effective. Measurement_ Period
Where the associated ABIE Measurement_ Period. Details now becomes part
of a property in the associating ABIE of Trade_ Contract. Details and the
property term (nature of that association) is Effective.
Page 72 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B105] Each ASBIE localized information definition shall adhere to all ASBIE
definition rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[B106] Each localized information ASBIE DEN and definition shall be in the language
identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[B107] Each ASBIE localized information business term shall be in the language
identified by the language and locale code, or a recognized dialect of the
language.
Page 73 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B115] ASBIE property qualifier terms shall precede the property term.
[B116] Each ASBIE property qualifier term shall be followed by an underscore and a
space character (_ ).
[B117] A multi-worded ASBIE property qualifier term shall have a unique semantic
meaning compared to the words separately.
[B118] A qualifying ASBIE property hierarchy shall be established when multiple
qualifiers are used.
Page 74 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B119] A qualified property term of an ASBIE property DEN may be applied in its
entirety as a qualifier for another property term to convey a semantic
relationship between the objects providing the qualifier hierarchy is preserved.
7.9.3 Association Business Information Entity Property Identifiers
Every ASBIE property is a registry class. In order to ensure uniqueness, every
ASBIE property will have assigned a:
Unique Identifier: The identifier that references an ASBIE property in
a unique and unambiguous way.
Version Identifier: An indication of the evolution over time of an
ASBIE property.
[B120] Each ASBIE property shall have a unique identifier within the library of which
it is a part.
[B121] Each version of an ASBIE property shall have a unique version identifier
within the library of which it is a part.
7.9.4 Association Business Information Entity Property Common Information
[B122] Each ASBIE property shall have a common information class.
[B123] The ASBIE property common information class shall conform to all BIE
common information rules.
[B124] The ASBIE property common information class shall consist of:
DEN (mandatory): The official name of the ASBIE property.
Definition (mandatory): The semantic meaning of the ASBIE
property.
Business Term (optional, repetitive): A synonym term under which
the ASBIE property is commonly known and used in business.
[Example] – ASBIE Property Common Information
DEN – Effective. Measurement_ Period
Definition – A period within which the measurement of provisions are, or will be
effective.
Page 75 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Where the associated object class term period, and its qualifier Measurement,
and property term Effective are included in the definition.
[B129] An ASBIE property with a qualified property term shall have a definition that
semantically restricts the definition of the less qualified ASBIE property or the
ASCC property that the ASBIE property is based on.
7.9.4.3 Association Business Information Entity Property Business Terms
An ASBIE property may have several business terms. ASBIE property business
terms are synonym terms under which the ASBIE property is commonly known and
used in business.
[B130] Each ASBIE property shall have zero or more business terms.
7.9.5 Association Business Information Entity Property Localized Information
The ASBIE property localized information class contains the relevant information
necessary to associate native language expressions of ASBIE property attributes to
the ASBIE property.
[B131] An ASBIE property shall have zero or more localized information classes.
[B132] Each occurrence of an ASBIE property localized information class shall
contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
DEN (optional): The official name of the ASBIE property in a
language other than English.
Definition (mandatory): The semantic meaning of the ASBIE
property in a language other than English.
Business Term (optional, repetitive): A synonym term in another
language under which the ASBIE property is commonly known and
used in a business expression in that language.
ASBIE localized information DENs should follow, as much as possible, all ASBIE
property DEN rules.
[B133] Each ASBIE property localized information DEN shall only consist of
alphabetic characters, ideographic characters, plus the dot, the underscore
and the space characters unless required by language rules.
[B134] Each ASBIE localized information property definition shall adhere to all ASBIE
property definition rules other than the requirement to be in the English
language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
Page 76 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B135] Each ASBIE property localized information DEN and definition shall be in the
language identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[B136] Each ASBIE property localized information business term shall be expressed
in the language identified by the language and locale code, or a recognized
dialect of the language.
Page 77 of 162
UN/CEFACT CCTS V3.0 2009-09-29
BBIE usage rule constraint types must also be specified. The constraint type value is
taken from a constraint type code list.
[B143] Every BBIE usage rule shall have a constraint type taken from a constraint
type code list.
[Note] – Constraint Type Code List
UN/CEFACT will publish and make freely available a Constraint Type Code List for
use in support of this rule.
BBIE usage rules will also have a condition type that identifies when the constraint
should be applied.
[B144] Every BBIE usage rule shall have a condition type.
[B145] Every BBIE usage rule condition type shall be one of pre-condition, post-
condition, or invariant.
Page 78 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.10.2 Basic Business Information Entity Cardinality
Each BBIE, in its role as an ABIE property, will have its cardinality explicitly
expressed.
[B152] Each BBIE shall have a cardinality that consists of a set of values consisting
of a minimum occurrence and a maximum occurrence.
[B153] BBIE cardinality values shall be non-negative integers of zero or greater, or –
only in the case of maximum occurrence – the token unbounded if no limit
applies.
[B154] BBIE cardinality values shall never be an extension of its basis BCC
cardinality values.
The BBIE minimum occurrence will never be smaller than the BCC minimum
occurrence and the maximum occurrence will never be larger than the BCC
maximum occurrence.
7.10.3 Basic Business Information Entity Sequencing Key
Business requirements may exist for BBIEs to occur in a specific order within an
ABIE. Software and storage applications may have unique sequencing algorithms
that change the normatively defined order of the BBIE within an ABIE. To ensure the
desired order is preserved, each BBIE within an ABIE will be assigned a unique
sequencing key.
[Note] – Sequencing Key
The sequence of ASBIEs and BBIEs can be interwoven in the content model of an
ABIE, thus sequencing keys of the ASBIEs and BBIEs within an ABIE are inter-
dependent. Each identifies the sequence of the individual ASBIE or BBIE within the
overall content model of the ABIE.
[B155] Each BBIE shall be assigned a unique sequencing key within the ABIE of
which it is a part.
[Note] – Sequencing Key Structure
There are no specific rules for the structure of the sequencing keys. Implementers
are free to choose any structure providing it guarantees uniqueness within the ACC
to which it belongs and the structuring scheme is readily available for anyone
accessing or using the ACC.
Since BBIEs represent contextualized expressions of their basis BCCs, the
sequencing requirements of a BBIE in an ABIE might be different than the
sequencing key of the corresponding BCC in an ACC.
[B156] A BBIE sequencing key may be different than its corresponding BCC
sequencing key.
7.10.4 Basic Business Information Entity Common Information
In its role as an ABIE property, each BBIE has a common information class.
[B157] Each BBIE shall have a common information class.
[B158] The BBIE common information class shall conform to all BIE common
information rules.
[B159] The BBIE common information class shall consist of:
Page 79 of 162
UN/CEFACT CCTS V3.0 2009-09-29
DEN (mandatory): The official name of the BBIE.
Definition (mandatory): The semantic meaning of the BBIE.
Business Term (optional, repetitive): A synonym term under which
the BBIE is commonly known and used in business.
[Example] – Common Information
DEN – Trade_ Contract. Total_ Price. Amount
Definition – The monetary amount of the total price of this trade contract.
Business Term – Service Agreement Total Price; Amount Owed
Definition – The monetary amount of the total price of this trade contract.
Where the object class term and qualifier Trade_ Contract, property term and
qualifier Total_ Price, and representation term Amount are in the definition.
Page 80 of 162
UN/CEFACT CCTS V3.0 2009-09-29
7.10.5 Basic Business Information Entity Localized Information
The BBIE localized information class contains the relevant information necessary to
associate native language expressions of BBIE attributes to the BBIE.
[B167] A BBIE shall have zero or more localized information classes.
[B168] Each occurrence of a BBIE localized information class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
DEN (optional): The official name of the BBIE in a language other
than English.
Definition (mandatory): The semantic meaning of the BBIE in a
language other than English.
Business Term (optional, repetitive): A synonym term in another
language under which the BBIE is commonly known and used in a
business expression in that language.
BBIE localized information DENs should follow, as much as possible, all BBIE DEN
rules.
[B169] Each BBIE localized information DEN shall only consist of alphabetic
characters, ideographic characters, plus the dot, the underscore and the
space characters unless required by language rules.
[B170] Each BBIE localized information definition shall adhere to all BBIE definition
rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[B171] Each BBIE localized information DEN and definition shall be in the language
identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[B172] Each BBIE localized information business term shall be in the language
identified by the language and locale code, or a recognized dialect of the
language.
Page 81 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 82 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B181] Each BBIE property qualifier term shall be followed by an underscore and a
space character (_ ).
[B182] A multi-worded BBIE property qualifier term shall have a unique semantic
meaning compared to the words separately.
[B183] A BBIE property hierarchy shall be established when multiple qualifiers are
used.
[B184] A qualified property term of a BBIE property DEN may be applied in its
entirety as a qualifier for another property term to convey a semantic
relationship between the objects providing the qualifier hierarchy is preserved.
7.11.3 Basic Business Information Entity Property Representation Term
Each BBIE property contains a representation term. The representation term is a
semantically meaningful name that represents the value domain of the BBIE property
and its associated BDT. UN/CEFACT defines the approved representation terms as
part of the UN/CEFACT Data Type Catalogue.
If the BDT of a BBIE property is qualified, the data type qualifier should be used as
part of the BBIE object class, object class qualifier term(s), or the property term
and/or property term qualifier term(s) of the BBIE property.
[B185] A representation term shall be defined for each BBIE property.
[B186] The name of the BBIE property representation term may consist of more than
one word.
[B187] A multi-worded BBIE property representation term shall have a unique
semantic meaning compared to the words separately and compared to any
other combination of these words.
[B188] The name of the BBIE property representation term shall be one of the
approved representation terms in the UN/CEFACT Data Type Catalogue.
The BDT or qualified BDT will be of the same CDT as the basis BCC property.
[B189] A BBIE property shall have a BDT that is based on the CDT of the basis BCC
property.
7.11.4 Basic Business Information Entity Property Identifiers
In order to ensure uniqueness, every BBIE property will have assigned a:
Unique Identifier (mandatory): The identifier that references the
BBIE property in a unique and unambiguous way.
Version Identifier (mandatory): An indication of the evolution over
time of the BBIE property.
[B190] Each BBIE property shall have a unique identifier within the library of which it
is a part.
Page 83 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B191] Each version of a BBIE property shall have a unique version identifier within
the library of which it is a part.
7.11.5 Basic Business Information Entity Property Common Information
[B192] Each BBIE property shall have a common information class.
[B193] The BBIE property common information class shall conform to all BIE
common information rules.
[B194] The BBIE property common information class shall consist of:
DEN (mandatory): The official name of the BBIE property.
Definition (mandatory): The semantic meaning of the BBIE property.
Business Term (optional, repetitive): A synonym term under which
the BBIE property is commonly known and used in business.
[Example] – BBIE Property Common Information
DEN – Total_ Price. Amount
Definition – A monetary amount of a total price
Business Term – Price; Amount Owed
Page 84 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[B200] Each BBIE property shall have zero or more business terms.
7.11.6 Basic Business Information Entity Property Localized Information
The BBIE property localized information class contains the relevant information
necessary to associate native language expressions of BBIE property attributes to
the BBIE property.
[B201] A BBIE property shall have zero or more localized information classes.
[B202] Each occurrence of a BBIE property localized information class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
DEN (optional): The official name of the BBIE property in a language
other than English.
Definition (mandatory): The semantic meaning of the BBIE property
in a language other than English.
Business Term (optional, repetitive): A synonym term in another
language under which the BBIE property is commonly known and
used in a business expression in that language.
BBIE property localized information DENs should follow, as much as possible, all
BBIE property DEN rules.
[B203] Each BBIE property localized information DEN shall only consist of alphabetic
characters, ideographic characters, plus the dot, the underscore and the
space characters unless required by language rules.
[B204] Each BBIE property localized information definition shall adhere to all BBIE
definition rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[B205] Each BBIE property localized information DEN and definition shall be in the
language identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[B206] Each BBIE property localized information business term shall be in the
language identified by the language and locale code, or a recognized dialect
of the language.
Page 85 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8 Data Types
This section provides a detailed technical explanation of CCTS data types. The
abstract UML diagram shown in figure 8-1 represents a generic data type (DT)
metamodel that is used by both the CDT and BDT metamodels.
«Invariant»
{Only BDTshave
qualifiers, not CDTs.}
«abstract» «abstract»
DT Content Component DT Supplementary Component
0..1
0..*
1..* 1..* 1 1 1
1..* 1
0..*
0..* 0..* 0..*
0..1
«abstract» 0..1
Scheme Or List
Identification Metadata
+ Agency Identifier
+ Identifier + BusinessTerm [0..*]
+ Modification Allowed Indicator: Boolean + Name [0..1]
+ Version Identifier
0..*
1..*
Page 86 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.1 Overview
A data type defines the value domain – set of valid values – that can be used for a
particular BCC property or BBIE property.
There are two categories of data Types (DTs)
Core Data Type (CDT)
Business Data Type (BDT)
[D1] A data type shall be a CDT or BDT.
Page 87 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 88 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[D12] Each word in a DT DEN shall start with a capital letter.
[D13] The dots after DT terms shall be followed by a space character.
8.4.2 Data Type Definitions
Data Type definitions are based on the requirements for data element definitions
defined in ISO 11179-4.
[D14] Each DT shall have its own unique semantic definition within the library of
which it is a part.
[Note] – Order of Development of Definition and DEN
In the interest of quality, it is recommended that the definition be developed first and
the DEN extracted from it.
[D15] The definition shall be in the English language following the latest version of
the Oxford English Dictionary. Where conflicting spellings exist, the spelling
listed as the primary British spelling shall be used.
[D16] The definition shall be consistent with the requirements of ISO 11179-4 and
will provide an understandable meaning, which should also be translatable to
other languages.
[D17] The definition shall take into account the fact that the users of the DT library
are not necessarily native English speakers. It shall therefore contain short
sentences, using normal words. Wherever synonym terms are possible, the
definition shall use the preferred term as identified in the controlled
vocabulary.
[D18] Whenever both the definite (i.e. the) and indefinite article (i.e. a) are possible
in a definition, preference shall be given to an indefinite article
(i.e. a).
[Note] – Definition Quality
To verify the quality of the definition, place the DEN followed by the word is before
the definition to ensure that it is not simply a repetition of the DEN.
Page 89 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Language Code: A code which identifies the language being used.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 will be used as the authoritative
source for code values.
DEN: The official name of the DT in a language other than English.
Definition: The semantic meaning of the DT in a language other than
English.
Business Term: A synonym term in another language under which
the DT is commonly known and used in a business expression in that
language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language and locale code. The business terms must
only be expressed in the language identified by the language and locale code, or a
recognized dialect of the language.
Page 90 of 162
UN/CEFACT CCTS V3.0 2009-09-29
«invariant»
{A CDT Content
Component must not
have a default value.}
1
0..*
0..* 0..*
+ Cardinality
+ Property Term 0..*
+ Representation Term
Primitive
+ Description
+ Name 0..1
+ Primitive Type
1..*
0..* 0..* 1..*
0..*
«Invariant»
0..1
{Core Value Domain
must have either a
«abstract»
Primitive or a "Core
Core Scheme Or List
0..1 Scheme Or List", but
+ Agency Identifier not both.}
Identification Metadata + Identifier
+ Modification Allowed Indicator: Boolean
+ BusinessTerm [0..*] + Version Identifier
+ Name [0..1]
0..*
1..*
Page 91 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.6.2 Core Data Type Usage Rules
CDTs may have usage rules. Each usage rule defines a constraint that describes
specific conditions that are applicable to the CDT. CDT usage rules represent the
specific application of a CDT in its role of expressing the value domain of BCCs and
BCC properties. CDT usage rules can be either unstructured – expressed as free
form text, or structured – expressed in a formal language.
[D25] A CDT shall have zero or more usage rules.
CDT usage rules may be reused by other DT artefacts. However, usage rules will be
applied at the lowest possible level of the hierarchical structure to which they apply.
[D26] CDT usage rules shall not replicate CDT content component, CDT
supplementary component, or CDT core value domain usage rules.
[D27] A CDT usage rule shall have an identifier that is unique amongst all usage
rules for the library of which it is a part.
[Note] – Usage Rule Identifier Structure
There are no specific rules for the structure of usage rule identifiers. Implementers
are free to choose any structure providing it guarantees uniqueness within the group
of usage rules of a library.
The CDT usage rule constraint is the formal expression of the usage rule. The
constraint can be structured or unstructured. An unstructured constraint will be
expressed as free form text.
[D28] An unstructured CDT usage rule constraint shall have a free form text
expression that fully details the usage rule.
A structured constraint is a constraint that is expressed in a formal constraint
language such as the UML OCL or OMG SBVR.
[D29] A structured CDT usage rule constraint shall have a formal constraint
language expression.
CDT usage rule constraint types must also be specified. The constraint type value is
taken from a constraint type code list.
[D30] Every CDT usage rule shall have a constraint type taken from a constraint
type code list.
[Note] – Constraint Type Code List
UN/CEFACT will publish and make freely available a Constraint Type Code List for
use in support of this rule.
CDT usage rules will also have a condition type that identifies when the constraint
should be applied.
[D31] Every CDT usage rule shall have a condition type.
[D32] Every CDT usage rule condition type shall be one of pre-condition, post-
condition, or invariant.
Page 92 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[D33] A CDT usage rule shall have zero or one identification metadata classes.
The CDT usage rule identification metadata may contain a unique name that
semantically differentiates the usage rule from all other named usage rules for the
CDT.
[D34] A CDT usage rule shall have zero or one names that is unique within the
group of usage rules of a CDT.
CDT usage rule identification metadata may contain business terms. CDT usage rule
business terms are synonym terms under which the usage rule is commonly known
and used in business.
[D35] Each CDT usage rule shall have zero or more business terms.
8.6.2.2 Core Data Type Usage Rule Localized Metadata
CDT usage rules may have localized metadata that is used to provide other
language expressions of its name and business term or terms.
[D36] A CDT usage rule shall have zero or more localized metadata classes.
[D37] Each occurrence of a CDT usage rule localized metadata class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[D38] CDT usage rule localized metadata shall be in the language identified by the
language and locale code.
8.6.3 Core Data Type Identifiers
In order to ensure uniqueness, every CDT will have assigned a:
Unique Identifier (mandatory): The identifier that references the CDT
in a unique and unambiguous way.
Version Identifier (mandatory): An indication of the evolution over
time of the CDT.
[D39] Each CDT shall have a unique identifier within the library of which it is a part.
[D40] Each version of a CDT shall have a unique version identifier within the library
of which it is a part.
8.6.4 Core Data Type Common Information
[D41] Each CDT shall have a common information class.
[D42] The CDT common information class shall consist of:
DEN (mandatory): The official name of the CDT.
Definition (mandatory): The semantic meaning of the CDT.
Page 93 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Business Term (optional, repetitive): A synonym term under which
the CDT is commonly known and used in business.
[Example] – CDT Common Information
DEN – Amount. Type
Definition – An amount is a number of monetary units specified in a currency
Business Term – Total Money; Sum of Money; Price; Monetary Value
Page 94 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[D50] Each CDT localized information DEN shall only consist of alphabetic
characters, ideographic characters, plus the dot, the underscore and the
space characters unless required by language rules.
[D51] Each CDT localized information definition shall adhere to all CDT definition
rules other than the requirement to be in the English language.
The DEN and definition in the localized information class must only be expressed in
the language identified by the language code property of that class.
[D52] Each CDT localized information DEN and definition shall be in the language
identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[D53] Each CDT localized information language business term shall be in the
language identified by the language and locale code, or a recognized dialect
of the language.
8.6.6 Core Data Type Content Component
CDT content components are defined in the UN/CEFACT Data Type Catalogue and
are unique to the CDT to which they are assigned.
[D54] A CDT shall have one and only one CDT content component.
[D55] A CDT content component shall be the specified CDT content component as
defined in the UN/CEFACT Data Type Catalogue.
8.6.6.1 Core Data Type Content Component Property Term
The CDT content component property term represents the actual content of a data
element. The CDT content component property term has a fixed value of content.
[D56] Each CDT content component shall have a property term.
[D57] The CDT content component property term shall have a fixed value of
Content.
Page 95 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.6.6.2.1 Core Data Type Content Component Usage Rule Identification Metadata
Although the unique identifier is sufficient to differentiate one usage rule in a given
library from all other usage rules in a library, a CDT content component usage rule
may also have an identification metadata class that provides additional information.
[D66] A CDT content component usage rule shall have zero or one identification
metadata classes.
The CDT content component usage rule identification metadata may contain a
unique name that semantically differentiates it from all other named usage rules for
the CDT content component.
[D67] A CDT content component usage rule shall have zero or one names that is
unique within the group of usage rules of a CDT content component.
A CDT content component usage rule metadata may contain business terms. CDT
content component usage rule business terms are synonym terms under which the
usage rule is commonly known and used in business.
[D68] Each CDT content component usage rule shall have zero or more business
terms.
Page 96 of 162
UN/CEFACT CCTS V3.0 2009-09-29
8.6.6.2.2 Core Data Type Content Component Usage Rule Identification Metadata
Localized Metadata
CDT content component usage rules may have localized metadata that is used to
provide other language expressions of its name and business term or terms.
[D69] A CDT content component usage rule shall have zero or more localized
metadata classes.
[D70] Each occurrence of a CDT content component usage rule localized metadata
class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[D71] CDT content component usage rule localized metadata shall be in the
language identified by the language and locale code.
8.6.6.3 Core Data Type Content Component Common Information
Each CDT content component has a common information class.
[D72] Each CDT content component shall have a common information class.
[D73] The CDT content component common information class shall consist of:
DEN (mandatory): The official name of a CDT content component.
Definition (mandatory): The semantic meaning of a CDT content
component.
Business Term (optional, repetitive): A synonym term under which
the CDT content component is commonly known and used in
business.
[Example] – CDT Content Component Common Information
DEN – Amount. Content
Definition – An amount is a number of monetary units
Business Term – Money
Page 97 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Page 98 of 162
UN/CEFACT CCTS V3.0 2009-09-29
[D83] Each CDT content component localized information DEN and definition shall
be in the language identified by the language and locale code.
The business terms must only be expressed in the language identified by the
language code property of that class, or a recognized dialect of the language.
[D84] Each CDT content component localized information business term shall be in
the language identified by the language and locale code, or a recognized
dialect of the language.
8.6.6.5 Core Data Type Content Component Core Value Domain
CDT content components can have one or more value domains. A CDT content
component core value domain is an abstract class that defines the set of allowed
values through the presence of either a scheme or list, or a primitive with defined
facets and their restrictions.
[D85] A CDT content component shall have one or more value domains.
Since each CDT content component may have multiple value domains, each defined
value domain contains a default indicator that identifies if it is the default value
domain amongst the set of value domains for the CDT content component.
[D86] A CDT content component core value domain shall have a default indicator
whose value = true if it is the default value domain.
[D87] A CDT content component core value domain shall have a default indicator
whose value = false if it is not the default value domain.
Each CDT content component core value domain may also have a default value.
This default value represents a CDT content component core value domain value
that is to be automatically applied to the CDT content component in the absence of a
choice made by the user. The default value should be used unless an alternate is
required to meet specific business purposes.
[D88] A CDT content component core value domain shall have zero or one default
values.
Default values will be conformant to the defined primitive or scheme or list of the
CDT content component core value domain.
[D89] The CDT content component core value domain default value shall be
conformant to its defined primitive or scheme or list.
CDT content component core value domains are defined by either a primitive or a
scheme or list. Each primitive or scheme or list constitutes a separate core value
domain for the CDT content component.
[D90] Each CDT content component core value domain shall consist of a primitive
or a scheme or list.
8.6.6.5.1 Core Data Type Content Component Core Value Domain Primitive
Primitives represent basic building blocks for defining value domains of content and
supplementary components. Each CDT content component core value domain can
have zero or one primitives defined for it. The CDT content component core value
domain primitive defines the value domain. Primitives are referred to as primitive
types.
Primitives include, but are not limited to:
Page 99 of 162
UN/CEFACT CCTS V3.0 2009-09-29
Binary
Boolean
Decimal
Double
Float
Integer
Normalized String
String
Time Duration
Time Point
Token
[D91] Each CDT content component core value domain shall have zero or one
primitives.
[D92] A CDT content component core value domain primitive shall be one of the
defined primitives in the UN/CEFACT Data Type Catalogue.
Each primitive has a primitive type.
[D93] Every CDT content component core value domain primitive shall have a
primitive type taken from the UN/CEFACT Data Type Catalogue.
Each primitive has a formal name. This name typically represents the nature of the
value domain it represents.
[D94] Every CDT content component core value domain primitive shall have a
primitive name.
[D95] Every CDT content component core value domain primitive name shall be
unique within the set of primitives of CDTs.
A CDT content component core value domain primitive will also have a description
that semantically defines its value domain.
[D96] Each CDT content component core value domain primitive shall have a
description that semantically defines its value domain.
8.6.6.5.1.1 Core Data Type Content Component Core Value Domain Primitive Facet
The value domains expressed by primitives are quantified through their facets. A
primitive may have zero or more facets. Each facet defines or constrains an aspect
of the value domain expressed by the primitive.
[D97] Each CDT content component core value domain primitive shall have zero or
more facets.
Each facet shall have a facet type.
[D98] Each CDT content component core value domain primitive facet shall be one
of the defined primitive facets in the UN/CEFACT Data Type Catalogue.
[D99] Each CDT content component core value domain primitive facet shall have a
name that is unique amongst the set of facet names of a primitive.
8.6.6.5.2 Core Data Type Content Component Core Value Domain Scheme or List
Schemes are the equivalent of a pattern facet. A scheme formally expresses the
pattern and the allowed values for populating that pattern in the form of identifiers.
Lists are the equivalent of enumerated lists and are typically published as formal
code lists. The set of codes in a formal code list is used by core value domains as an
enumerated set of allowed values.
Unambiguous identification of the scheme or list is necessary.
[D101] Every CDT content component core value domain scheme or list shall have
an identifier.
A version identifier serves to differentiate one version of a scheme or list from all
other versions of the scheme or list.
[D102] Every CDT content component core value domain scheme or list shall have a
version identifier.
Every scheme or list will be owned by an organization. The organization is identified
by a unique identifier.
[D103] Every CDT content component core value domain scheme or list shall have
an agency identifier.
[Note] – Agency Identifier
UN/CEFACT recommends using UN/CEFACT Code List Responsible Agency Code
(Data Element 3055) in the latest version of the UN/CEFACT directory.
Business data types are able to place restrictions on schemes and lists. If such
restrictions are undesirable, then this will be indicated through the use of a required
modification allowed indicator.
[D104] Every CDT content component core value domain scheme or list shall have a
modification allowed indicator whose value = true if modifications are
allowed, or whose value = false if modifications are not allowed.
8.6.6.5.2.1 Core Data Type Content Component Core Value Domain Core Identifier
Scheme
Identifier schemes are typically not enumerated, rather the scheme defines a regular
expression or pattern that is used to populate its set of values and also used to
validate values. No additional rules are provided regarding the content of identifier
schemes. However, at a minimum, an identifier scheme should define a specific
pattern for the values of the identifiers to conform to.
8.6.6.5.2.2 Core Data Type Content Component Core Value Domain Core Code List
Core data type content component core value domain core code lists contain lists of
enumerated core code values and optional core code names and core code
definitions.
[D105] Each CDT content component core value domain core code list shall contain
one or more core code values.
8.6.6.5.2.2.1 Core Data Type Content Component Core Value Domain Core Code List
Core Code Value Code Localized Metadata
CDT content component core value domain core code list core code values may
have code localized metadata that is used to provide other language expressions of
its name and definition.
[D108] Each CDT content component core value domain core code list core code
value shall have zero or more code localized metadata classes.
[D109] Each occurrence of a CDT content component core value domain core code
list core code value code localized metadata class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
Name (optional): The name of the core code value in a language
other than English.
Definition (optional): The definition of the core code value in another
language.
[D110] The CDT content component core value domain core code list core code
value code localized metadata shall be in the language identified by the
language and locale code.
8.6.6.5.3 Core Data Type Content Component Core Value Domain Usage Rule
CDT content component core value domains may have usage rules. Each usage
rule defines a constraint that describes specific conditions that are applicable to the
CDT content component core value domain. CDT content component core value
domain usage rules represent the specific application of a CDT content component
core value domain in its role of expressing a value domain of its CDT content
component. CDT content component core value domain usage rules can be either
unstructured – expressed as free form text, or structured – expressed in a formal
language.
[D111] A CDT content component core value domain shall have zero or more usage
rules.
CDT content component core value domain usage rules may be reused by other DT
artefacts. However, usage rules will be applied at the lowest possible level of the
hierarchical structure to which they apply.
[D112] CDT content component core value domain usage rules shall not replicate
CDT, CDT content component, CDT supplementary component or CDT
supplementary component core value domain usage rules.
8.6.6.5.3.1 Core Data Type Content Component Core Value Domain Usage Rule
Identification Metadata
Although the unique identifier is sufficient to differentiate one usage rule in a library
from all other usage rules in a library, a CDT content component core value domain
usage rule may also have an identification metadata class that provides additional
information.
[D119] A CDT content component core value domain usage rule shall have zero or
one identification metadata classes.
The CDT content component core value domain usage rule identification metadata
may contain a unique name that semantically differentiates the usage rule from all
other named usage rules for the CDT content component core value domain.
8.6.6.5.3.2 Core Data Type Content Component Core Value Domain Usage Rule
Identification Metadata Localized Metadata
CDT content component core value domain usage rules may have localized
metadata that is used to provide other language expressions of its name and
business term or terms.
[D122] A CDT content component core value domain usage rule shall have zero or
more localized metadata classes.
[D123] Each occurrence of a CDT content component core value domain usage rule
localized metadata class shall contain:
Language Code (mandatory): A code which identifies the language
being used. Tags for the Identification of Languages, Internet
Engineering Task Force RFC 3066 of January 2001 shall be used as
the authoritative source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[C124] CDT content component core value domain usage rule localized metadata
shall be in the language identified by the language and locale code.
8.6.7 Core Data Type Supplementary Components
CDT supplementary components are defined in the UN/CEFACT Data Type
Catalogue and are unique to the CDT to which they are assigned. A CDT will have
zero or more CDT supplementary components.
[D125] A CDT shall have zero or more CDT supplementary components.
[D126] A CDT supplementary component shall be one of the specified CDT
supplementary components as defined in the UN/CEFACT Data Type
Catalogue.
8.6.7.1 Core Data Type Supplementary Component Property Term
Each CDT supplementary component contains a property term. The CDT
supplementary component property term is a semantically meaningful name for a
unique characteristic that can be used in a CDT.
[D127] Each CDT supplementary component shall have a property term.
[D154] The CDT supplementary component DEN shall be unique amongst all CDT
supplementary component names within the library of which it is a part.
8.6.7.7.1 Core Data Type Supplementary Component Core Value Domain Primitive
Primitives represent basic building blocks for defining value domains of content and
supplementary components. Each CDT supplementary component core value
domain can have zero or one primitives defined for it. The CDT supplementary
component core value domain primitive defines the value domain. Primitives are
referred to as primitive types.
Primitives include, but are not limited to:
Binary
Boolean
Decimal
Double
Float
Integer
Normalized String
String
Time Duration
Time Point
Token
[D170] Each CDT supplementary component core value domain shall have zero or
one primitives.
8.6.7.7.1.1 Core Data Type Supplementary Component Core Value Domain Primitive Facet
The value domains expressed by primitives are quantified through their facets. A
primitive may have zero or more facets. Each facet defines or constrains an aspect
of the value domain expressed by the primitive.
[D176] Each CDT supplementary component core value domain primitive shall have
zero or more facets.
Each facet shall have a facet type.
[D177] Each CDT supplementary component core value domain primitive facet shall
be one of the defined primitive facet types in the UN/CEFACT Data Type
Catalogue.
[D178] Each CDT supplementary component core value domain primitive facet shall
have a name that is unique amongst the set of facet names of a primitive.
[D179] Each CDT supplementary component core value domain primitive facet shall
have a description that semantically expresses the nature of the restrictions
associated with it.
8.6.7.7.2 Core Data Type Supplementary Component Core Value Domain Scheme
or List
Schemes are the equivalent of a pattern facet. A scheme formally expresses the
pattern and the allowed values for populating that pattern in the form of identifiers.
Lists are the equivalent of enumerated lists and are typically published as formal
code lists. The set of codes in a formal code list is used by core value domains as an
enumerated set of allowed values.
Unambiguous identification of the scheme or list is necessary.
[D180] Every CDT supplementary component core value domain scheme or list shall
have an identifier.
A version identifier serves to differentiate one version of a scheme or list from all
other versions of the scheme or list.
8.6.7.7.2.1 Core Data Type Supplementary Component Core Value Domain Core Identifier
Scheme
Identifier schemes are typically not enumerated, rather the scheme defines a regular
expression or pattern that is used to populate its set of values and also used to
validate values. No additional rules are provided regarding the content of identifier
schemes. However, at a minimum, an identifier scheme should define a specific
pattern for the values of the identifiers to conform to.
8.6.7.7.2.2 Core Data Type Supplementary Component Core Value Domain Core Code List
CDT supplementary component core value domain core code lists contain lists of
enumerated core code values and optional core code names and core code
definitions.
[D184] Each CDT supplementary component core value domain core code list shall
contain one or more core code values.
[D185] A CDT supplementary component core value domain core code list core code
value shall have zero or one core code definitions that is unique within the set
of core code values for a core code list.
[D186] A CDT supplementary component core value domain core code list core code
value shall have zero or one core code names that is unique within the set of
core code values for a core code list.
8.6.7.7.2.2.1 Core Data Type Supplementary Component Core Value Domain Core Code
List Core Code Value Code Localized Metadata
CDT supplementary component core value domain core code list core code values
may have code localized metadata that is used to provide other language
expressions of its name and definition.
[D187] Each CDT supplementary component core value domain core code list core
code value shall have zero or more code localized metadata classes.
[D188] Each occurrence of a CDT supplementary component core value domain
core code list core code value localized metadata class shall contain:
8.6.7.7.3 Core Data Type Supplementary Component Core Value Domain Usage
Rule
CDT supplementary component core value domains may have usage rules. Each
usage rule defines a constraint that describes specific conditions that are applicable
to the CDT supplementary component core value domain. CDT supplementary
component core value domain usage rules represent the specific application of a
CDT supplementary component core value domain in its role of expressing the value
domain of its CDT supplementary component. CDT supplementary component core
value domain usage rules can be either unstructured – expressed as free form text,
or structured – expressed in a formal language.
[D190] A CDT supplementary component core value domain shall have zero or more
usage rules.
CDT supplementary component core value domain usage rules may be reused by
other DT artefacts. However, usage rules will be applied at the lowest possible level
of the hierarchical structure to which they apply.
[D191] CDT supplementary component core value domain usage rules shall not
replicate CDT, CDT content component, CDT content component core value
domain, or CDT supplementary component usage rules.
[D192] A CDT supplementary component core value domain usage rule shall have
an identifier that is unique amongst all usage rules for the library of which it is
a part.
[Note] – Usage Rule Identifier Structure
There are no specific rules for the structure of usage rule identifiers. Implementers
are free to choose any structure providing it guarantees uniqueness within the group
of usage rules of a library.
The CDT supplementary component core value domain usage rule constraint is the
formal expression of the usage rule. The constraint can be structured or
unstructured. An unstructured constraint will be expressed as free form text.
[D193] An unstructured CDT supplementary component core value domain usage
rule constraint shall have a free form text expression that fully details the
usage rule.
A structured constraint is a constraint that is expressed in a formal language such as
the UML OCL or OMG SBVR.
8.6.7.7.3.1 Core Data Type Supplementary Component Core Value Domain Usage Rule
Identification Metadata
Although the unique identifier is sufficient to differentiate one usage rule in a library
from all other usage rules in a library, a CDT supplementary component core value
domain usage rule may also have an identification metadata class that provides
additional information.
[D198] A CDT supplementary component core value domain usage rule shall have
zero or one identification metadata classes.
The CDT supplementary component core value domain usage rule identification
metadata may contain a unique name that semantically differentiates the usage rule
from all other named usage rules for a CDT supplementary component core value
domain.
[D199] A CDT supplementary component core value domain usage rule shall have
zero or one names that is unique within the group of usage rules of a CDT
supplementary component core value domain.
CDT supplementary component core value domain usage rule identification
metadata may contain business terms. CDT supplementary component core value
domain usage rule business terms are synonym terms under which the usage rule is
commonly known and used in business.
[D200] Each CDT supplementary component core value domain usage rule shall
have zero or more business terms.
8.6.7.7.3.2 Core Data Type Supplementary Component Core Value Domain Usage Rule
Identification Metadata Localized Metadata
CDT supplementary component core value domain usage rules may have localized
metadata that is used to provide other language expressions of its name and
business term or terms.
[D201] A CDT supplementary component core value domain usage rule shall have
zero or more localized metadata classes
«invariant» «invariant»
{A BDT Content {A CDT Content
Component must not Component must not
have a default value.} have a default value.}
1 1
0..* 0..*
0..*
0..1
Primitive
1..*
0..* 1..* 0..* 0..* 1..*
0..* 0..*
0..* 0..*
«invariant» «Invariant»
{BusinessValue Domain Domain Restriction Facet {Core Value Domain
must have either a must have either a
+ Facet Language [0..1] + Description
Primitive or a "Business Primitive or a "Core
+ Facet Type + Facet Type
Scheme Or List", but not Scheme Or List", but
+ Facet Value + Name
both.} not both.}
0..1 0..1
«abstract» «abstract»
Business Scheme Or List Core Scheme Or List
0..1
+ Agency Identifier + Agency Identifier
+ Identifier Identification Metadata + Identifier
+ Modification Allowed Indicator: Boolean + Modification Allowed Indicator: Boolean
+ Version Identifier + BusinessTerm [0..*] + Version Identifier
+ Name [0..1]
0..*
Localized Metadata
+ BusinessTerm [0..*]
+ Language Code
+ Name [0..1]
1..* 1
1..* 1..*
+ Language Code
+ Name [0..1]
+ Definition [0..1]
8.7.7.5.2 Business Data Type Content Component Business Value Domain Primitive
Primitives represent basic building blocks for defining value domains of content and
supplementary components. Each BDT content component business value domain
can have zero or one primitives defined for it. The BDT content component business
value domain primitive defines the value domain. Primitives are referred to as
primitive types.
Primitives include, but are not limited to:
Binary
Boolean
Decimal
Double
Float
Integer
Normalized String
8.7.7.5.2.1 Business Data Type Content Component Business Value Domain Primitive
Facet
The value domains expressed by primitives are quantified through their facets. A
primitive may have zero or more facets. Each facet defines or constrains an aspect
of the value domain expressed by the primitive.
[D294] Each BDT content component business value domain primitive shall have
zero or more facets.
Each facet shall have a facet type.
[D295] Each BDT content component business value domain primitive facet shall be
one of the defined primitive facets in the UN/CEFACT Data Type Catalogue.
[D296] Each BDT content component business value domain primitive facet shall
have a name that is unique amongst the set of facet names of a primitive.
[D297] Each BDT content component business value domain primitive facet shall
have a description that semantically expresses the nature of the restrictions
associated with it.
8.7.7.5.3 Business Data Type Content Component Business Value Domain Scheme
or List
Schemes are the equivalent of a pattern facet. A scheme formally expresses the
pattern and the allowed values for populating that pattern in the form of identifiers.
Lists are the equivalent of enumerated lists and are typically published as formal
8.7.7.5.3.1 Business Data Type Content Component Business Value Domain Business
Identifier Scheme
Identifier schemes are typically not enumerated, rather the scheme defines a regular
expression or pattern that is used to populate its set of values and also used to
validate values. BDT content component business value domain business identifier
schemes can be restricted from their basis CDT content component core value
domain core scheme, or less restricted BDT content component business value
domain business scheme. These restrictions take the form of subsetting the set of
allowed values as defined by its regular expression or pattern.
[D302] Each BDT content component business value domain business identifier
scheme set of allowed values shall be equal to or less than the set of allowed
values of its basis CDT content component core value domain core identifier
scheme or less restricted BDT content component core value domain
business identifier scheme.
8.7.7.5.3.2 Business Data Type Content Component Business Value Domain Business
Code List
Business data type content component business value domain business code lists
contain lists of enumerated business code values and optional business code names
and business code definitions.
[D303] Each BDT content component business value domain business code list shall
contain one or more business code values.
8.7.7.5.3.2.1 Business Data Type Content Component Business Value Domain Business
Code List Business Code Value Code Localized Metadata
BDT content component business value domain business code list business code
values may have code localized metadata that is used to provide other language
expressions of its name and definition.
[D307] Each BDT content component business value domain business code list
business code value shall have zero or more code localized metadata
classes.
[D308] Each occurrence of a BDT content component business value domain
business code list business code value code localized metadata class shall
contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
Name (optional): The name of the business code value in a language
other than English.
Definition (optional): The definition of the code value in another
language.
[D309] The BDT content component business value domain business code list
business code value code localized metadata shall be in the language
identified by the language and locale code.
8.7.7.5.4 Business Data Type Content Component Business Value Domain Usage
Rule
BDT content component business value domains may have usage rules. Each
usage rule defines a constraint that describes specific conditions that are applicable
to the BDT content component business value domain. BDT content component
business value domain usage rules represent the specific application of a BDT
content component business value domain in its role of expressing a value domain
of its BDT content component. BDT content component business value domain
8.7.7.5.4.1 Business Data Type Content Component Business Value Domain Usage Rule
Identification Metadata
8.7.7.5.4.2 Business Data Type Content Component Business Value Domain Usage Rule
Identification Metadata Localized Metadata
BDT content component business value domain usage rules may have localized
metadata that is used to provide other language expressions of its name and
business term or terms.
[D321] A BDT content component business value domain usage rule shall have zero
or more localized metadata classes.
[D322] Each occurrence of a BDT content component business value domain usage
rule localized metadata class shall contain:
Language Code (mandatory): A code which identifies the language
being used. Tags for the Identification of Languages, Internet
Engineering Task Force RFC 3066 of January 2001 shall be used as
the authoritative source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[D323] BDT content component business value domain usage rule localized
metadata shall be in the language identified by the language code.
8.7.8 Business Data Type Supplementary Components
A BDT will have zero or more BDT supplementary components.
[D324] A BDT shall have zero or more BDT supplementary components.
BDT supplementary components are based on the CDT supplementary component
of the source CDT.
[D353] The BDT supplementary component DEN shall be unique amongst all BDT
supplementary component names within the library of which it is a part.
Primitive type facet restrictions for BDT supplementary component business value
domains consist of the facet type, facet value, and optional facet language.
[D374] Each BDT supplementary component business value domain – domain
restriction shall contain the following attributes:
8.7.8.7.4.1 Business Data Type Supplementary Component Business Value Domain Usage
Rule Identification Metadata
Although the unique identifier is sufficient to differentiate one usage rule in a library
from all other usage rules in a library, a BDT supplementary component business
value domain usage rule may also have an identification metadata class that
provides additional information.
[D405] A BDT supplementary component business value domain usage rule shall
have zero or one identification metadata classes.
8.7.8.7.4.2 Business Data Type Supplementary Component Business Value Domain Usage
Rule Identification Metadata Localized Metadata
BDT supplementary component business value domain usage rules may have
localized metadata that is used to provide other language expressions of its name
and business term or terms.
[D408] A BDT supplementary component business value domain usage rule shall
have zero or more localized metadata classes
[D409] Each occurrence of a BDT supplementary component business value domain
usage rule localized metadata class shall contain:
Language Code (mandatory): A code which identifies the language.
Tags for the Identification of Languages, Internet Engineering Task
Force RFC 3066 of January 2001 shall be used as the authoritative
source for code values.
Name (optional): The name of the usage rule in a language other
than English.
Business Term (optional, repetitive): A synonym term in another
language under which the usage rule is commonly known and used in
a business expression in that language.
[D410] BDT supplementary component business value domain usage rule localized
metadata shall be in the language identified by the language and locale code.
9 Context
This section fully describes applicable rules and applications for the use of context in
core component discovery, analysis, and use to include context categories and their
values.
[Note] – Context Mechanism
The context mechanism is being more robustly defined in a separate UN/CEFACT
Context Methodology specification. Once the final version of that specification is
published, this section will be deprecated.
9.1 Overview
Whenever business collaboration takes place between specific trading partners, data
is exchanged in the form of business messages. When used as such, that data
exists in a particular business context. In its simplest form, this is the idea of context
as used in this specification. The context in which the business collaboration takes
place can be specified by a set of categories and their associated values.
1..*
0..*
0..*
1..*
Product Classification Context Value
1..*
+ Context Category
+ Definition
+ Hierarchy SystemCapabilities Context Value
+ Name: ABIE Property 1..*
+ Owner
+ Primitive Type
0..1
9.5 Categories
Context categories exist to allow users to uniquely identify and distinguish between
different business contexts. Eight context categories have been identified
(Table 9-1). Each of the identified categories, unless otherwise stated, uses a
standard classification to provide values for the category. Constraint rules, and
therefore BIEs, are tied to a particular set of standard classifications for identifying
and distinguishing contexts.
Product Classification Factors influencing semantics that are the result of the
goods or services being exchanged, handled, or paid for,
etc. (e.g. the buying of consulting services as opposed to
materials).
10 Definition of Terms
Aggregate Business Information Entity (ABIE) – An aggregate business
information entity is a collection of related pieces of business information that
together convey a distinct business meaning in a specific business context.
Expressed in modelling terms, it is the representation of an object class, in a specific
business context.
Aggregate Business Information Entity Property – An aggregate business
information entity property is a business information entity property for which the
permissible values are expressed as a complex structure, represented by an
aggregate business information entity.
Aggregate Core Component (ACC) – An aggregate core component is a collection
of related pieces of business information that together convey a distinct business
meaning, independent of any specific business context. Expressed in modelling
terms, it is the representation of an object class, independent of any specific
business context.
Primitive Type – A primitive type, also known as a base type or built-in type, is the
basic building block for the representation of a value as expressed by more complex
data types.
11 References
Electronic Business Extensible Markup Language (ebXML) -- Part 5: ebXML
Core Components Technical Specification, ISO/TS 15000-5:2005 Version
2.01(ebCCTS)
Information Technology – Specification and standardization of data elements –
Part 1: Framework for the specification and standardization of data elements,
International Standardization Organization, ISO 11179-1:1999
Information Technology – Metadata registries (MDR) – Part 2: Classification,
ISO 11179-2: Second Edition 2005-11-15
Information Technology – Metadata registries (MDR) – Part 3: Registry
Metamodel and Basic Attributes, ISO 11179-3(e): Second Edition 2003/Cor
1:2004
Information Technology – Metadata registries (MDR) – Part 4: Formulation of
Data Definitions, ISO 11179-4: Second Edition 2004-07-15
Information Technology – Metadata registries (MDR) – Part 5: Naming and
Identification Principles, ISO 11179-5: Second Edition 2005-09-01
Information Technology – Metadata registries: Registration, ISO 11179-6:
Second Edition 2005-01-15
Information Technology -- Programming languages, their environments and
system software interfaces -- Language-independent datatypes - ISO/IEC
11404:1996 - 1st edition.
Tags for the Identification of Languages, Internet Engineering Task Force (IETF)
RFC 3066 of January 2001
UN/CEFACT Core Components Technical Specification – Part 8 of the ebXML
Framework, 15 November 2003
UN/CEFACT Modeling Methodology (UMM): UMM Meta Model – Foundation
Module Version 1.0 Technical Specification, October 2006
UN/CEFACT Modeling Methodology (UMM): UMM Meta Model – Base Module
Version 1.0 Technical Specification, October 2006
Unified Modeling Language™(UML) Superstructure, Version 2.1.1, 2007-02-03
Unified Modeling Language™(UML) Infrastructure, Version 2.1.1, 2007-02-04
12 Disclaimer
The views and specification expressed in this document are those of the authors and
are not necessarily those of their employers. The authors and their employers
specifically disclaim responsibility for any problems arising from correct or incorrect
implementation or use of this design.
Copyright Statement
Copyright © UN/CEFACT 2009. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the copyright
notice or references to UN/CEFACT except as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be revoked by
UN/CEFACT or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis
and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: