Core-Components-Technical-Specification-Ver-1PT6

UN/CEFACT DRAFT United Nations Centre for Trade Facilitation and Electronic Business 1 10 11 12 13 Core Components Technical Specification, Part 12 October 2001 Version 1.6 2UN/CEFACT Core Component Technical Specification 3Tuesday, October 18, 2022 Page 1of 84 5Core Components 141 October 2001 Status of This Document 15 16This Technical Specification is being developed in accordance with 17UN/CEFACT/TRADE/22 Open Development Process It has been approved by the 18eBTWG Core Component Project Team for first draft public release for comment as 19defined in Step of the Open Development Process 20 21This document contains information to guide in the interpretation or implementation 22of ebXML concepts 23 24Distribution of this document is unlimited 25 26The document formatting is based on the Internet Society’s Standard RFC format 27 28This version: Core Components Technical Specification, Version 1.6 of 12 October 292001 30 6UN/CEFACT Core Component Technical Specification Page of 84 9Core Components 10 312 October 2001 eBTWG CC Project Team Participants 32We would like to recognize the following for their significant participation to the 33development of this document 34 35Project Team Leader: Hartmut Hermes Siemens 36Lead Editor: Mark Crawford Logistics Management Institute 37Editing Team Mike Adcock APACS 38 James Whittle e Centre 39 Alan Stitzer Marsh, Inc 40 41Contributors: Mary Kay Blantz Iona Technologies 42 Sue Probert CommerceOne 43 Stig Korsgaard Danish Bankers Association 44 Andreas Schultz GDV 45 Arofan Gregory CommerceOne 46 Marianne Cockle APACS 47 Frank VanDamme SWIFT 48 Eduardo Gutentag Sun Microsystems 49 Paula Heilig Worldspan 50 Lisa Seaburg CommerceOne 51 Nigel Wooden Accord 52 Gunther Stuhec SAP AG 53 Hisanao Sugamata ECOM-Japan 54 James Wearner Boeing 55 Alain Dechamps CEN/ISSS 56 Kerstein Celis Seagha c.v 57 Bill Murray General Motors 58 Tom Warner Boeing 59 Scott Coulthurst State Farm 60 Dale McKay Logicon/Northrop Grumman 61 Richard May Marsh, Inc 62 Herbert Thomas AustriaPro 63 Bernd Boesler DIN 64 Margaret Pemberton Diskray 65 Joe Zurlo LMI 66 67 68 69 70 71 72 11UN/CEFACT Core Component Technical Specification 12Tuesday, October 18, 2022 13 Page 3of 84 14Core Components 15 733 741 752 763 774 78 79 80 81 82 835 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 1016 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 October 2001 Table of Contents Status of This Document eBTWG CC Project Team Participants Table of Contents Introduction 4.1 Intended Audience 4.2 Structure of this Specification 4.2.1 Notation 4.3 Related Documents 4.4 Executive Summary .8 Working Process and Methodology 13 5.1 Discovery 13 5.2 How to use UN/CEFACT Core Components .14 5.2.1 Core Components and Semantic Interoperability 14 5.2.2 Core Components Discovery Steps 18 5.2.2.1 Core Component Discovery - Preparation Steps 18 5.2.2.2 Core Components Discovery  Search Repository 20 5.3 Submission 21 5.3.1 Applying the Naming Convention to a New Item 22 5.3.2 Submitting New Aggregate Core Components 25 5.3.3 Preparation Steps for Requesting a New Basic Core Component .26 5.3.4 Preparation for Requesting a New ABIE which re-uses an Existing Aggregate Core Component .26 5.3.5 Harmonisation 27 5.3.6 Technical Assessment and Approval 28 5.3.7 Context in the Discovery Process .29 5.3.7.1 Guidelines for Analysing BIEs in Context .29 5.3.7.2 Context Categories 30 Technical Details 34 6.1 Core Components and Business Information Entities 34 6.1.1 Core Components .34 6.1.2 Business Information Entities 39 6.1.3 Naming Convention 40 6.1.3.1 Dictionary Information 41 6.1.3.2 Rules .41 6.1.3.2.1 General Rules 41 6.1.3.2.2 Rules for Definitions 42 6.1.3.2.3 Rules for Dictionary Entry Names 42 6.1.3.2.4 Rules for Business Terms 44 6.1.3.3 List of Representation Terms 44 6.1.4 Catalogue of Core Components 46 6.1.5 Catalogue of Business Information Entities .47 6.2 Context .47 6.2.1 Overview of Context Specification 47 6.2.1.1 Approved Context Categories 48 6.2.1.2 Constraint Language 49 6.2.1.3 Syntax Binding .50 6.2.2 Context Categories Specification .50 16UN/CEFACT Core Component Technical Specification 17Tuesday, October 18, 2022 18 Page 4of 84 19Core Components October 2001 121 6.2.2.1 Business Process Context .50 122 6.2.2.1.1 Recommended Sets of Values 50 123 6.2.2.2 Product Classification Context .50 124 6.2.2.2.1 Recommended Sets of Values 51 125 6.2.2.3 Industry Classification Context 51 126 6.2.2.4 Geopolitical Context 51 127 6.2.2.5 Official Constraints Context 52 128 6.2.2.6 Business Process Role Context 53 129 6.2.2.7 Supporting Role Context 53 130 6.2.2.8 System Capabilities Context 53 131 6.2.3 Context Values 53 132 6.2.4 Constraints Language 53 133 6.2.4.1 Notes about Assembly 59 134 6.2.4.2 Notes about Context Rules .59 135 6.2.4.3 Output Constraints 60 136 6.2.4.4 Ordering and Application .60 1377 Technical Details - Core Component Repository Storage 61 138 7.1 Storing Core Components 61 139 7.2 Storing Classes and Attributes 63 140 7.2.1 Supplementary Component Value 64 141 7.2.2 Value Component .64 142 7.2.3 Value Component Restriction .65 143 7.3 Description of diagram .66 144 7.4 Definition of all Classes and Attributes 67 145 7.4.1 Business Context 67 146 7.4.2 Context categories 67 147 7.4.3 Context categories Scheme 67 148 7.4.4 Context Value .67 149 7.5 Description of diagram .68 150 7.6 Definition of all Classes and Attributes 69 151 7.6.1 Aggregate Business Information Entity (ABIE) 69 152 7.6.2 Aggregate Core Component (ACC) 69 153 7.6.3 Assembly Component 69 154 7.6.4 Assembly Data Type 70 155 7.6.5 Basic Business Information Entity (BBIE) 70 156 7.6.6 Basic Core Component (BCC) 70 157 7.6.7 BBIE Data Type 70 158 7.6.8 Business Context 70 159 7.6.9 Business Information Entity .70 160 7.6.10 Core Component 71 161 7.6.11 Data Type 71 162 7.6.12 Supplementary Component Value 71 163 7.6.13 Value Component Restriction .71 164 7.7 Core Component Storage Metadata 72 165 7.8 Description of diagram .72 166 7.9 Definition of all Classes and Attributes 73 167 7.9.1 Administrative Information 73 168 7.9.2 Association Information .73 169 7.9.3 Change History 74 170 7.9.4 Descriptive Information .74 20UN/CEFACT Core Component Technical Specification 21 Page of 84 22 23Core Components October 2001 171 7.9.5 Replacement Information 74 172 7.9.6 Representation Information 74 173 7.9.7 Status Information 75 1748 Definition of Terms 76 1759 Disclaimer 80 17610 Contact Information .81 177Copyright Statement 82 178 179 180 181 24UN/CEFACT Core Component Technical Specification 25 Page of 84 26 27Core Components 1824 October 2001 Introduction 183This Core Components technical specification describes and specifies a new approach 184to the well-understood problem of the lack of interoperability between applications in 185the e-business arena Traditionally, standards for the exchange of business data have 186been focused on static message definitions that have not enabled a sufficient degree of 187inter-operability or flexibility A more flexible and inter-operable way of standardising 188business semantics is required The UN/CEFACT Core Component solution described 189in this technical specification presents a methodology for developing a common set of 190semantic building blocks that represent the general types of business data in use today 191 192The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 193SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 194this document, are to be interpreted as described in Internet Engineering Task Force 195(IETF) Request For Comments (RFC) 2119.1 1964.1 Intended Audience 197The target audience for this document includes business analysts, business users and 198information technology specialists supplying the content of and implementing 199applications that will employ the UN/CEFACT Core Component Library (CCL) 200 201Due to the evolving nature of the UN/CEFACT Core Component Library, the 202specification includes material that focuses on the business community doing further 203discovery and analysis work Some of the contents of this specification are not typical 204of this type of technical document However, they are critical for successful adoption 205and standardisation in this area to move forward 2064.2 Structure of this Specification 207Due to the diversity of the intended audience, this document has been divided into 208three main Sections and an Appendix 209 210 Section 5: Working Process and Methodology for Business UsersDiscovery, 211 Harmonisation, Assessment and How to Use 212 Section 6: Technical DetailsCore Components and Context 213 Section 7:Technical DetailsStorage and Metadata 214 Appendix A contains a full glossary of terms 215 216Sections 5, and are complementary, but may also be used independently of each 217other Section is informative A business audience may choose to read through the 218working process and methodology section (Section 5) and only reference the 219Technical Details (Sections and 7) as needed Sections and are normative A 220technical audience may choose to focus on the technical details (Sections and 7), 221referring to the methodology (Section 5) and example (Part 2) sections as appropriate, 222using the glossary (Section 9) Reference Documents 223 224In addition, the Core Components Team has prepared Core Components Technical 225Specification, Parts and Part 2Core Components Primer details how the 226contents of Sections 5, 6, and would be used Part 3Catalog of Discovered Core 28UN/CEFACT Core Component Technical Specification 29 Page of 84 30 31Core Components October 2001 227Components represents work of various organisations working in a joint endeavor to 228develop a beginning catalog of core components 2294.2.1 Notation 230[Definition] - a formal definition of a term 231[Ed Note] - A note from the editing team indicating where additional work is required 232before the document becomes final 233[Example] - A representation of a definition or a rule 234[Issue] - A recorded issue 235[Note] 236[Rn: where n (1 n) indicates the sequential number of the rule] - Identification of a 237rule that requires conformance to ensure discovered core components are properly 238discovered, named and stored 239 240[Ed Note - The rules designators still need corrected throughout the document to 241conform to the above] 2424.3 Related Documents 243The following documents provided significant levels of influence in the development 244of this document: 245  ebXML Technical Architecture Specification v1.04 249  ebXML Business Process Specification Schema v1.01 250  ebXML Registry Information Model v1.0 251  ebXML Registry Services Specification v1.0 252  ebXML Requirements Specification v1.06 253  ebXML Collaboration-Protocol Profile and Agreement Specification v1.0 254  ebXML Message Service Specification v1.0 255ebXML Technical Reports 256  Business Process and Business Information Analysis Overview v1.0 257  Business Process Analysis Worksheets & Guidelines v1.0 - 258  E-Commerce Patterns v1.0 259  Catalog of Common Business Processes v1.0 260  Core Component Overview v1.05 261  Core Component Discovery and Analysis v1.04 262  Context and Re-Usability of Core Components v1.04 263  Guide to the Core Components Dictionary v1.04 264  Naming Convention for Core Components v1.04 265  Document Assembly and Context Rules v1.04 266  Catalogue of Context categoriess v1.04 267  Core Component Dictionary v1.04 32UN/CEFACT Core Component Technical Specification 33 Page of 84 34 35Core Components 268 October 2001  Core Component Structure v1.04 2694.4 Executive Summary 270This Core Component technical specification provides a mechanism for identifying 271business situations uniquely, and associating semantic refinements and modifications 272to the building blocks with the business situation they support All of the information 273about what data is required in which situation can be expressed in a human-readable 274and machine-processable way by trading partners, standards organisations, and other 275business message creators 276 277The system is more flexible than current standards in this area because the semantic 278standardisation is done in a syntax-neutral fashion UN/CEFACT can guarantee that 279two trading partners using different syntaxes (e.g XML and EDIFACT) are using 280business semantics in the same way This enables clean mapping between disparate 281message definitions across syntaxes, industry and regional boundaries 282 283UN/CEFACT BP and CC solutions capture a wealth of metadata about the business 284reasons for variation in message semantics and structure In the past, these variations 285have produced incompatibilities The core components mechanism uses this rich 286metadata to allow easy identification of exact similarities and differences between 287semantic models Incompatibility becomes incremental rather than wholesale, i.e the 288detailed points of difference are noted, rather than a whole model being dismissed as 289incompatible 290 291The key concepts in the Core Components Technical Specification are: 292 293 294  Core Component  A technical specification for creating a core component library is provided The Core Component is a semantic building block that is used to construct all electronic business messages 295 296 297 298  Context – Context is a mechanism for classifying business situations Once business contexts are identified, the appropriate core components can be selected or created and differentiated to indicate any necessary qualification and refinement needed to support the business process 299 300 301 302  Business Information Entity –When a Core Component is used in a real business situation it is used to define a Business Information Entity The BIE is the result of using a core construct within a specific business context 303 304 305 306  Repository Metadata – Core Components, Context Categories and Business Information Entities along with syntax bound business message descriptions are available in the repository The relationships between these objects are stored to encourage standard use and re-use at all levels 307 Figure 4-1 shows the relationships between the three categories of Core Components: 308 Basic Core Component, Core Component Type and Aggregate Core Component 309 The following definitions explain each of these: 310[Definition] Core Component (CC) 36UN/CEFACT Core Component Technical Specification 37 Page of 84 38 39Core Components October 2001 311 312A building block for the creation of a semantically correct and meaningful 313information exchange ‘parcel’ It contains only the information pieces necessary to 314describe a specific concept 315 316 317[Definition] Basic Core Component (BCC) 318 319A Core Component that represents a singular business concept with a unique business 320semantic definition A BCC is constructed by using a Core Component Type BCCs 321are used in developing Aggregate Core Components 322 323[Definition] Aggregate Core Component 324 325A collection of pieces of business information that together form a single business 326concept (e.g postal address) Each Aggregate Core Component has its own unique 327business semantic definition and can contain either: 328 two or more Basic Core Components, or 329 at least one Basic Core Component plus one or more Aggregate Core Components 330 331[Example] - Aggregate Core Components 332 333account details, party details 334 335Figure 4-1 Core Component Overview 336 without business semantics Core Component Consists of Type (CCT) with known business semantics Value Component 1-n Supplementary Component Used in Basic Core Component Aggregated in 337 338 339 Aggregate Core Component 40UN/CEFACT Core Component Technical Specification 41 Page 10 of 84 42 284Core Components October 2001 Business Information Entities Full Definition < Defines Aggregate Business Information Entity (ABIE) Aggregate Core Component (ACC) * ABIE Type 1 ABIE Rule * Business Context Is Based On Is a Is a > Defines * * Assembly Component Business Information Entity (BIE) Core Component Dictionary Entry Name 1 Definition 1 MinOccur 1 MaxOccur 1 Name Sequence Number Business Term * Example * Definition : Text Name Is Derived From * Is Based On Is a Is Of Type Is a Defines Basic Core Component (BCC) 1 Basic Business Information Entity (BBIE) Assembly Data Type * Data Type Name 1 * * Is Of Type * Data Type Is Derived From Data Type Name 1 * BBIE Data T ype Data Type Name 1 * * Applies To Applies To * Value Component Restriction * Restriction T ype 1 Restriction Value 1 Supplementary Component Value Value 1 Meaning 1 * Is Derived From Applies To * Applies To * 1840 18417.5 Description of diagram 1842This diagram describes the types of Business Information Entities and their 1843relationships A Business Information Entity is defined as "a piece of business data or 1844a group of pieces of business data with a unique business semantic definition in a 1845specified business context" 1846A Business Information Entity is always of one of the following types: 1847 1848 1849  A "Basic Business Information Entity" (BBIE) is a piece of business information with a unique concept having a single business semantic definition in a specified business context 1850 1851 1852  An "Aggregate Business Information Entity" (ABIE) is a collection of related pieces of business information that together convey a distinct business meaning in a specified business context 285UN/CEFACT Core Component Technical Specification 286 Page 70 of 84 287 288Core Components October 2001 1853A Business Context is defined as a unique combination of values for all defined 1854Context Categories For a given business context it is possible to define business 1855terms and examples, to specify an alternative definition and name and to restrict the 1856data type (only for BBIE) 1857All BBIEs that relate to the same context-free concept form the basis of the definition 1858of a BCC 1859All ABIEs that relate to the same context-free concept form the basis of the definition 1860of an ACC 1861An ABIE is either a sequence or a choice and will consist of two or more Assembly 1862Components, which are either BBIEs or ABIEs Each Assembly Component has a 1863certain cardinality (i.e it is mandatory, optional and/or repetitive) and - in case of a 1864sequence - a sequence number When used as an Assembly Component, it is possible 1865to change the name of the composing ABIE or BBIE and to restrict the data type of a 1866composing BBIE 18677.6 Definition of all Classes and Attributes 18687.6.1 Aggregate Business Information Entity (ABIE) 1869Definition: 1870Aggregate Business Information Entity (ABIE) is a collection of related pieces of 1871business information that together convey a distinct business meaning in a specified 1872business context 1873Attributes: 1874ABIE Type 1: ABIE Type indicates whether the composing components of the 1875ABIE form a sequence (i.e all composing components may occur when the ABIE is 1876used) or a choice (i.e only one of the composing components may occur when the 1877ABIE is used) 1878ABIE Rule *: ABIE Rule describes a restriction that relates to various Assembly 1879Components of the ABIE 18807.6.2 Aggregate Core Component (ACC) 1881Definition: 1882An Aggregate Core Component (ACC) is a collection of Core Components that 1883conveys a distinct business meaning An ACC will consist of two or more Basic Core 1884Components, or at least one Basic Core Component plus one or more Aggregate Core 1885Components 18867.6.3 Assembly Component 1887Definition: 1888An Assembly Component is either a ABIE or a BBIE that is a component of an ABIE 1889It specifies the cardinality and possibly the alternative name and the sequence number 1890to be used 1891Attributes: 1892MinOccur 1: Minimum number of occurrences that a composing BIE must occur 1893when used in an ABIE If the minimum is zero, the component is optional If the 1894minimum is one or more, the component is mandatory 1895MaxOccur 1: Maximum number of occurrences that a composing BIE may occur 1896when used in an ABIE If the maximum is zero, the component is not allowed If the 289UN/CEFACT Core Component Technical Specification 290 Page 71 of 84 291 292Core Components October 2001 1897maximum is more than one, the component is repetitive Remark that the defined 1898maximum must always be greater than or equal to the defined minimum 1899Name 1: Optional alternative name to be used for a BIE when used in an ABIE 1900Sequence Number 1: Position of the Assembly Component in an ABIE of type 1901Sequence 19027.6.4 Assembly Data Type 1903Definition: 1904An Assembly Data Type defines the set of valid values that can be used for a 1905particular BBIE when used in a particular ABIE It is defined by specifying 1906restrictions on the Value Component and Supplementary Components 1907Attributes: 1908Data Type Name 1: Official name of the Data Type 19097.6.5 Basic Business Information Entity (BBIE) 1910Definition: 1911A Basic Business Information Entity (BBIE) is a piece of business information with a 1912unique concept having a single business semantic definition in a specified business 1913context 19147.6.6 Basic Core Component (BCC) 1915Definition: 1916A Basic Core Component (BCC) is a Core Component with a unique concept having a single 1917business semantic definition It must be constructed by using a Core Component Type 19187.6.7 BBIE Data Type 1919Definition: 1920A BBIE Data Type defines the set of valid values that can be used for a particular 1921BBIE It is defined by specifying restrictions on the Value Component and 1922Supplementary Components 1923Attributes: 1924Data Type Name 1: Official name of the Data Type 19257.6.8 Business Context 1926Definition: 1927Combination of values for Context categories, defining a unique and meaningful 1928business context 19297.6.9 Business Information Entity 1930Definition: 1931A Business Information Entity (BIE) is a piece of business data or a group of pieces of 1932business data with a unique business semantic definition in a specified business 1933context A BIE will either be a Basic Business Information Entity (BBIE) or an 1934Aggregate Business Information Entity (ABIE) 1935Attributes: 1936Business Term *: A synonym term under which the Core Component is commonly 1937known and used in the business A Core Component may have several business terms 1938or synonyms 293UN/CEFACT Core Component Technical Specification 294 Page 72 of 84 295 296Core Components October 2001 1939Example *: An example of a possible value of a Core Component in a given 1940business context 1941Definition 1: Context dependent definition of a Core Component 1942Name 1: Context dependent name of a Core Component 19437.6.10 Core Component 1944Definition: 1945A Core Component is a building block for the creation of a semantically correct and 1946meaningful information exchange 'parcel' It contains only the information pieces 1947necessary to describe a specific concept A Core Component will always be defined as 1948a Basic Core Component, a Core Component Type, or an Aggregate Core Component 19497.6.11 Data Type 1950Definition: 1951A Data Type defines the set of valid values that can be used for a particular BCC It is 1952defined by specifying restrictions on the CCT that forms the basis of the 1953Representation Term from which the Data Type is derived 19547.6.12 Supplementary Component Value 1955Definition: 1956A Supplementary Component Value defines an enumerated list of possible values of a 1957Supplementary Component This will only exist if the values can be defined by an 1958enumeration (e.g list of quantity units) 1959The list of possible values can be further restricted when a Core Component Type is 1960used for a particular Basic Component Example: the Core Component Type 1961"Quantity" has a supplementary component "Quantity Unit" with possible values like 1962gram and second A Basic Component like "Person Weight Quantity" will not accept 1963"second" as quantity unit 1964The list can still be further restricted when used in a particular context 1965Attributes: 1966Value 1: Value is a possible value of a Supplementary Component 1967Meaning 1: Meaning describes the meaning of the Supplementary Component 1968when it has a particular Value 19697.6.13 Value Component Restriction 1970Definition: 1971A Value Component Restriction defines a format restriction that applies to the 1972possible values of a Value Component This will only exist if the values can be 1973defined by a format restriction (e.g string pattern, minimum or maximum length, 1974enumeration, ) 1975Attributes: 1976Restriction Type 1: Restriction Type defines the type of format restriction that 1977must be applied to the Value Component Possible values include pattern, length, 1978minimum length, maximum length, enumeration, etc 1979Restriction Value 1: Restriction Value is the actual value of the Restriction Type 1980that applies to a Value Component The possible values depend on the restriction type 1981(e.g integer for a "length" restriction type, list of possible values for an "enumeration" 1982restriction type, ) 297UN/CEFACT Core Component Technical Specification 298 Page 73 of 84 299 300Core Components October 2001 1983 1984 1985 19867.7 1987 Core Component Storage Metadata Repository Metadata Replacement Information Replacement Description 1 : Text Replacement Date 1 : Date * Has As Previous Version Status Information Status 1 : Code Start Date 1 : Date Reason : Text Reference * : Document Comment * : Comments Replaced by 1 Is a Core Component Repository Element UID 1 Version 1 Dictionary EntryName 1 Definition 1 Usage Rule * * * Administrative Information Registrar 1 Registration Authority 1 : Organisation Submitting Organisation 1 : Organisation Is a Descriptive Information Comments * : Comments Reference Document * : Document Acronym * Keyword * * Business Information Entity (BIE) Associated To * Representation Information Representation Syntax 1 : Syntax Representation 1 : String Constraint * : String Change History Change Type 1 Change Date 1 : Date Change Description 1 : Text Request By 1 : Organisation Request Date 1 Comment * : Comments Reference * : Document Association Information Association Description 1 : Text Association Type 1 : Code Association Multiplicity 1 : Code Start Date 1 : Date End Date 1 : Date Comment * : Comments 1988 1989[Ed Note - Frank to provide updated diagram that includes context as repository element] 19907.8 Description of diagram 1991This diagram focuses on the "meta-information" that needs to be defined for a 1992Repository Element (i.e all information needed to store for Core Components and for 1993Business Information Entities) To simplify the diagram all information regarding the 1994structure of a Core Component and a Business Information Entity has been hidden 1995The diagram contains following information: 1996 1997Version Information: even though at any given point in time only one version of a 1998Repository Element can be valid, multiple previous versions my have existed and a 1999future version may be in preparation The "Version" association makes it possible to 301UN/CEFACT Core Component Technical Specification 302 Page 74 of 84 303 304Core Components October 2001 2000link the consecutive versions of a Repository Element Remark that we don't envisage 2001to have branches in the versioning: only a linear versioning will be supported 2002 2003Replacement Information: a Repository Element may be replaced by another 2004Repository Element at some point in time (e.g because a duplicate is discovered) The 2005"Replaced by" association makes it possible to this and "Replacement Information" 2006makes it possible to document the date and reason of replacement 2007 2008Status Information: information about the live status of a Repository Element (i.e to 2009indicate whether the Repository Element can be used or not) 2010 2011Administrative Information: information about the registration of the Repository 2012Element 2013 2014Descriptive Information: additional descriptive information about a Repository 2015Element, giving further clarification about its meaning 2016 2017Change History: information about all changes that are made to a Repository Element 2018 2019Association Information: a Repository Element may be associated to multiple other 2020Repository Elements (e.g to indicate that there is a relation between an Organisation 2021ands a Postal Address) The "Associated To" association can be used for this and 2022"Association Information" can be used to document additional information about the 2023association 2024 2025Representation Information: information about the physical representation of a 2026Repository Element in a particular syntax (e.g to document the XML-tag) 20277.9 Definition of all Classes and Attributes 20287.9.1 Administrative Information 2029Definition: 2030Administrative information regarding a Repository Element 2031Attributes: 2032Registrar 1: Name of the responsible person who has created the Repository 2033Element in the repository 2034Registration Authority 1: Organisation authorised to register the Repository 2035Element 2036Submitting Organisation 1: The organisation that has submitted / requested the 2037Repository Element 20387.9.2 Association Information 2039Definition: 2040Information about the association (i.e relation) between two Repository Elements 2041Attributes: 2042Association Description 1: Descriptive text explaining the meaning of the 2043association 2044Association Type 1: Type of association (e.g aggregation, specialisation, ) 2045Association Multiplicity 1: Cardinality of the association 305UN/CEFACT Core Component Technical Specification 306 Page 75 of 84 307 308Core Components October 2001 2046Start Date 1: Date at which the association becomes valid 2047End Date 1: Date from which the association is no longer valid 2048Comment *: Relevant information about the association (e.g reason why it has 2049been removed, ) 20507.9.3 Change History 2051Definition: 2052History of all modifications applied to a Repository Element version 2053Attributes: 2054Change Type 1: Purpose of the Change 2055Change Date 1: Date on which the modification has been made 2056Change Description 1: Description of why and how the Repository Element has 2057been modified 2058Request By 1: Name of the organisation that has requested the modification of the 2059Repository Element 2060Request Date 1: Date on which the modification was requested 2061Comment *: Remark about the Repository Element modification 2062Reference *: Document containing relevant information about the modification 20637.9.4 Descriptive Information 2064Definition: 2065Additional descriptive information about a Repository Element, giving further 2066clarification about its meaning 2067Attributes: 2068Comments *: Comments is additional information about a Repository Element, 2069which is not part of the definition but that is considered relevant for clarification 2070Reference Document *: Reference Document is a reference (e.g URL) to external 2071documentation that contains relevant additional information about a Repository 2072Element 2073Acronym *: Acronym is an abbreviation or code under which the Semantic 2074Information Component is commonly known 2075Keyword *: Keyword is one or more significant words used for the search and 2076retrieval of a Semantic Information Component 20777.9.5 Replacement Information 2078Definition: 2079Information about the reason and timing of the replacement of a Repository Element 2080by another 2081Attributes: 2082Replacement Description 1: Reason for the Repository Element being replaced 2083Replacement Date 1: Date from which the replacement is effective 20847.9.6 Representation Information 2085Definition: 2086Information about the physical representation of a Repository Element in a particular 2087syntax 2088Attributes: 2089Representation Syntax 1: Identification of the representation syntax 309UN/CEFACT Core Component Technical Specification 310 Page 76 of 84 311 312Core Components October 2001 2090Representation 1: Physical representation of the Repository Element (e.g XML2091tag) 2092Constraint *: Description of additional constraints that apply to the representation 2093of the Repository Element in the given syntax (e.g maximum length, ) 20947.9.7 Status Information 2095Definition: 2096History of the status lifecycle of a particular version of a Repository Element 2097Attributes: 2098Status 1: Status of the Repository Element (i.e draft, provisionally registered, 2099registered, retired, ) 2100Start Date 1: Date on which the status comes into effect 2101Reason 1: Description of why the Repository Element status has been changed 2102Reference *: Document containing relevant information about the status change 2103Comment *: Remark about the Repository Element status 2104 313UN/CEFACT Core Component Technical Specification 314 Page 77 of 84 315 316Core Components 317 2105Definition October 2001 of Terms 2106 2107Aggregate Business Information Entity - (ABIE) A collection of related pieces of 2108business information that together convey a distinct business meaning in a specified 2109business context 2110 2111Aggregate Composition Value Restriction - A Restriction on the possible values for 2112a Supplementary Component of a Core Component Type when the corresponding 2113Basic Information Entity is used indirectly (i.e via another Aggregate Information 2114Entity) in an Aggregate Information Entity 2115 2116Example: 2117 The Basic Information Entity "Financial Account.Country.Identifier" could 2118 restrict the allowed value of the "Identification.Scheme.Name" to "ISO list of 2119 country codes." 2120 Remarks: 2121 There are two possibilities: 2122 If the value of the Supplementary Component is fixed the Representation 2123 Term can be specialised (e.g "ISO Country Identifier") 2124 If the value of the Supplementary Component is not fixed, the user will 2125 have to specify the value of the Supplementary Component each time he 2126 uses the Basic Information Entity 2127 2128 2129Aggregate Core Component - (ACC) —A collection of Core Components that 2130convey a distinct business meaning An ACC will consist of two or more Basic Core 2131Components, or at least one Basic Core Component plus one or more Aggregate Core 2132Components 2133 2134Aggregate-Aggregate Composition Information - Specifies additional information 2135when an Aggregate Information Entity is used in another Aggregate Information 2136Entity This gives the ability to define the cardinality of the component in the 2137aggregate as either mandatory, optional, repetitive 2138 2139Aggregate-Aggregate Context Information – The Influence of a particular context 2140on the additional information when an Aggregate Information Entity is used in 2141another Aggregate Information Entity 2142 2143Aggregate-Basic Composition Information - Specifies additional information when 2144the Basic Information Entity is used in an Aggregate Information Entity 2145 2146Basic Business Information Entity - A Basic Business Information Entity is derived 2147from a Basic Core Component 2148 2149Basic Composition Value Restriction - Restriction on the possible values for a 2150Supplementary Component of a Core Component Type when the corresponding Basic 2151Information Entity is used in an Aggregate Information Entity 2152 318UN/CEFACT Core Component Technical Specification 319Tuesday, October 18, 2022 320 Page 78of 84 321Core Components October 2001 2153Example: 2154 The Basic Information Entity "Financial Account.Country.Identifier" could 2155 restrict the allowed value of the "Identification.Scheme.Name" to "ISO list of 2156 country codes." 2157 Remarks: 2158 There are two possibilities: 2159 o If the value of the Supplementary Component is fixed the 2160 Representation Term can be specialised (e.g "ISO Country 2161 Identifier") 2162 o If the value of the Supplementary Component is not fixed, the user will 2163 have to specify the value of the Supplementary Component each time 2164 he uses the Basic Information Entity 2165 2166Basic Core Component - A Core Component with a unique concept having a single 2167business semantic definition It must be constructed by using a Core Component Type 2168 2169Basic-Aggregate Context Info – The influence of a particular context on the 2170additional information when a Basic Information Entity is used in an Aggregate 2171Information Entity 2172 2173Business Information Entity (BIE) – A Business Information Entity is a piece of 2174business data or a group of pieces of business data with a unique business semantic 2175definition A BIE can be either a Basic Business Information Entity (BBIE) or an 2176Aggregate Business Information Entity (ABIE) 2177 2178Business Term - This is a synonym term under which the Core Component is 2179commonly known and used in the business A Core Component may have several 2180business terms or synonyms 2181 2182Constraint Language - A formal expression of actions occurring in specific contexts 2183to assemble, structurally refine, and semantically qualify core components The result 2184of applying the constraint language to a set of core components in a specific context is 2185a set of BIEs 2186 2187Context - The formal description of a specific business circumstance as identified by 2188the values of a set of context categories, allowing different business circumstances to 2189be uniquely distinguished 2190 2191Context Basic Composition Value Restriction – The influence of a particular 2192context on the restriction on the possible values for a Supplementary Component of a 2193Core Component Type when the corresponding Basic Information Entity is used in an 2194Aggregate Information Entity 2195 2196Example: 2197 The Basic Information Entity "Financial Account.Country.Identifier" could 2198 restrict the allowed value of the "Identification.Scheme.Name" to "ISO list of 2199 country codes." 2200 Remarks: 2201 There are two possibilities: 322UN/CEFACT Core Component Technical Specification 323 Page 79 of 84 324 325Core Components October 2001 2202 If the value of the Supplementary Component is fixed the 2203 Representation Term can be specialised (e.g "ISO Country 2204 Identifier") 2205 If the value of the Supplementary Component is not fixed, the user 2206 will have to specify the value of the Supplementary Component 2207 each time he uses the Basic Information Entity 2208 2209 2210Context Category - A group of one or more related values used to express one 2211characteristic of a business circumstance 2212 2213Context Information Entity — The influence of a particular context on the 2214restriction on a reusable semantic building block for the exchange of business-related 2215information 2216 2217Context Value Composition Restriction – The influence of a particular context on 2218the restriction on the possible values for a Supplementary Component of a Core 2219Component Type when the corresponding Basic Information Entity is used indirectly 2220(i.e via another Aggregate Information Entity) in an Aggregate Information Entity 2221 2222Example: 2223 The Basic Information Entity "Financial Account.Country.Identifier" could 2224 restrict the allowed value of the "Identification.Scheme.Name" to "ISO list of 2225 country codes." 2226 Remarks: 2227 There are two possibilities: 2228 If the value of the Supplementary Component is fixed the 2229 Representation Term can be specialised (e.g "ISO Country 2230 Identifier") 2231 If the value of the Supplementary Component is not fixed, the user 2232 will have to specify the value of the Supplementary Component 2233 each time he uses the Basic Information Entity 2234 2235 2236Core Component - A building block for the creation of a semantically correct and 2237meaningful information exchange ‘parcel’ It contains only the information pieces 2238necessary to describe a specific concept A Core Component will always be defined as 2239a Basic Core Component, a Core Component Type, or an Aggregate Core Component 2240 2241Core Component Administrative Information - Administrative information 2242regarding a core component 2243 2244Core Component Association Information - Information about the association 2245between two core components 2246 2247Core Component Change History - History of the modifications applied to a core 2248component version 2249 2250Core Component Replacement Information - Information about the replacement of 2251a core component by another 326UN/CEFACT Core Component Technical Specification 327 Page 80 of 84 328 329Core Components October 2001 2252 2253Core Component Representation Information - Information about the physical 2254representation of a core component in a particular syntax 2255 2256Core Component Status Information - History of the lifecycle of a particular 2257version of a core component 2258 2259Core Component Type - A core component that consists of one and only one value 2260component that carries the actual content plus one or more supplementary components 2261giving an essential extra definition to the value component Core Component Types 2262do not have business meaning 2264[Note] 2265 2266As an example, if the content component carries “12” this has no meaning on its own 2267But “12 Kilometres” or “12 Euros” have meaning 2268 2269Data Type - Defines the set of valid values that can be used for a particular BCC It is 2270defined by specifying restrictions on the CCT that forms the basis of the 2271Representation Term from which the Data Type is derived 2272 2273Definition - This is the unique semantic business meaning of a Core Component 2274 2275Dictionary Entry Name - This is the unique official name of a Core Component in 2276the dictionary 2277 2278Information Entity - A reusable semantic building block for the exchange of 2279business-related information 2280 2281Object Class - The logical data grouping (in a logical data model) to which a data 2282element belongs (ISO11179) The Object Class is the part of a Core Component’s 2283Dictionary Entry Name that represents an activity or object in a specific context 2284 2285Primitive Type - Primitive type used for the representation of the value of a 2286Supplementary Component Possible values are String, Decimal, Integer, Boolean, 2287Date 2288 2289Property Term - This identifies one of the characteristics belonging to the Object 2290Class 2291 2292Representation Term - The type of valid values for a Basic Core Component 2293 2294Supplementary Component - Gives meaning to the Value Component in the CCT 2295 2296Value Component - Defines the primitive type used to express the value of a CCT 2297 2298Value Restriction - Restriction on the possible values for a Supplementary 2299Component of a Core Component Type when the corresponding Basic Information 330UN/CEFACT Core Component Technical Specification 331 Page 81 of 84 332 333Core Components October 2001 2300Entity is based on this Core Component Type 2301Example: 2302 The Basic Information Entity "Financial Account.Country.Identifier" could 2303 restrict the allowed value of the "Identification.Scheme.Name" to "ISO list of 2304 country codes." 2305 Remarks: 2306 There are two possibilities: 2307 If the value of the Supplementary Component is fixed the 2308 Representation Term can be specialised (e.g "ISO Country 2309 Identifier") 2310 If the value of the Supplementary Component is not fixed, the user 2311 will have to specify the value of the Supplementary Component 2312 each time he uses the Basic Information Entity 2313 23148 Disclaimer 2315The views and specification expressed in this document are those of the authors and 2316are not necessarily those of their employers The authors and their employers 2317specifically disclaim responsibility for any problems arising from correct or incorrect 2318implementation or use of this design 334UN/CEFACT Core Component Technical Specification 335 Page 82 of 84 336 337Core Components 338 23199 October 2001 Contact Information 2320Team Leader 2321 Name 2322 Company 2323 Street 2324 City, state, zip/other 2325 Nation 2326 2327 Phone: 2328 Email: 2329 2330Editor 2331 Name 2332 Company 2333 Street 2334 City, state, zip/other 2335 Nation 2336 2337 Phone: 2338 Email: 2339 Hartmut Hermes Siemens AG Richard Strauss Strasse 76 81679 Munich Germany (089) 92 21-4564 hartmut.hermes@mch11.siemens.de Mark Crawford Logistics Management Institute 2000 Corporate Ridge McLean, Virginia 22102 USA +01 703 917 7177 mcrawford@lmi.org 339UN/CEFACT Core Component Technical Specification 340Tuesday, October 18, 2022 341 Page 83of 84 342Core Components 2340Copyright October 2001 Statement 2341 2342Copyright © UN/CEFACT 2001 All Rights Reserved 2343 2344This document and translations of it MAY be copied and furnished to others, and 2345derivative works that comment on or otherwise explain it or assist in its 2346implementation MAY be prepared, copied, published and distributed, in whole or in 2347part, without restriction of any kind, provided that the above copyright notice and this 2348paragraph are included on all such copies and derivative works However, this 2349document itself MAY not be modified in any way, such as by removing the copyright 2350notice or references to ebXML, UN/CEFACT, or OASIS, except as required to 2351translate it into languages other than English 2352 2353The limited permissions granted above are perpetual and will not be revoked by 2354UN/CEFACT or its successors or assigns 2355 2356This document and the information contained herein is provided on an "AS IS" basis 2357and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 2358INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2359THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 2360IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2361PARTICULAR PURPOSE 2362 2363 343UN/CEFACT Core Component Technical Specification 344 Page 84 of 84 345