UN/CEFACT Unified Context Methodology Technical
UCM Draft A29 03 February 2010
5
6
1
2
3
4
UN/CEFACT
Unified Context Methodology
Technical Specification
Working Draft
Revision [A29]
[03 February 2010]
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 1 of 34
UCM Draft A29
7
ABSTRACT
8 [Ed Note - Insert Abstract Here in ODP4]
9
03 February 2010
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 2 of 34
UCM Draft A29 03 February 2010
10
11
12
13
14
Table of Contents
2 UN/CEFACT UNIFIED CONTEXT METHODOLOGY TECHNICAL
SPECIFICATION PROJECT TEAM PARTICIPANTS ............................................. 6
15
16
17
18
19
20
22
23
24
21
Goals of the UCM Technical Specification ........................................................ 8
25
26
27
28
29
30
Core Components and Business Information Entities ...................................... 11
31
32
33
34
Mathematical Directed Acyclic Graph ......................................................... 12
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 3 of 34
UCM Draft A6 01 October 2009
35
36
37
38
39
40
41
Expressing Context Using a Mathematical Graph ............................................ 15
42
43
44
45
46
47
48
49
7 CONTEXT EXPRESSION GRAMMAR ............................................................. 23
50
51
52
53
54
55
56
57
8 DEFINING AND USING BUSINESS CONTEXT .............................................. 28
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 4 of 34
UCM Draft A6 01 October 2009
58
59
60
61
62
63
1 Status of this Document
64
65
66
This Technical Specification is being developed in accordance with the UN/CEFACT
Trade R650R4 Open Development Process for Technical Specifications. The Unified
Context Methodology Project Team is developing it for internal review.
67 This document contains information to guide in interpretation or implementation.
68 Distribution of this document is limited to UCM Project teams.
69
70
This version: Unified Context Methodology Technical Specification, Version 1.0 Draft
A14 of 01 October 2009.
71
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 5 of 34
UCM Draft A29 03 February 2010
72
73
74
2 UN/CEFACT Unified Context Methodology
Technical Specification Project Team
Participants
75
76
77
We would like to recognize the following for their significant participation to the development of this document.
78
Project Team Leader: Scott Hinkelman, Oracle
Editors:
Pat O’Connor, Infor
79
80
81 Contributors:
82
83
84
85
86
87
88
Anthony Coates, Londata
Mark Crawford, SAP
Oyvind Assave, Nortella (at time of participation)
David Connelly, OAGi
Mark Crawford, SAP AG
Michael Rowell, Oracle
Gunther Stuhec, SAP AG
Nikola Stojanovic, RosettaNet
Jim Wilson, KCX
89
2.1
Disclaimer
90
91
92
93
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.
94
2.2
Contact Information
95
96
97
CCWG Chair: Mark Crawford, SAP, mark.crawford@sap.com
UCM Chair: Scott Hinkelman, Oracle, scott.hinkelman@oracle.com
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 6 of 34
UCM Draft A6
98
99
3 Introduction
3.1
Summary of Contents of Document
100
01 October 2009
101
102
103
104
105
106
107
108
109
3.2
Audience
Software architects, information architects, standards organizations, governments, private sector and non profit organizations who desire to design, build, implement or use a context driven solution for their business information.
UN/CEFACT Forum participants.
Internal UN/CEFACT and external private and public sector users of the Core
Components Technical Specification, Data Type Catalogue, UML Profile for
Core Components, Core Components Message Assembly, and XML Naming and
Design Rules.
110
111
3.3
Related Documents
3.3.1
Documents:
112 UML 2.x.x
113 UMM Base Module 2.0
114
115
UMM Foundation Module 2.0
CCTS 3.0
116 DTC 3.0
117 UPCC 3.0
118 3.3.2
Normative References:
119 Chartand, Gary. Introductory Graph Theory, 1985
120
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 7 of 34
UCM Draft A29 03 February 2010
121
122
4 Objectives
4.1
Goals of the UCM Technical Specification
123
124
125
126
127
The goal of this specification is to deliver a unified methodology for developing, registering, and using context to support UN/CEFACT Core Components Technical
Specification, Data Type Catalogue, UML Profile for Core Components, Core
Components Message Assembly, and XML Naming and Design Rules; and similar standards for defining and using business information.
128
129
Enable widespread software tooling to realize the promise of the UN/CEFACT common methodology standards stack.
130
4.2
Requirements
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
To ensure this specification meets its intended audience’s needs, it satisfies the following requirements:
Defines context concepts in terms of CCTS artifacts
Supports migration of existing CCTS based context methodologies
Defines a usable metamodel
Defines a methodology for defining, extending, restricting and managing context values
Defines a methodology for defining, extending, restricting and managing groupings of context values
Defines a methodology for defining, extending, restricting and managing relationships between context values
Defines a methodology for managing and applying context values at design time
Defines the relationships between context values and lists and schemes of context values
Defines rules for creating and using lists and schemes of context values
Supports multi-parent hierarchies
Support multiple context values in groupings of business information
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 8 of 34
UCM Draft A6
148
4.3
Caveats and Assumptions
01 October 2009
149
150
151
152
153
154
155
156
Even though this specification is intended for use by a broad constituency to include those that do not use UN/CEFACT standards, we assume that the reader has a general understanding of the UN/CEFACT common methodology standards stack – CCTS, CCL,
DT Catalogue, UMM etc.
We assume the reader has a familiarity with the OMG UML.
We assume the reader has a familiarity with mathematical graph theory, especially Directed Acyclic Graphs.
We assume the reader has a familiarity with set theory
157
4.4
Guiding Principles
158
159
160
161
162
163
164
165
In order to maximize the usefulness of this specification, the following guiding principles have been adhered to:
UCM will minimize dependencies on specific implementation technologies and other specifications.
UCM will be cohesive with related UN/CEFACT standards.
UCM will not limit the sources and uses of context.
UCM will be based on existing standards and scientific and mathematical principles.
166
4.5
Conformance
167
168
169
170
171
172
Designers in governments, private sector, and other standards organizations external to the UN/CEFACT community have found this specification suitable for adoption. To maximize reuse and interoperability across this wide user community, the rules in this specification have been categorized to allow these other organizations to be conformant while allowing for discretion or extensibility in areas that have minimal impact on overall interoperability.
173
174
Accordingly, 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.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 9 of 34
UCM Draft A6 01 October 2009
175
176
Rules in categories 1, 4 and 5 cannot be modified. Rules in categories 2, 3, 6, and 7 may be tailored within the limits identified in the rule and the related normative text.
Conformance SHALL be determined through adherence to the content of the normative sections and rules. Furthermore each rule is categorized to indicate the intended audience for the rule by the following:
Rule Categorization
ID Description
1 Rules which must not be violated by individual organizations else conformance and interoperability is lost
2 Rules which may be modified by individual organizations while still conformant to the overall intent.
[R XXX]
3 Rules which may be modified by individual organizations while still conformant to agreed upon data models
4 Rules that if violated lose conformance with the
UN/CEFACT context model
5 Rules that relate to extension that are not used by
UN/CEFACT and have specific restrictions on their use by other than UN/CEFACT organizations.
6 Rules that relate to extension that are determined by specific organizations.
7 Rules that can be modified while not changing instance validation capability.
1
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 10 of 34
UCM Draft A29 03 February 2010
177
5 Overview
178
179
180
181
182
183
The UN/CEFACT Context Methodology is a methodology for managing the representation and use of business context information, especially for UN/CEFACT technologies. This includes representing the business contexts of Business Information
Entities (BIEs), using business context during message assembly to produce messages for specific business contexts, and using business context to (semi-) automatically customise generic business processes.
184
185
186
187
188
189
In building a context model, it is necessary to have an agreed definition of what context is. Without agreement on what context is, it isn't possible to define an agreed methodology for modelling context and for processing context models to drive customisations. Context is metadata that defines circumstances in which particular data is or is not relevant. That is to say, context information is information that is used to identify the scope (relevance, applicability, business context) of some other information.
190
191
192
193
194
In order to create a workable context model and methodology, it is necessary to understand what context information needs to be modelled and how it will be used. The concept of context naturally leads to categorization of context values which can be expressed as a context category.
A context category is a group of one or more unordered values used to express a characteristic of a business circumstance.
195
5.1
Core Components and Business Information Entities
196
197
198
199
200
201
202
The Core Components Technical Specification (CCTS) defines two key concepts – Core
Components and Business Information Entities. Core Components (CCs) are conceptual data model components that are not specific to any particular business context. They represent a superset from which business-specific data model components are created.
Business Information Entities (BIEs) represent logical data model components in a given context and can be used as business-specific message components. Each BIE is derived by restriction from a CC
1
.
203
204
In modelling approaches that do not have an equivalent of the CC layer, what typically
(and quickly) happens is that business message components are copied, truncated, and
1 Note that an ABIE (Aggregate Business Information Entity) can have more children (BBIEs and ASBIEs) than the ACC (Aggregate Core Component) that it restricts, since the individual BCCs and ASCCs from the ACC are allowed to be repeated in the ABIE with different business contexts (so there can be multiple
BIEs derived from a single BCC in an ABIE, etc.).
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 11 of 34
UCM Draft A6 01 October 2009
205
206
207
208
209 extended, so that soon there are many business components with similar fields, but no way to be sure whether two fields in different components are the same or not. This leads to an explosion of fields with similar but different definitions and information.
Mismatches between the definitions of similar fields make it difficult to move information reliably and correctly between systems.
210
211
212
213
The CCTS approach requires all BIEs to be related back to the common CCs, so that there is no confusion when two fields are the same. The introduction of new CCs, and new fields (BCCs or ASCCs) into ACCs (Aggregate Core Components) is managed through a harmonisation process that detects and removes duplicate field definitions.
214
5.2
UCM
215
216
UCM is comprised of a Context Graph, Context Grammar, and Context use.
[Ed Note – insert figure here in ODP4]
217
5.3
Graph Theory
218
219
220
221
222
UCM uses graph theory to define and understand the concept of context, context categories, context values and context operands. It is necessary to understand graph theory and terms to properly understand and apply UCM. A graph is a set of nodes
(points) connected by edges. A root node is a starting point of a graph. An edge is an ordered pair of vertices represented by a connection between two nodes.
223
224
225
226
UCM is predicated on Directed Acyclic Graphs (DAGs). A graph is directed if it defines a direction between nodes, and does not allow for looping between nodes. A graph is acyclic if it has no cycles. A DAG can contain one or more entry points/root nodes. UCM supports DAGs with multiple entry points/root nodes.
227 5.3.1
Mathematical Directed Acyclic Graph
228
229
230
231
This section provides a terse explanation of key DAG concepts and base terminology. For in depth discussion of graphs, much has been written. Refer to the reference section of the specification. We identify and discuss the base concepts of a DAG which are relevant to this specification, which uses a mathematical DAG as its foundation.
232
233
234
235
A Directed Acyclic Graph is a specific form of a graph. In a DAG, vertices (or nodes) are directionally connected by edges (or lines) and following any edge along its direction, from a given vertex, the same vertex can never be reached (no cycles, acyclic). Edges directionally connect two vertices.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 12 of 34
UCM Draft A6 01 October 2009
236
237
In graph theory, an edge is a pair of vertices (nodes). In a DAG, an edge is an ordered pair of vertices (the order semantics are not specified).
238 Throughout the rest of this document the term node will be used for a vertex .
239 5.3.2
Notations
240
241
242
While there is no best drawing of a graph, they are usually represented using dots to represent vertices and lines, or arcs, to represent edges. Arrows are usually used to show orientation of directed edges.
243 Notations for a mathematical DAG are the primary notations used in this specification.
244 A node is represented by ellipse:
245
246
247
An edge is represented arrow, which identifies the direction. The end of the arrow without the arrow head is the edge source and the end with the arrow is the edge target .
248
249
250
251
Technically, a DAG is purely mathematical, and vertices within a DAG do not require a value, or label, of any sort. For the purpose of this specification, we will use a simple text label within a node to exemplify a value of a node.
X
252
253 5.3.3
Key DAG Concepts
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 13 of 34
UCM Draft A6
1 2 3 4
01 October 2009
5
6 7
254
255
256
257
258
8
A root node is a node that is not the edge target of any edge (1, 2, 3, and 4). A leaf node is a node that is not the edge source of any edge (4, 6, and 8). Note that (4) is both a root node and a leaf node. Nodes which are neither a root node nor leaf node (5) have no special term beyond just ‘node’.
259
260
An edge that goes from a particular node is an outgoing edge of that node. An edge that goes to a particular node is an incoming edge of that node.
261
262
263
Note that there is no requirement for a node to be connected by edges. A DAG may have one or more source vertices and one or more sink vertices, but must have at least one node .
264
5.4
CCTS Classic Context
265
266
267
268
269
CCTS defines Business Context as 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. Each context category consists of a set of related context values. Each value is defined by a classification scheme which is expressed as code list or identifier scheme.
270
5.5
Context DAGs
271
272
273
274
275
276
A Context DAG is an organized collection of values. A Context DAG has one or more context root nodes. Each context root node is the equivalent of a classic CCTS context category. Each context root node has zero or more child nodes, each of which represents a related context value. Each context value is an identifier from an identification scheme or a code from a code list. Business context is identified through a context expression that is relevant to one or more context graphs and specific context
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 14 of 34
UCM Draft A6 01 October 2009
277
278
279 values within them. The business context describes the specific business circumstance for the use of a given contextualizable (refer to Chapter 7 for information on contextualizable).
280
5.6
Business Context
281
282
Definition – Business Context
Business Context is an organized collection of context values.
283
284
285
The business context is assigned to a contextualizable whose applicability in a specific business transaction is determined by the comparing its business context to the context of the transaction.
286
5.7
Classification Models
287
288
289
290
291
292
293
294
295
296
The context model that is presented in this document is a network classification model.
What does that mean? A network classification model is basically a collection of classifications with associations (relationships) between those classifications. The associations are not necessarily hierarchical (as they would be in, say, a strict taxonomy).
The way you control the structure of a classification model is by controlling the associations that are allowed (or required) in the model. For the UCM context model, where each classification is a context, the aim is to have just enough kinds of associations to represent the necessary relationships between contexts, without having so many different kinds of associations that it becomes difficult to process the model and produce the information required by context-driven processes, e.g. message assembly.
297
5.8
Expressing Context Using a Mathematical Graph
298
299
300
301
302
303
304
305
306
307
308
A business context is commonly a combination of multiple separate contexts. Given the context values of ‘
Global
’, ‘
Automotive
’, ‘
Asia
’, ‘
Japan
’ and ‘
China
’ the following statements could be made. Global Automotive is a compound context that combines the ‘ Global ’ context with the ‘ Automotive ’ context. The context model needs to be able to combine contexts to produce narrower, or more specific, business contexts. It also must be possible to combine context to produce broader business contexts, e.g. to combine ‘ Japan ’ and ‘ China ’ to produce ‘ Japan ’ and ‘ China ’. It is sometimes also necessary to be able to remove some context. For example, if you need to express the context ‘ Asia ’ without ‘ Japan ’, it is much simpler if you can express this narrowing of the context directly, rather than by individually listing and combining the contexts for all of the countries in ‘ Asia
’ other than ‘
Japan
’.
309 The foundation of this specification is a mathematical graph.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 15 of 34
UCM Draft A6 01 October 2009
310
311
312
Specifically, this specification is based on a Directed Acyclic Graph [ DAG ]. A DAG has many applications in event processing, expression evaluation, game theory, sorting algorithms, parser algorithms, etc.
313
314
While a DAG is a mathematical construct, it defines no semantics. This specification imposes semantics on a DAG to realize Context Schemes.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 16 of 34
UCM Draft A29 03 February 2010
315
6 Context Graphs
316
317
318
319
320
321
322
A ContextGraph is the foundation of the UCM methodology. A context graph is a mathematical DAG. A ContextGraph imposes semantics on a directed acyclic graph to realize the expression of context.
Definition – ContextGraph
A ContextGraph is the organization of possible values used to identify specific business circumstances. A ContextGraph is a Directed Acyclic
Graph.
323
324
A ContextGraph may or may not contain all possible context values used to express a given business context.
+graph 1
ContextGraph
ContextEdge
+edge 0..* constraints
{Target must be different to source}
{Both nodes are from same graph as edge}
{At most one edge connects any pair of nodes}
0..* 0..*
Should source and target be renamed parent and child ?
Or should we talk about indirect source and indirect target rather than ancestor and descendant ?
+graph 1 +source 1 1 +target
1
1
ContextGraphInformation
+ ContextGraphIdentifier: String
+ ContextGraphName: String [0..1]
+ ContextGraphDescription: String [0..1]
+ ContextGraphVersionIdentifier: String
+ ContextGraphVersionDate: Date [0..1]
+ ContextGraphAgencyIdentifier: String
+ ContextGraphAgencyName: String [0..1]
+node 1..*
ContextNode
+ ContextNodeIdentifier: String
+ ContextValue: String
+ ContextValueName: String [0..1]
+ ContextValueDefinition: String [0..1] constraints
{Is a ContextRootNode, or has exactly 1 ancestor ContextRootNode}
{(ContextValueSource,ContextValue) pair is unique within tree rooted at ContextRootNode}
+Source
0..*
1
ContextRootNode constraints
{Not a target of any edge}
Scheme Or List
+ Identifier: String
+ VersionIdentifier: String
+ AgencyIdentifier: String
325
326 Figure 6-1. ContextGraph
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 17 of 34
UCM Draft A6 01 October 2009
327
328
329
330
Note –
This specification utilizes UML to sketch the concepts where useful to facilitate the discussion. Unless otherwise specified, these sketches are informative.
331
332
A ContextGraph consists of ContextGraphInformation, ContextNodes, and possibly
ContextEdges.
333 [Ed Note – insert hyperlinks above to the relevant sections]
[R XXX]
A ContextGraph MUST have one ContextGraphInformation
[R XXX]
A ContextGraph MUST have one or more ContextNode
[R XXX]
A ContextGraph MUST have zero or more ContextEdge
1
1
1
334
6.1
ContextGraph Information
335
336
337
ContextGraphInformation provides unique information about the entire graph.
Definition – ContextGraphID
A ContextGraphID uniquely identifies a ContextGraph.
338
[R XXX]
The ContextGraphInformation MUST have a ContextGraphID.
[R XXX]
Once assigned, a ContextGraphID MUST never be changed or reused.
[R XXX]
The ContextGraphID MUST be a URN as defined by RFC 2141.
1
[R 8E2D]
The ContextGraphID URN scheme MUST use the following pattern:
URN: urn:<organization>:<org hierarchy>[:<org hierarchy level>]*:context:<major>:<status>
3
1
1
Where:
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 18 of 34
UCM Draft A6 01 October 2009
organization – An identifier of the organization providing the standard.
org hierarchy – The first level of the hierarchy within the organization providing the standard.
org hierarchy level – Zero to n level hierarchy of the organization providing the standard.
data
package – the context graph name
major – The major version number.
status – The status of the schema as: draft|standard .
[R XXX]
[R XXX]
[R XXX]
[R XXX]
[R XXX]
[Ed Note – take NDR example and insert here]
The ContextGraphInformation MUST have a ContextGraphVersionID.
1
The ContextGraphInformation MUST have zero or one ContextGraph
Version Date
The ContextGraph Version ID MUST consist of a major and minor version number (add language from NDR regarding allowed values).
1
A ContextGraph minor version MUST have the same ContextGraphID as its major version.
1
The ContextGraphInformation MUST have a ContextGraph Agency ID (add language from NDR/CCTS about using the UN/CEFACT AID or when an agency doesn’t have an agency id.)
1
The ContextGraphInformation MUST have zero or one ContextGraph Name
1 [R XXX]
[R XXX]
[R XXX]
The ContextGraphInformation MUST have zero or one ContextGraph
Agency Name
The ContextGraphInformation MUST have zero or one ContextGraph
Description
1
1
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 19 of 34
UCM Draft A6
339
6.2
ContextNode
01 October 2009
ContextNode
+ ContextNodeIdentifier: String
+ ContextValue: String
+ ContextValueName: String [0..1]
+ ContextValueDefinition: String [0..1]
0..*
Scheme Or List
+Source
1
+ Identifier: String
+ VersionIdentifier: String
+ AgencyIdentifier: String
340
341 Figure 6.3. ContextNode
342
343
ContextNodes contain the ContextValues in a ContextGraph. ContextNodes are organized through the use of ContextEdges.
344
345
346
[Ed. Note – Insert link for ContextEdge to Section 6.3]
Definition – ContextNode
A ContextNode is a node in a ContextGraph
347
348
349
A ContextNode may have multiple parent ContextNodes. A ContextNode can be a
ContextRootNode. A ContextNode at any level in the graph will only have at most one ancestor ContextRootNode.
350
351
352
353
A ContextGraph uses globally unique identifiers for each node. Globally unique identifier schemes include:
UUID
URI
1 [R XXX] A ContextNode MUST have one ContextNodeIdentifier
354
355
UN/CEFACT will use UUIDs. Other organizations are free to choose URI or any other scheme that guarantees global uniqueness.
[R XXX] A ContextNodeID MUST be globally unique
[R XXX] A ContextNodeID MUST be a UUID
1
3
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 20 of 34
UCM Draft A6
[R XXX] A ContextNode ID MUST be devoid of white space
01 October 2009
1
356
357
358
6.2.1
ContextValue
Definition –
ContextValue
A
ContextValue
is a value taken from an identified scheme or list
359 Each ContextNode has a ContextValue
[R XXX] The ContextNode MUST have exactly one ContextValue
[R XXX]
1
Each ordered pair ContextValue and ContextValueSource MUST be unique within the set of ContextNodes comprising a ContextRootNode and all of its descendent ContextNodes.
1
[R XXX] The ContextNode MUST have zero or one ContextValue Name
[R XXX] The ContextNode MUST have zero or one ContextValue Definition
1
1
360 6.2.2
ContextNode Scheme or List
[R XXX]
[R XXX]
The ContextNode MUST have one Scheme or List
1
The Scheme or List MUST have the following properties:
Identifier (1..1) – Unambiguous identification of the scheme or list is necessary.
Version identifier (1..1) – Serves to differentiate one version of a scheme or list from all other versions of the scheme or list.
Agency identifier (1..1) – Every scheme or list will be owned by an organization. The organization is identified by a unique identifier.
1
361
6.3
ContextRootNode
362
363
ContextRootNode are intended to reflect separate categories of organized values. It is a special form of ContextNode.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 21 of 34
UCM Draft A6 01 October 2009
364
365
366
Definition – ContextRootNode
A ContextRootNode is a ContextNode that is not a target ContextNode of any ContextEdge.
[R XXX]
A ContextNode which is not a ContextRootNode MUST only be connected to one ancestor ContextRootNode.
1
367
368
[Note] – A ContextRootNode ContextValue provides the least precise level of semantics within a ContextGraph .
369
[R XXX]
A ContextGraph MUST contain one or more RootContextNode.
1
370
6.4
.
ContextEdge
371
372
373
374
375
376
377
378
379
380
A ContextEdge relates two ContextNodes, where one ContextNode is the source and the other ContextNode is the target. The relationship is directional from the source
ContextNode to the target ContextNode. Possible relationship types include, but are not limited to, type of and aggregation/composition (i.e., part of). A source ContextNode is the ContextNode in a ContextEdge that is reached earlier in the directed collection of
ContextNodes . A target ContextNode is the ContextNode in a ContextEdge that is accessed through the source ContextNode.
Definition – ContextEdge
A ContextEdge is a directed relationship between a source
ContextNode and target ContextNode.
[R XXX] The set of ContextEdges in a ContextGraph MUST be acyclic.
381
382
383
The target ContextNode ContextValue represents a narrowed relationship to the source
ContextNode’s ContextValue such as a – generic expression of, kind of, whole/part relation of.
384
1
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 22 of 34
UCM Draft A6 01 October 2009
385
7 Context Expression Grammar
386
387
388
389
390
391
The UCM context expression grammar is used to identify particular sets of ContextNodes from a ContextGraph, and is defined using predicate language. A context expression is a function that can be applied to a ContextNode to determine whether it matches a given context or not. It is a function that has a single ContextNode operand and returns a boolean result. UCM context expressions are written without showing the single operand explicitly.
392
7.1
Context Expression
393 A ContextExpression is created using the Context Expression Grammar.
ContextExpression
+ ContextExpressionID: String
+ ContextExpressionVersionID: String
0..* 1
«abstract»
ContextClause
SimpleContextClause
+ Predicate: PredicateKind
«enumeration»
PredicateKind
=
!=
>
<
>=
<=
0..*
1
ContextGraph
2 {ordered}
0..*
CompoundContextClause
+ Operator: OperatorKind
0..*
1
ContextNode
«enumeration»
OperatorKind
&&
||
!
394
395
396
397
398
399
Figure 7-1. Context Expression UML
Definition – ContextExpression
A Context Expression is a combination of a single ContextClause and the identification of the specific version of the ContextGraph to which it is applicable.
400
401
The ContextExpression contains the ID and version of the ContextGraph to which it refers.
[R XXX]
[R XXX]
A ContextExpression MUST contain the ID of the ContextGraph to which it applies.
1
A ContextExpression MUST contain the version of the ContextGraph to which it applies.
1
402 A ContextExpressionID is a unique identifier.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 23 of 34
UCM Draft A6
[R XXX]
A ContextExpressionID MUST be globally unique
[R XXX]
A ContextExpressionID MUST be a UUID
01 October 2009
403 A ContextExpression has a version number.
[R XXX]
A ContextExpression MUST have a version number.
404 A ContextExpression has a single ContextClause.
[R XXX]
A ContextExpression MUST have a single ContextClause
1
1
405
406
407
The ContextExpression lexical notation [create appendix with lexical notation characters and insert hyperlink here] contains the ContextGraph URI, ContextGraph version, and
ContextClause in that order with a space character between each.
[R XXX]
A ContextExpression MUST have the following lexical notation:
<ContextExpressionIdentifier><spacecharacter><ContextGraph
URI><spacecharacter><ContextGraphversion><spacecharacter><Co ntextClause>
1
1
3
408
7.2
Context Clause
409
410
411
412
413
414
The ContextClause is the normative expression of the set of ContextNodes that together express a Business Context.
Definition –
ContextClause
A ContextClause is the part of a ContextExpression that formally defines a particular Business Context in terms of a set of
ContextNodes
415
416
There are two types of ContextClauses – SimpleContextClause and
CompoundContextClause.
[R XXX]
A ContextClause Must be a SimpleContextClause or a
CompoundContextClause
1
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 24 of 34
UCM Draft A6 01 October 2009
417
418
419
Definition – SimpleContextClause
A SimpleContextClause is a ContextClause with one predicate and one
ContextNodeID.
420
421
422
[R XXX]
A SimpleContextClause MUST have the following lexical notation:
<predicate><spacecharacter><ContextNodeID>
Definition – CompoundContextClause
A CompoundContextClause is a ContextClause with two ordered
ContextClauses and one operand.
[R XXX]
A CompoundContextClause MUST have the following lexical notation:
(<ContextClause>)<operator>(<ContextClause>)
1
1
423 7.2.1
Predicates
424
425
426
427
428
429
Predicates are used within SimpleContextClauses to define matching of
ContextNodes. A SimpleContextClause contains a ContextNodeID, referred to hereafter as “the specified ContextNodeID”. The ContextNode whose (unique)
ContextNodeID is contained in the SimpleContextClause is referred to hereafter as “the specified ContextNode”. A predicate is a function that compares some given ContextNode to the specified ContextNode and returns a boolean result.
430 Allowed predicates and their meaning (with notation):
Predicate Short Name
=
Meaning
Equal to True if the given ContextNode has the same
ContextNodeID as the specified
ContextNode. False otherwise.
!=
>
Not equal to True if the given ContextNode does not have the same ContextNodeID as the specified ContextNode. False otherwise.
Greater than True if the given ContextNode is an ancestor of, but not equal to, the specified
ContextNode. False otherwise.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 25 of 34
UCM Draft A6 01 October 2009
Predicate Short Name
<
Meaning
Less than True if the given ContextNode is a descendant of, but not equal to, the specified ContextNode. False otherwise.
>= Greater than or equal to
True if the given ContextNode is an ancestor of, or equal to, the specified
ContextNode. False otherwise False otherwise.
<= Less than or equal to
True if the given ContextNode is a descendant of, or equal to, the specified
ContextNode. False otherwise.
431
[R XXX]
The predicates MUST be represented as: (=, !=, >, <, >=, <=) where:
= is Equal, != is Not equal, > is Greater than, > is Less than, >= is
Greater than or equal to, and <= is Less than or equal to.
1
432 7.2.2
Operator
433
434
435
436
An operator is used within a CompoundContextClause to combine the results of a pair of ContextClauses. An operator is a function that matches a given
ContextNode using two ContextClauses. The individual boolean results from the two ContextClauses are combined to produce a single boolean result.
437 Allowed operators and their meaning (with notation):
Operator Short Name Meaning
&&
||
Intersection True if both ContextClauses return true for the given ContextNode. False otherwise.
Union True if either ContextClause returns true for the given ContextNode. False otherwise.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 26 of 34
UCM Draft A6 01 October 2009
Operator Short Name Meaning
!! Exclusion True if the first ContextClause returns true and the second ContextClause returns false for the given ContextNode. False otherwise.
438
[R XXX]
The operands MUST be represented as: (&&, ||, !!) where && is
Intersection, || is Union, !! is Exclusion.
439
1
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 27 of 34
440
UCM Draft A6 01 October 2009
441
442
443
8 Defining and Using Business Context
[Ed. Note] - Insert revised figure here
Figure 8-1 UCM Metamodel
444
445
446
447
448
449
450
Context Use is the act of assigning, calculating, or applying context to an object, process or other artifact to fully define its particular business meaning and use. Create a contextualized. A contextualized exists at design time – library creation and syntax binding – and is subject to further contextualization at run time.
Definition - Contextualized
A contextualized is an object whose context has been defined through association with a ContextExpression
A Contextualized MUST be associated with a ContextExpression.
[R XXX] 1
451
452
453
454
[Example] – Contextualized - Aggregate Business Information Entities (ABIEs),
Association Business Information Entities (ASBIEs), Basic Business Information Entities
(BBIEs) and Business Data Types (BDTs) are examples of a Contextualized. Other types of objects also may be contextualized.
455
8.1
Design Time Use
456 Design time Context Use includes both assigning context and calculating context.
457 8.1.1
Assign Context –
458
459
460
461
462
Context can be assigned to an object, process or other artifact to fully define its particular business meaning and use.
Definition – AssignContext
The action of associating a ContextExpression to an object, process or other artefact
463 Context Assignment creates a Contextualized.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 28 of 34
UCM Draft A6 01 October 2009
464
465
466
467
8.1.1.1
Assigning context to BBIEs
Context is assigned to a BBIE by walking through the graph and identifying all nodes that apply and creating and assigning a ContextExpression that includes simple or complex clauses
468 8.1.1.2
Assigning context to ASBIEs
469
470
Context is assigned to an ASBIE by the same process. The ASBIE ContextExpression further restricts the context expression of the associated ABIE (See calculated)
471 8.1.2
Calculate Context
472
473
474
475
476
477
478
CalculateContext is created through union or intersection of the context expression for each contextualizable property. Arriving at a calculated context requires traversing the relationships between libraries in order to process the context values for each object that can be resolved from the context expressions.
Definition – CalculateContext
The action of calculating a ContextExpression of an object, process or other artefact by considering all of its relationships
479 8.1.2.1
Calculate Context for an ABIE
480
481
An ABIE context is calculated by creating a ContextExpression that is the set of the unique nodes of the lower level BBIEs and ASBIEs.
482 8.1.2.2
Calculating an Associated ABIE Context
483
484
485
486
487
488
An associated ABIE is a lower level property of an ASBIE. As a standalone object, the
ABIE has a calculated context based on its properties per 8.1.2.1. However that calculated context is further refined by restricting it to the intersection with the context expression of its owning ASBIE. The ASBIE filters the context values of the associated
ABIE and its lower level properties (BBIEs and ASBIEs) to only those allowed by the context expression of the ASBIE.
489
8.2
Run Time Context Use
490
491
Run time Context Use is the application of context for generation of an instance of a business payload.
492 8.2.1
Apply Context
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 29 of 34
UCM Draft A6 01 October 2009
493
494
495
496
Apply Context is refining the context expression of a modeled business payload. This application of context for a specific business situation is the action of resolving a set of
Contextualized objects by applying a ContextExpression against the global set of
Contextualized objects.
497
498
499
500
501
The application of context is accomplished by evaluating the simple context clauses to return a set of Contextualized. The ContextClause is first evaluated against the
ContextGraph to return a set of ContextNodes. The set of ContextNodes is then used to query the global set of Contextualized to return the set of all Contextualized that is assigned any of the returned ContextValues.
502 8.3
Example Implementation
D E
B C
F
503
504
505
A
I
H
G
J
Figure 8-2. DAG example identified by urn:un:unece:uncefact:context:draft:20091001682ba7e31f26 version 1.0
Contextualized
Assignment
ContextClause Assigned Context
Contextualized1 (=,A)
Contextualized2 (<=,B)
A
B, C, D, E, F, H, I, J
Contextualized3 (<=,A) A, B, C, D, E, F, G, H, I, J
Contextualized4 (((<,A)!!(<=,H))||(=,I)) B, C, D, E, F, G, I
Contextualized5 (=,C)
Contextualized6 ((<=,H)!!(=,I))
Contextualized7 ((>=,H)!!(=,G))
C
H, J
A, B, H
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 30 of 34
UCM Draft A6 01 October 2009
506 Table 8-1. Assigning Context the Assignment ContextClause and the resulting Assigned Context
Applied
ContextClause
(=,A)
((=,A)!!(=,B))
((=,A)&&(=,B))
((=,I)||(=,J))
Processing Description Results
Create a set of all Contextualized
Contextualized that have ‘A’ assigned as a
Contextualized1,
Contextualized3,
ContextNode Contextualized7
Create a set of all Contextualized
Contextualized that have ‘A’ assigned as a
Contextualized1
ContextNode and then Exclude all
Contextualized from the set that have ‘B’ assigned as a ContextNode.
Create a set of all Contextualized Contextualized3,
Contextualized that have ‘A’ assigned as a Contextualized7
ContextNode then create a set of all
Contextualized that have ‘B’ assigned as a
ContextNode and then perform an intersection of the two sets.
Create a set of all Contextualized
Contextualized that have ‘I’ assigned as a
ContextNode then create a set of all
Contextualized that have ‘J’ assigned as a
Contextualized4,
Contextualized6
ContextNode and then perform a union of the two sets.
Contextualized2,
Contextualized3,
507 Table 8-2. Results of Applying Context
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 31 of 34
UCM Draft A29 03 February 2010
508
509
510
511
512
513
514
515
516
517
518
9 Glossary
[Ed Note – to be finalized during ODP4]
Context Methodology – already in the document
Classification Scheme – TBD
Modeling dimension - TBD
Semantic Modeling – TBD
Type/Value-Domain – TBD
519
520
521
522
523
524
525
526
527
528
529
BIE/BDT Contextualized Profile – wait for Gunther
Classification - distinguish it from other more generic meanings of it, to be discussed in the con call
Payload – TBD
530
531
Contextual Instance Payload - TBD
Profile definitions:
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 32 of 34
UCM Draft A6 01 October 2009
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
ClassificationScheme – it is in the CCTS spec and echoed in the UN/CEFACT
Glossary; maybe ClassificationMechanism is better?
ClassificationArea – space appropriate for classifying business information; change to ContextCategory for now.
Classifiable – TBD
Merged Model definitions:
Business Context – use current definition from the CCTS spec
Context –
Context Category – use current definition from the CCTS spec
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2009
. All Rights Reserved.
Page 33 of 34
UCM Draft A29 03 February 2010
548
549
Copyright Statement
Copyright © UN/CEFACT 2010. All Rights Reserved.
550
551
552
553
554
555
556
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.
557
558
The limited permissions granted above are perpetual and will not be revoked by
UN/CEFACT or its successors or assigns.
559
560
561
562
563
564
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.
UN/CEFACT Context Methodology Technical Specification
Copyright © UN/CEFACT 2010
. All Rights Reserved.
Page 34 of 34
