1. Core Components and More
Good Afternoon.
Thank you for joining us. As you can see, there are a lot of folks involved in this presentation.
Let me introduce them.

2. International Standards – Core Components
Technical Specification – both ISO and UN/CEFACT
Goal is global registry
Thousands of Candidates submitted
Harmonization at UN/CEFACT
Now we’ll leave modeling, for the moment, and go on to Core Components.
My job is to give you some basic information, or education, about modeling and Core Components.
My co-presenters will give you actual application of these two methodologies.
The Core Component Technical Specification, or CCTS, is an approved publication from UN/CEFACT and ISO.
Our goal is the global registry we discussed earlier.
Thousands of Candidate CCs have been submitted to a team at UN/CEFACT; this team is working to harmonize those submissions into common Core Components to be put into the global registry. This is not an easy task!

3. Core Components Basic building block – a data element
No business context
Types
ACC = Aggregate Core Component
Like a segment in X12 or EDIFACT
BCC = Basic Core Component
Like a data element in X12 or EDIFACT
ASCC = Associate Core Component
Connects two ACCs
Like a Party to an Address
Just a little education, for those of you who haven’t had the joy of working on or reading the CCTS.
I hope that you’re familiar with EDI?
An ACC, or Aggregate Core Component is like a segment, or a segment group, or a loop. It’s a collection of business data that logically works together. But without the business context.
Within an ACC, are BCCs, Basic Core Components. These are like data elements.
Think back on the example we saw earlier.
The Object Class was Address; we have an ACC for Address.
And within it are a lot of BCCs; the ones that you would all be able to figure out. Street, City, PO Box, and so on.

4. Business Information Entities
Built from Core Components
Have Business Context (8 possible)
Like Trade, Purchasing, Switzerland
Types
ABIE = Aggregate Business Information Entity
Built from an ACC
Qualified with a meaningful term
BBIE = Basic Business Information Entity
Built from a BCC
ASBIE= Association Business Information Entity Connects two ABIEs
Built from an ASCC
Just a little education, for those of you who haven’t had the joy of working on or reading the CCTS.
I hope that you’re familiar with EDI?
An ACC, or Aggregate Core Component is like a segment, or a segment group, or a loop. It’s a collection of business data that logically works together. But without the business context.
Within an ACC, are BCCs, Basic Core Components. These are like data elements.
Think back on the example we saw earlier.
The Object Class was Address; we have an ACC for Address.
And within it are a lot of BCCs; the ones that you would all be able to figure out. Street, City, PO Box, and so on.

5. Core Components as Canonical Model
X12
DE 116
EDIFACT
DE 3251
If you are involved in traditional EDI, or even in XML, you know that you might have to use many variations of either or both of them. This adds cost, both in time and resources, but is also an excellent to increase the possibility of error.
This slide shows just a small fraction of the possibilities.
TDED
RosettaNet
NationalPostalCode
DE 3251

6. TBG17 Submission for Address
For Postal Code
UBL (OASIS) submitted Postal_Zone
OAGi submitted Postal Code
Construction submitted Postcode
CC Harmonization agreed on
And actual example of submissions is Postal Code.
UBL, which is a committee within OASIS, and the Open Applications Group, and the Construction industry all submitted postal code. But you see that each group had a different name for the same thing.
At UN/CEFACT, the harmonization team agreed to call it Postcode; and the other two terms are shown as business terms in the dictionary.
Address. Postcode. Code

7. Core Components as Canonical Model
EDIFACT
DE 3251
X12
DE 116 UN
Address. Postcode. Code
However, once syntax neutral Core Components are available on a global level, and each has it‘s own Unique Identifier, we can use that UID to connect every syntax to every other syntax.
This is the vision of ebXML Core Components.
And what is will provide is Interoperability. Saving all of us time and money.
TDED
DE 3251
RosettaNet
NationalPostalCode
This is genuine INTEROPERABILITY

8. SYNTAX NEUTRAL!!! Naming Conventions The dictionary is Unique ID
Dictionary Entry
X12
EDIFACT
XML UN UN
Address. Postcode. Code
Address. Street Name. Text
DE 116
DE 166
DE 3251
DE 3042
ZipCode
Street
One part of the Core Components Technical Specification is called Naming Conventions. These follow an international standard from ISO, and they provide the rules and procedures for naming the dictionary entries.
Each entry, that is each Core Component, will have a unique identifier.
This is the exciting idea behind Core Components. Because, as you can see, the dictionary is syntax neutral. We finally have an automated way to communicate and understand each other , no matter what format we use.
SYNTAX NEUTRAL!!!
The dictionary is

9. UN/CEFACT Library Maintenance9

10. Maintenance Procedure Upgrade
Reorganisation
Maintenance Procedure Upgrade
Clarify procedures to lower barriers for participation
Increase speed of library publication
Need to increase limited resources for library work
Need complete methodology for all aspects of library maintenance
Alignment of deletion/deprecation procedures
Include alignment / harmonisation of libraries and publication cycles in maintenance procedures 10

11. The Libraries Three Libraries CCL TDED Joint Maintenance Agency
Reference
Models
Code lists
Three Libraries
XML
Schema
EDIFACT
CCL
TDED
Joint Maintenance Agency
(UNECE and ISO TC154)
“Libraries” also refers to code lists and XML schema. 11

12. Library Linkages UN/EDIFACT DE 7065 Package Type Description Code
TDED DE 7065 Package. Type. Code
CCL BCC Package. Type. Code/TDED Link 7065 12

13. Maintenance Steps
The following steps apply to all requests for changes to existing libraries/code lists/directories:
Change request(s) submitted and logged
Technical assessment
Semantic assessment
Harmonization
Update of libraries/code lists/directories
Validation of updated libraries/code lists/directories
Quality Assurance (internal review)
Formal Validation (external review)
Publication 13