European Interoperability Framework (EIF)

Het Europese Interoperabiliteitsraamwerk (EIF)

De elektronische overheid (e-overheid) valt niet meer weg te denken in de huidige Internetmaatschappij. De e-overheid biedt burgers, bedrijven en overheidsinstellingen een nieuw communicatiekanaal om met elkaar in gesprek te gaan. Door het toepassen van informatie- en communicatietechnologie (ICT) kunnen de administratieve lasten van burgers en bedrijfsleven worden verminderd en de kwaliteit van de dienstverlening worden verbeterd.

De verhoogde toename van het vrije verkeer van burgers en bedrijven in Europa vraagt om meer aandacht voor de ontwikkeling van de grensoverschrijdende dimensie van e-overheid. De informatiesystemen van lidstaten moeten steeds meer informatie onderling uitwisselen. Hierbij valt ondermeer te denken aan de uitwisseling van gegevens over verkeersovertredingen, diploma’s en justitiële veroordelingen.

Voor het verkrijgen van een eenduidig gezamenlijk beeld van de huidige en toekomstige Europese informatievoorziening en organisatiestructuur is een gemeenschappelijk referentiekader nodig voor alle betrokkenen. Het aanbrengen van structuur in deze complexe informatievoorziening gebeurt door het ontwerpen van een referentiekader waarin de samenhang tussen organisatie, processen, diensten, informatievoorziening en infrastructuur inzichtelijk wordt gemaakt. Naast de ontwikkeling van een referentiearchitectuur is een interoperabiliteitsraamwerk vereist waarin richting gegeven wordt aan de te hanteren standaarden.

Een interoperabiliteitsraamwerk bestaat uit een verzameling van standaarden, richtlijnen en regels die beschrijven op welke wijze bedrijven willen (of moeten) samenwerken. Het raamwerk is (moet) in staat (zijn) om mee te evolueren met technologische veranderingen, administratieve wijzigingen en nieuwe standaarden.

Het Europese Interoperabiliteitsraamwerk - European Interoperability Framework (EIF) voorziet in een dergelijke verzameling van richtlijnen en aanbevelingen die de interoperabiliteit van overheidssystemen en processen mogelijk maken ten behoeve van het leveren van pan-Europese elektronische overheidsdiensten (PEGS)

Het EIF identificeert een aantal algemene principes voor de levering van pan-Europese elektronische overheidsdiensten: toegankelijkheid, meertaligheid, security, privacy, subsidiariteit en het gebruik van open standaarden. Het raamwerk bespreekt verder de voordelen van Open Source Software.

Het EIF is ontwikkeld onder het IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) programma. Het IDABC programma liep tot 31 December 2009 en is daarna opgevolgd door het ISA programma (Interoperability Solutions for European Public Administrations).

Het EIF onderscheidt 3 niveaus van interoperabiliteit:

- Organisatorische interoperabiliteit:
Deze vorm van interoperabiliteit houdt in dat kan worden vastgesteld welke spelers en organisatieprocessen nodig zijn voor de verlening van een specifieke e-overheidsdienst en dat zij onderling overeenstemming bereiken over de structuur van hun interacties, d.w.z. het vaststellen van hun “samenwerkingsverbanden”[

- Technische interoperabiliteit
Deze vorm van interoperabiliteit houdt in dat IT-systemen en software met elkaar worden verweven en dat er open interfaces, normen en protocollen worden gedefinieerd en gebruikt om betrouwbare, doelmatige en efficiënte informatiesystemen op te bouwen.

- Semantische interoperabiliteit (betekenis en formaat)
Deze vorm van interoperabiliteit zorgt ervoor dat de betekenis van de uitgewisselde informatie niet in het proces verloren gaat, en dat deze wordt bewaard en begrepen door de betrokken personen, toepassingen en instellingen.

Belangrijk is dat op al deze niveaus afstemming nodig is en dat binnen en tussen deze drie niveaus eveneens coördinatie noodzakelijk is.

Er bestaat niet één universele definitie voor het begrip Open Standaard.

Interoperabiliteit betekent samenwerking tussen systemen, diensten en mensen. Een vraag die automatisch opkomt is hoe realiseren en/of bevorderen we interoperabiliteit.

Door de jaren heen is het duidelijk geworden dat platform onafhankelijke en open standaarden het fundament vormen voor interoperabiliteit. Interoperabiliteit is vooral gebaseerd op afspraken vastgelegd in technische specificaties of in standaarden. Zuivere interoperabiliteit betekent connectiviteit gebaseerd op zuivere open standaarden die per definitie geen enkele software leverancier begunstigen.

Op de XML Cover Pages staan de definities en formuleringen van enkele voorname internationale instellingen en bedrijven zoals de Business Software Alliance (BSA) en Sun Microsystems.

De definitie van een Open Standaard volgens de European Interoperability Framework (EIF) is eveneens opgenomen in deze lijst met definities.

Op de Engelse Wikipedia wordt de definitie van een Open Standaard volgens de European Interoperability Framework (EIF) vermeld naast 10 andere specifieke definities waaronder deze van de World Wide Web Consortium (W3C) en de International Telecommunication Union (ITU).

De definities van de W3C en de ITU hebben veel overeenkomsten onderling en met de EIF.

W3C en ITU komen op volgende punten overeen met elkaar:

# Collaborative process (ITU) - Transparancy (W3C), Openness (W3C)
# Reasonably balanced (ITU) - Impartiality and consensus (W3C), Openness (W3C)
# Due process (ITU) - Transparancy (W3C)
# Publicly available (ITU) - Availability (W3C)
# On-going support (ITU) - Maintenance (W3C)

Voor de volgende punten van de ITU definitie is de overeenkomst met W3C niet of in mindere mate terug te vinden:
# Intellectual property rights (ITU)
# Quality and level of detail (ITU)

Wat is de definitie van een Open Standaard volgens de EIF ?

De minimale eisen waaraan een Open Standaard moet voldoen volgens het Europese Interoperabiliteitsraamwerk zijn:

1. De standaard is goedgekeurd en zal worden gehandhaafd door een not-for-profit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz..);

2. De standaard is gepubliceerd en over het specificatie document van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om het te kopiëren,beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs;

3. Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis;

4. Er zijn geen beperkingen omtrent het hergebruik van de standaard

Wat is het verschil tussen Open Standaarden en Open Source ?

Het is goed om hier te benadrukken dat Open Standaarden en Open Source géén synoniemen zijn. Open Standaarden gaat over specificaties die de karakteristieken van een technologie beschrijven en publiekelijk beschikbaar zijn.

Open Source is een verzamelnaam voor alle software waarvan de broncode vrij beschikbaar gesteld wordt en waarbij in het licentiemodel het gebruik van de software alsook het gebruiken, verbeteren, uitbreiden en distribueren van de broncode geregeld wordt. Let op: Open source software mag vrijelijk gebruikt worden maar is geen publiek domein.

Standaarden en interoperabiliteit zijn onlosmakelijk met elkaar verbonden maar dat geldt niet of nauwelijks voor open source software.

Een aantal belangrijke vragen die ik de komende tijd wil beantwoorden zijn:

- Hoe realiseren of bevorderen we pan-Europese semantische interoperabiliteit ?

- Welke Open Standaarden zijn in gebruik binnen Europa ?

Tags: Overheid, Interoperability-Frameworks

Last update: 26-11-2011

UN E-Government Readiness Survey (EN)

The European Interoperability Framework (EIF is a set of guidelines and recommendations to enable interoperability of government systems and processes with a view to delivering pan-European e-Government services (PEGS).

The EIF is developed under the IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) program. The IDABC program lasted till 31 December 2009 and has been superseded by the ISA program (Interoperability Solutions for European Public Administrations).

What is the ISA program ?
Public administrations are expected to provide efficient public services to businesses and citizens across Europe. ISA, the programme on Interoperability Solutions for European Public Administrations, addresses this need. ISA supports and facilitates efficient and effective cross-border electronic collaboration between European public administrations. The programme enables the delivery of electronic public services and ensures the availability, interoperability, re-use and sharing of common solutions.

Interoperability Frameworks in Europe
Almost all European Governments are in the process of developing and implementing the electronic government. The starting point of the EIF is that each member state has or is actively working on the development of its national Government Interoperability Framework (GIF).

A few examples of frameworks are available on the next websites:
# BELGIF: BELgian Governement Interoperability Framework.

# UK e-GIF: UK e-Government Interoperability Framework.

For a complete overview of the Interoperability Frameworks of all European countries visit the website epractice.eu. Another overview of e-Government initiatives in Europe can be found on Wikipedia: eGovernement in Europe.

Interoperability Frameworks outside Europe
Also governments outside of Europe are working on developing interoperability frameworks:

# New Zealand: NZ E-government Interoperability Framework

# Australia: Australian Government Information Interoperability Framework

# Tasmania: Interoperability Program

The role of the United Nations
The United Nations plays an important role in the promotion of the Interoperability Frameworks. Regularly the United Nations examines the Interoperability Frameworks of the connected countries. The results of the investigation are published on the United Nations Online Network in Public Administration and Finance (UNPAN).

The United Nations Online Network in Public Administration and Finance (UNPAN) is a virtual electronic network that promotes the exchange of expertise and sharing of experiences and lessons learned in public administration and finance at local, national, sub regional, regional and international levels.

On the website of the UNPAN you can find the E-Government Readiness Knowledge Base of the United Nations . The United Nations E-Government Readiness Knowledge Base (UNKB) is a benchmarking tool that provides a comparative assessment for monitoring progress of a country’s e-government readiness.

Yearly the United Nations publishes the Survey e-government readiness. At the begin of the year (2008) the Division for Public Administration and Development Management (DPADM) of the United Nations Department of Economic and Social Affairs (UNDESA) published the UN E-Government Survey 2008: From E-Government to Connected Governance. The survey assesses the e-government readiness of the 192 Member States of the UN according to a quantitative composite index of e-readiness based on website assessment, telecommunication infrastructure, and human resource endowment.

The Scandinavian countries (Sweden, Denmark and Norway) took the top three in the survey followed by the United States. The European countries made up 70 per cent of the top 35 countries with the Netherlands ranked fifth.

The survey can be found on the website of the United Nations Public Administration Network (UNPAN). Open the top level menu Library, go to the option Major Publications and select the item UN E-Government survey.

Last year (2007) the regional centre for the Asia-Pacific of the United Nations Development Program (UNDP) in Bangkok has investigated the Interoperability Frameworks of seven countries including Australia, New Zealand, UK and Denmark. The analysis has been performed under the Asia-Pacific Development Information Programma (APDIP).

The comparisons are intended to provide supplementary information for countries interested in developing their own Governement Interoperability Framework (GIF) and/or updating an existing framework.

During the investigation the focus has been on how Government Interoperability Frameworks (GIFs) in different countries are developed, implemented and maintained. The emphasis has been on the sections: Context, Technical Content, Development Process, Implementation and Compliance.

The Context includes the definition of the GIF, aims of the document, principles that support the selection of standards, scope and limitations, agencies bound by the specifications of the GIF, and the relationship of the GIF with other government documents.

The Technical Content contains the standards and recommendations of the GIF regarding the development of ICT systems and contains a listing of the standards categorized according to the defined interoperability layers.

The Implementation describes the support tools that are provided and/or being developed to aid the widespread adoption of the GIF.

The Compliance references indicators for interoperability, strategies for ensuring compliance, and additional guidance for stakeholders that are provided.

The results are presented in the document e-Government Interoperability: A review of Government Interoperability Frameworks in Selected Countries (GIF-Review.pdf).

Tags: Government, Interoperability-Frameworks

Last update: 26-11-2011

UN E-Government Readiness Survey (NL)

Het Europese Interoperabiliteitsraamwerk - European Interoperability Framework (EIF) is een verzameling van richtlijnen en aanbevelingen die de interoperabiliteit van overheidssystemen en processen mogelijk maken ten behoeve van het leveren van pan-Europese elektronische overheidsdiensten (PEGS).

Het EIF is ontwikkeld onder het IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) programma. Het IDABC programma liep tot 31 December 2009 en is daarna opgevolgd door het ISA programma (Interoperability Solutions for European Public Administrations).

Wat is het ISA programma ?
Public administrations are expected to provide efficient public services to businesses and citizens across Europe. ISA, the programme on Interoperability Solutions for European Public Administrations, addresses this need. ISA supports and facilitates efficient and effective cross-border electronic collaboration between European public administrations. The programme enables the delivery of electronic public services and ensures the availability, interoperability, re-use and sharing of common solutions.

Interoperabiliteitsraamwerken in Europa
Vrijwel alle Europese overheden zijn druk bezig een bijdrage te leveren aan het ontwikkelen en inrichten van de elektronische overheid. Het uitgangspunt van de EIF is dat elke lidstaat beschikt over of actief werkt aan het ontwikkelen van een eigen Government Interoperability Framework (GIF).

Een aantal voorbeelden van raamwerken zijn terug te vinden op de volgende websites:
# BELGIF: BELgian Governement Interoperability Framework.

# UK e-GIF: UK e-Government Interoperability Framework.

Voor een overzicht van de Interoperabiliteitsraamwerken van alle Europese landen ga naar de website epractice.eu. Een anderoverzicht van e-Government initiatieven in Europa kunt u terugvinden op Wikipedia: eGovernement in Europe.

Interoperabiliteitsraamwerken buiten Europa
Ook buiten Europa werken overheden aan interoperabiliteitsraamwerken: # Nieuw Zeeland: NZ E-government Interoperability Framework

# Australië: Australian Government Information Interoperability Framework

# Tasmanië: Interoperability Program

Rol van de Verenigde Naties
De Verenigde Naties speelt een belangrijke rol in de promotie van de Interoperabiliteitsraamwerken. Zo verricht de Verenigde Naties jaarlijks onderzoek naar de interoperabiliteitsraamwerken van de aangesloten landen en stelt deze onderzoeksresultaten beschikbaar via het United Nations Public Administration Network (UNPAN).

De UNPAN is een virtueel elektronisch netwerk ter promotie van het uitwisselen en delen van kennis, ervaring en "lessons learned" in publieke administraties en financiën op lokaal, nationaal, regionaal en internationaal niveau.

Op de website van de UNPAN kunt u de E-Government Readiness Knowledge Base van de Verenigde Naties vinden. De Knowledge Base is een benchmark tool waarmee de gereedheid voor e-overheid van een land gevolgd kan worden in vergelijking met andere landen.

Jaarlijkst publiceert de Verenigde Naties de Ranglijst e-overheid readiness. De Divisie voor Public Administration and Development Management (DPADM) van het Departement Economische en Sociale Zaken van de Verenigde Naties (UNDESA) heeft begin van het jaar (2008) de UN E-Government Survey 2008: From E-Government to Connected Governance gepubliceerd. Dit onderzoek maakt de balans op van de gereedheid van de e-overheid in de 192 lidstaten van de Verenigde Naties op basis van een aantal kwantitatieve indicatoren. Daarbij werd gekeken naar webtoegankelijkheid en internetpenetratie, de telecommunicatie infrastructuur en de opleidingsgraad van burgers.

De top 3 van landen die het best zijn voorbereid op e-overheid zijn de Scandinavische landen Zweden, Denemarken en Noorwegen gevolgd door de Verenigde Staten. De Europese landen nemen 70 procent in van de top 35 landen in de ranglijst, met Nederland op de vijfde plaats.

Het onderzoeksrapport kun u vinden op de website van de United Nations Public Administration Network (UNPAN). Open het menu Library, ga naar de optie Major Publications en selecteer het onderwerp UN E-Government survey.

Vorig jaar (2007) heeft het regionale kantoor voor de Asia-Pacific van de ontwikkelingsorganisatie van de Verenigde Naties (UNDP - United Nations Development Programma) in Bangkok een vergelijkend onderzoek uitgevoerd naar de Interoperabiliteitsraamwerken van zeven landen waaronder Australië, Nieuw Zeeland, UK en Denemarken. Deze vergelijkende analyse werd uitgevoerd als onderdeel van het Asia-Pacific Development Information Programma (APDIP).

De vergelijkende analyses zijn bedoeld om meer en additionele informatie beschikbaar te stellen aan landen die een Interoperabiliteitsraamwerk - Government Interoperability Framework (GIF) - willen ontwikkelen en/of een bestaand raamwerk willen upgraden / verbeteren.

Tijdens het onderzoek is voornamelijk gekeken naar hoe de Government Interoperability Frameworks (GIFs) in de verschillende landen tot stand zijn gekomen, zijn geïmplementeerd en worden onderhouden. Daarbij is met nadruk onderzoek gepleegd naar de invulling van de onderdelen: Context, Technische Inhoud, Development Process, Implementatie en Compliance.

De Context gaat over de definitie en het doel van de GIF, de principes voor het selecteren van standaarden, het bereik en de beperkingen, de organisatie die zich dienen te houden aan de specificaties van de GIF en de relatie van de GIF met andere overheidsdocumenten.

De Technische Inhoud heeft betrekking op de standaarden en aanbevelingen van de GIF voor de realisatie van informatie- en communicatie systemen en bevat een lijst met standaarden gegroepeerd naar de gehanteerde interoperabiliteitslagen.

Het Development Process betreft het proces van ontwikkelen, goedkeuren en implementeren van de GIF. Daarbij is gekeken naar de stappen die doorlopen werden voor het ontwikkelen van de GIF, de organisaties die daarbij betrokken zijn, en stappen die gevolgd moeten worden voor het updaten van de GIF.

De Implementatie beschrijft de ondersteunende gereedschappen die beschikbaar worden gesteld of ontwikkeld ten behoeve van de algemene (wijdvertakte) acceptatie van de GIF.

De Compliance bespreekt het gebruik van indicatoren voor het meten van interoperabiliteit, de strategieën voor het borgen van de naleving van het raamwerk en de richtlijnen voor belanghebbenden.

De resultaten van het onderzoek staan beschreven in het document e-Government Interoperability: A review of Government Interoperability Frameworks in Selected Countries (GIF-Review.pdf).

Tags: Government, Interoperability Frameworks

Last update: 26-11-2011

the XAware Sandbox EDIFACT project requirements

A few weeks ago I wrote about the missing support for EDIFACT and derived standards in Open Source XML-based Transformation Tools such as XAware and Chainbuilder.

The goal was to get the people behind these communities motivated to provide the means and tools for managing Community projects. One of these will of course be the development of EDIFACT functionality.

Meanwhile the XAware Company has established a Sandbox environment for Community Members to start their development projects but moreover to enable knowledge transfer and share prebuilt transformation routines and connectors / adaptors.

The guidelines and procedures for contributing code to the core software are under development. These will include coding guidelines and standards, test and certification guidelines, contributor agreement required for developers wishing to contribute code to the project, acceptance criteria and procedures for the adoption into the core project.

One of the first Community projects will be the development of EDIFACT functionality. A short summary of the UN/EDIFACT message structure can be found in my bloart Short description of the EDIFACT Message Structure.

People from XAware-Europe, Atos Origin, freelancers and private persons are participating on a voluntary basis to establish the first XAware Sandbox project, the EDIFACT functionality. Last week the functional requirements and technical design were discussed in the Netherlands based on a draft proposal from one of the participants.

The goal is to establish a generic approach that will become available for the whole community. The preliminary functional requirements and technical design are described hereafter. You are welcome to join us in the development of the EDIFACT functionality or to comment on the preliminary requirements and design approach.

Background
XAware is Data Integration Middleware provided under the Open Software Foundation approved GNU General Public License Version 2 GPLv2. People all over the world are using XAware technology for various projects and purposes. The main reasons for the popularity are:

1. Benefits of Open Source software.

2. XAware has an open architecture and Application Programming Interface (API)

3. Solutions can be implemented in a short period of time

4. Reusable integration solutions for message standards

The benefits of Open Source software are:
- Lower software licensing costs

- Avoidance of proprietary lock-in

- Compliance with accepted industry standards

- High innovation speed

- Freedom to study how the programs works and adapt it to your needs

- Freedom to run the program

To use XAware as a generic transformation tool in large scale B2B environments the support for EDIFACT and alike standards is imperative.

EDIFACT contains a standard set of message definitions used for particular business functions such as shipment, warehousing and invoicing. This standard has been around for at least two decades and is expected to be replaced by a suitable XML standard in the future. Support for EDIFACT will allow XAware technology to be used for EDIFACT integration and EDIFACT migration projects where EDIFACT is replaced by an XML standard.

Purpose
This document describes the functionality to be provided and/or developed for EDIFACT support in XAware.

User requirements:
1. XAware must support reading, processing and writing of EDIFACT messages

2. Supported EDIFACT messages and specifics are:

a. Message definitions from the UN/EDIFACT Standard Directories

b. Messages with zero or one Functional Group containing the contents of the message

c. XAware will not support customizing EDIFACT message structures such as adding or removing segments

. Subsets of EDIFACT messages

e. Parts of EDIFACT messages

3. EDIFACT support should be built under (commercial) open source conditions, meaning that it is reusable for all customers and users in the community

4. The Project, project documentation and other artifacts should be made available through the XAware community site and forum. This helps the community awareness of the EDIFACT initiative and reuse of the solution.

5. EDIFACT messages must be readable from multiple channels (file, queue, ws, etc)

6. EDIFACT communication configuration must be done at EDIFACT directory level

7. XAware must support multiple versions of the EDIFACT directory provided by UN/ECE

8. XAware must provide a solution that enables reuse of mappings between various standards

9. A methodology for future integration/migration projects using the EDIFACT solution should be defined. This methodology should address the following requirements:

a. EDIFACT message discovery and exploration at business level

b. Mapping specification at business level

c. Mapping based on metadata (XML Schema Definition (XSD))

d. Reusable mapping components

e. Incremental process

f. Define the proper workflow in XAware designer to support this methodology

g. Select (or built in XAware) a powerful mapping facility (IDE) needed to support business consultants in defining the mapping from EDIFACT to other standards at the customer site

Functional requirements
1. XAware must read EDIFACT message definition from multiple files from the directory (edmd.zip, edsd.zip, eded.zip, edcd.zip, message definition)

2. XAware must implement logic to generate the corresponding EDIFACT XML XSD for a specified EDIFACT message definition.

3. XAware must map all messages to the corresponding ‘EDIFACT XML’ as the Common Information Model (CIM) and vice versa.

4. Reusable XAware mappings at segment level, composite data element and primitive data types

5. Separators for segments (‘’’), composite data elements (‘:’) and data elements (‘+’) should be made configurable. Reason is that the default values can be overridden in the message header.

6. The design of the solution should include a plug point for adding business logic (for validation or transformation)

7. The design of the segment processing logic should address

a. Filter(s) for removing and selecting optional sections

b. Handle qualified data elements and data types (composite data elements & primitive data type conversion)

c. Reuse components that map segments, composite data types and primitive data types (e.g date time mappings).

d. Allow for generation of a skeleton BizDocument that implements the processing logic

8. Performance requirements are not clear at this time. Process messages up till certain size under a second.

9. Scalability requirements are not clear at this time.
Rough estimate: Technology should be able to cope with Millions of messages per day?

Technical Design
This section describes the design, considerations and decisions for implementing the EDIFACT functionality. The approach is to split development into two focus areas: the required XAware technology for working with the EDIFACT directories and the XAware scripts and process for building transformation routines.

XAware technology
1. Parser for reading EDIFACT message types and convert this to corresponding XML Schema Definition (XSD).

2. Instruction for processing messages in EDIFACT format similar to multi format instruction

a. Parsing of the messages using EDIFACT directory (or EDIFACT metadata included in BizComponent at design time)

b. Convert the message to corresponding XML structure that conforms to the generated EDIFACT XSD and deliver that in the response

3. User interface wizard to create an EDIFACT BizComponent based on directory version and message id.

4. Where do we want to place EDIFACT directory in the architecture?

XA script
Building blocks for the segment processing logic are:
1. BizComponent that reads the EDIFACT message and returns the corresponding EDIFACT XML

2. (Generated) BizDocument skeleton that maps EDIFACT XML to the source/target system.

a. Data type conversion logic?

b. Transformation logic?

c. Business logic?

3. XML mapper for handling repeatable groups in the EDIFACT XML

Tags van Technorati: electronic data interchange,eclipse,data mapping tool,EDIFACT

Last update: 26-11-2011

On what does the interoperability solution of the UN/CEFACT CCTS rest?

The UN/CEFACT Core Components Technical Specification (CCTS and ISO 15000-5) is developed by the UN/CEFACT Techniques and Methodologies Group (TMG), one of the permanent working groups of the UN/CEFACT. The most important goal of the UN/CEFACT TMG is the development of information and communication technology specifications and recommendations for the other UN/CEFACT working groups. The UN/CEFACT TMG group also developed the UN/CEFACT Modelling Methodology (UMM).

What is the goal of the UN/CEFACT CCTS ?
The UN/CEFACT Core Components Technical Specification (CCTS) provides in a syntax-neutral methodology for the design and development of semantic building blocks.

The goal of the specification is to provide a solution oriented approach for the well-known interoperability question. For years the lack of information interoperability between Business supporting systems has been a restricting factor in the realization of inter-enterprise collaborative Business processes and data exchange.

The UN/CEFACT CCTS constitutes the basis for the development of a grammar that organizations can use to develop new Business vocabularies. Those new vocabularies contribute to improving and simplifying the way parties communicate with each other across Business boundaries (applications and systems) and domains (sectors). To eliminate the interoperability problems the use of one generic grammar language is advised.

The UN/CEFACT takes care of the development and maintenance of a universal Core Component Library (CCL) and Data Type Catalogue with free access for the Core Component community.

What boundary conditions apply ?
For a proper working of the CCTS concept all standards organizations need to ensure their core components are included in the Core Component Library (CCL) and/or need to open up their libraries to others.

At the moment only a few standards organizations have adopted and partially implemented the CCTS approach. OAGIS and OASIS Universal Business Language (UBL) took the CCTS as a basis for the development of their message libraries. Some other standards organizations that adopted the CCTS approach are RosettaNet, CIDX, HR-XML en ACORD.

What approach does the CCTS takes in solving the interoperability question ?
The approach of the Core Components Technical Specification is based on commonly accepted and publicitely available Core Components and derived Business Information Entities. The most atomic information parts for assembling the core components and information entities, up to a complete Business document, are the Core Data Types (CDT).

The foundation for the interoperability solution of the UN/CEFACT CCTS are the Core Data Types (CDTs) and the Business Data Types (BDTs) which are stored in the Data Type Catalogue of the UN/CEFACT. All other Core Components and Business Information Entities are based on these atomic information parts.

Given the fact that all standards organizations that adopted the CCTS approach have based their message libraries on these atomic information parts and are making use of the Data Type Catalogue the future of the CCTS looks promising.

The OAGIS and the OASIS UBL standards took over the Core Data Types and Business Data Types as a set of Unqualified Data Types (UDT) in addition to their own specific data types. However since the UN/CEFACT CCTS was developed only recently these organizations have not yet been able to incorporate all of the CCTS concepts. Although it should be mentioned that the OASIS UBL standard was ahead of the UN/CEFACT.

Key principes of the CCTS Data Types
There are two kinds of Data Types: Core Data Types (CDT) and Business Data Types (BDT).

The Core Data Types identify the most atomic pieces of Business information and should be considered as generic data types. Every Core Data Type consists of a Content Component and one or more Supplementary Components.

The Content Component is the carrier of the actual value and the Supplementary Component give meaning to this value. Every Content Component and Supplementary Component has a Primitive Type that sets the initial Value Domains. The Value Domain of the Content Component defines the set of permissible values for the Core Data Type but is constrained by its Supplementary Component.

The Core Data Types defines the value space for the Core Component (CC). The Business Data Types for the Business Information Entity (BIE).

Example:
The Core Data Type Amount.Type contains a Content Component that carries the value and a Supplementary Component that gives meaning to that value.

CDT = Amount. Type
Primitive = Decimal
Content Component = 12 (Amount. Content)
Supplementary Component = EUR (Amount. Currency. Code)

The Core Components Technical Specification provides a fixed list of Core Data Types in the Data Type Catalogue. The catalogue contains the list of the UN/CEFACT permissible Representation Terms, Core Data Types and Business Data Types.

The list of Core Data Types includes types such as Amount. Type, Binary. Object. Type, Code. Type, Date. Type, Date. Time. Type, Duration. Type, Graphic. Vector, Identifier. Type, etcetera.

Focus areas of the CCTS are:
- Core Components (CC's):
Core Components are semantic buidling blocks, conceptual in nature, that can be used for all aspects of data and information modelling.

- Business Information Entities (BIE's)
Business Information Entities are context-specific uses of conceptual core components within a specific business domain. BIE's are always derived from CC's.

Import startingpoint for the methodology is the use of the Dictionary Entry Name (DEN). This is the unique official name of the core component in the dictionary. The CCTS specifies that the dictionary content shall be in the English Language following the primary Oxford English Dictionary English spellings to assure unambiguous spelling.

The Core Components Technical Specification provides companies a semantic base for the support of different XML-languages for electronic communication. The CCTS enables semantic mapping of components between different libraries.

What is the status on solving the interoperability question ?
In the UBL Developers Community Mark Crawford answers my question How will CCTS improve the interoperability between one or more communication partners, standards and systems as follows:

"The Data Type interoperability is just one aspect of the interoperability of CCTS. People are referring to the base data types from CEFACT, but much more importantly, they are doing this in the development of their syntax neutral data models. The Data Types are the basis for both the conceptual and logical data models. The conceptual data model and semantic focus are the keys to interoperability as every logical data model is derived from a single ubiquituous data model."

In other words the CCTS aims at realizing universal semantic interoperability of Business Information through one single conceptual data model from which all other context-specific logical data models are derived.

This means that the necessary interoperability can only be obtained when all data models from the different standards are derived from the CCTS conceptual data model, next to the use of the Data Type Catalogue and the Core Component Library (CLL).

Likely this will not happen in the next few years because the impact is very extreme. I do not believe that standard organizations and others are willing to abandon their approaches and knowledge base in favor of interoperability. Other less extreme initiatives will soon be launched and build upon the CCTS or follow a new direction (web ontology).

One thing is sure, all of us are behind the idea that Informationinteroperability should be realized by using one common notion of the meaning of data but the way this will be done is not yet determined.

Once the selected principle can be incorporated in systems and applications then interoperability will be commonly accepted.

I will stay on top of the latest developments of interoperability and will soon be back with more.

Tags van Technorati: electronic data interchange,UDEF,CCTS,UN/CEFACT

Last update: 26-11-2011

Waarop berust de interoperabiliteitsoplossing van de UN/CEFACT CCTS ?

De UN/CEFACT Core Components Technical Specification (CCTS en ISO 15000-5) is ontwikkeld door de UN/CEFACT Techniques and Methodologies Group (TMG), één van de permanente werkgroepen van de UN/CEFACT. De voornaamste taak van de UN/CEFACT TMG is het ontwikkelen van informatie- en communicatietechnologie specificaties en aanbevelingen ten behoeve van de andere UN/CEFACT werkgroepen. De UN/CEFACT TMG groep heeft eveneens de UN/CEFACT Modelling Methodology (UMM) ontwikkeld.

Wat wordt beoogd met de UN/CEFACT CCTS ?
De UN/CEFACT Core Components Technical Specification (CCTS) voorziet in een syntax-neutrale methodologie voor het ontwerpen en ontwikkelen van een verzameling semantische bouwstenen.

De specificatie richt zich op het aanbieden van een oplossingsgerichte aanpak voor het alom bekende interoperabiliteitsvraagstuk. H et ontbreken van informatieinteroperabiliteit tussen bedrijfsondersteunende systemen is al jaren één van de beperkende factoren in de realisatie van inter-enterprise collaboratieve bedrijfsprocessen en gegevensuitwisseling.

De UN/CEFACT CCTS vormt de basis voor het ontwikkelen van een grammaticataal waarmee organisaties nieuwe woordenboeken - Business vocabulaires - kunnen ontwikkelen. Deze nieuwe woordenboeken dragen bij tot het verbeteren en vereenvoudigen van de wijze waarop partijen overheen bedrijfsgrenzen (applicaties en systemen) en domeinen (sectoren) met elkaar elektronisch gegevens kunnen uitwisselen. Om interoperabiliteitsproblemen voorgoed uit te bannen is het gebruik van één generieke grammaticataal aanbevolen.

De UN/CEFACT draagt zorg voor de ontwikkeling en het onderhoud van een universele Core Component Library (CCL) en Data Type Catalogue met gratis toegang voor de Core Component gemeenschap.

Welke randvoorwaarden gelden ?
Voor de goede werking van het CCTS concept dienen alle standaardisatieinstellingen hun core componenten op te laten nemen in de Core Component Library (CCL) en/of hun libraries open te stellen voor anderen.

Momenteel hebben slechts een aantal standaardisatieinstellingen de CCTS aanpak onderschreven en gedeeltelijk doorgevoerd. OAGIS en OASIS Universal Business Language (UBL) hebben CCTS als basis genomen voor de ontwikkeling van hun berichtenbibliotheken. Andere standaarden die de CCTS aanpak hebben overgenomen zijn ondermeer RosettaNet, CIDX, HR-XML en ACORD.

Welke benadering volgt de CCTS voor het oplossen van het interoperabiliteitsvraagstuk ?
De benadering van de Core Components Technical Specification gaat uit van algemeen geaccepteerde en publiekelijk beschikbare Core Components en daarop gebaseerde Business Information Entities. De meest elementaire informatiedeeltjes voor het assembleren van de core componenten en informatieentiteiten, tot en met een volledig bedrijfsdocument, zijn de Core Data Types (CDTs).

Het fundament voor de interoperabiliteitsoplossing van de UN/CEFACT Core Components Technical Specification wordt gevormd door de Core Data Types (CDTs) en de Business Data Types (BDTs) die zijn vastgelegd in de Data Type Catalogue van de UN/CEFACT. Al de andere Core Components en Business Information Entities zijn op deze elementaire informatiedeeltjes gebaseerd.

Het feit dat al de standaardisatieinstellingen die de CCTS aanpak hebben onderschreven hun berichtenbibliotheken eveneens baseren op deze elementaire informatiedeeltjes en gebruik maken van de Data Type Catalogue legt de basis voor de toekomst.

De OAGIS en de OASIS UBL standaarden hebben de Core Data Types en Business Data Types overgenomen als een verzameling van Unqualified Data Types (UDT) in aanvulling op de eigen specifieke data types. Aangezien de UN/CEFACT CCTS pas recent is ontwikkeld hebben deze instellingen de nodige achterstand in het inpassen van de CCTS concepten in hun standaarden. Het moet echter gezegd dat in feite de OASIS UBL standaard de voorloper is geweest van de UN/CEFACT CCTS.

Basisprincipes van de CCTS Data Types
Er zijn twee soorten Data Types: Core Data Types (CDT) en Business Data Types (BDT).

De Core Data Types identificeren de meest elementaire stukjes bedrijfsinformatie en worden beschouwd als generieke data types. Elke Core Data Type bestaat uit een Content Component en één of meer Supplementary Components.

De Content Component is de drager van de actuele waarde en de Supplementary Component geeft betekenis aan deze waarde. Elke Content Component en Supplementary Component is afgeleid van slechts één Primitive Type welke het Value Domain, de verzameling toegestane waarden, vastlegd. Het Value Domain van de Content Component bepaalt de verzameling van toegestane waarden van de Core Data Type die verder nog beperkt kunnen door de gedefinieerde Supplementary Components.

De Core Data Types bepalen het karakter van de inhoud van een Core Component (CC). De Business Data Types doen dat voor een Business Information Entity (BIE).

Voorbeeld:
Het Core Data Type <em>Amount.Type</em> bevat een Content Component die de waarde met zich meedraagt en een Supplementary Component die betekenis geeft aan de waarde.

CDT = Amount. Type
Primitive = Decimal
Content Component = 12 (Amount. Content)
Supplementary Component = EUR (Amount. Currency. Code)

De Core Components Technical Specification voorziet in een vaste lijst van Core Data Types opgenomen in de Data Type Catalogue. Deze catalogus bevat de lijst van door de UN/CEFACT toegestane Representation Terms, Core Data Types en Business Data Types.

De lijst van Core Data Types bevat ondermeer de types Amount. Type, Binary. Object. Type, Code. Type, Date. Type, Date. Time. Type, Duration. Type, Graphic. Vector, Identifier. Type, enzovoort.

Focusgebieden van de CCTS zijn:
De Core Component Technical Specification richt zich op twee gebieden:
- Core Components (CC's):
Core Components zijn de semantische bouwstenen, conceptueel van aard, voor het ontwikkelen van data- en informatiemodellen.

- Business Information Entities (BIE's):
Business Information Entities zijn context-specifieke toepassingen of afbeeldingen van conceptuele core components binnen een bedrijfsdomein. BIE's worden altijd afgeleid van CC's.

Belangrijk uitgangspunt voor de methodologie is het gebruik van de Dictionary Entry Name (DEN). Dit is de unieke officiële naam van een core component in het woordenboek. De CCTS schrijft voor dat voor de naamgeving (Dictionary Entry Name) van de Core Componenten de Oxford English Dictionary gevolgd dient te worden. Hetzelfde geldt voor de andere componenten uit de Core Component Technical Specification.

De Core Components Technical Specification biedt bedrijven een semantische basis voor de ondersteuning van verschillende XML-talen voor elektronische communicatie. Door het gebruik van CCTS kunnen semantisch equivalente componenten eenvoudiger gemapped worden tussen verschillende bibliotheken.

Hoe ver staat het met het oplossen van het interoperabiliteitsvraagstuk ?
In de UBL Developers Community antwoordt Mark Crawford op mijn vraag op welke wijze CCTS de interoperabiliteit tussen één of meer communicatiepartners, standaarden en systemen bevordert als volgt:

“CCTS richt zich op het bereiken van universele semantische interoperabiliteit van Business Information via één enkel conceptueel data model en daarvan afgeleid diverse contextspecifieke logische data modellen.”

Dit betekent dat de noodzakelijke interoperabiliteit alleen gerealiseerd kan worden wanneer naast het gebruik van de Data Type Catalogue en de Core Component Library (CCL) eveneens de datamodellen van de verschillende standaarden worden afgeleid van het CCTS conceptuele data model.

Vermoedelijk zal dit niet binnen nu en enkele jaren worden gerealiseerd omdat dit vrij ingrijpend is. Ik geloof niet dat de standaardisatieinstellingen en andere organisaties bereid zijn om hun gevolgde aanpak en knowledge base op te geven ten gunste van de interoperabiliteit. Er zullen andere iniatieven worden opgestart die minder ingrijpend zijn en verder borduren op de CCTS of een totaal andere invalshoek hanteren (web ontology).

Eén ding is zeker, we staan wel met zijn allen achter het idee dat Informatieinteroperabiliteit gerealiseerd moet worden door een gemeenschappelijk begrip van de betekenis van gegevens maar de wijze waarop dit tot stand moet komen is nog niet definitief bepaald.

Wanneer het toch ooit zover komt en het gekozen principe(s) ingebed kan worden in systemen en applicaties dan zal interoperabiliteit gemeengoed zijn. Ik blijf de ontwikkelingen op de voet volgen en zal hier binnenkort op doorgaan.

Tags van Technorati: electronic data interchange,UDEF,CCTS,UN/CEFACT

Last update: 26-11-2011

Short description of the UN/EDIFACT message structure

Extending Open Source tools with functionality for defining and executing message transformations from EDIFACT to other standards and back requires a good understanding of the UN/EDIFACT Standard.

Hereafter I will briefly explain the UN/EDIFACT standard and discuss the following topics:
- important character sets
- the different elements of the structure
- a description of the structure
- the position, status and repetition factor of the structure elements
- the compression rules

important character sets
- Segment terminator = apostrophe '

- Segment tag and data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? immediately preceding one of the characters ' + : ? restores their normal meaning.
Example: 10?+10=20 means 10+10=20

the structure elements
The structure of an EDIFACT message is fixed and contains a number of mandatory and conditional elements. The most important building block of an EDIFACT message is the segment and hence the structure is defined in segment tables. These tables show which segments are used in the message and the order in which the segments must occur.

A simple example of such a segment table looks as follows:

Segments that belong together can be grouped in a segment group. A segment group always contains a trigger segment and at least one or more segments or segment groups. The trigger segment is a mandatory segment and must appear once. The trigger segment is always the first segment in the group.

A segment is uniquely identified using a segment tag and the position in the message.

In the above example the segment with the segment tag RFF is a trigger segment of the segment group 1 and also of the segment group 3.

A segment is a collection of logically related stand-alone or composite data elements in a fixed, defined sequence. The segment BGM, see example below, contains two composite data elements and two stand-alone data elements. A composite data element contains a combination of several data elements.

description of the structure
The structure of an EDIFACT message consists of three group levels. These levels are often called envelopes. The start and end of an envelope is identified by a service segment. The segment tag of service segments start with the letters UN.

The three levels of the EDIFACT structure are:
- Interchange Envelope (mandatory)
- Functional Group Envelope (conditional)
- Message Envelope (mandatory)

The Interchange Envelope consists of the segments UNA, UNB and UNZ. The segment UNA Service String Advice is an optional segment and provides the capability to specify the use of different separators from the standard.

The segment UNB Interchange Header identifies the sender and receiver of a message. All the data within the Interchange Envelope are defined for one receiver. The segment UNZ Interchange Header closes the envelope.

The electronic document, the actual EDI message, contains the segments from UNH to UNT. A message always starts with a Message Header, the UNH segment, and ends with a Message Trailer, the UNT segment.

The segment UNH contains the Composite Data Element UNH-S009 Message Identifier with the message type, version number and the identification of the organization responsible for the message specification. The Data Element 0065 Message Type contains the message type. The message type is identified using a 6-letter word.

The service segment UNS Section Separator can also appear in the message part to make a clear distinction between the header, detail and summary sections. For the separation between header and detail sections the segment contains the value D and between the detail and the summary sections the value S.

The Functional Group Envelope is defined by the segments UNG and UNE. The use of the functional group envelope is mandatory for communication to and from North America. The functional group envelope provides the capability to include messages from different types in separate functional groups.

position, status and repetition factor
Segment groups, segments, composite data elements and data elements have a fixed position in the structure of an EDIFACT message. The position is represented by the position number. The position of segments and segment groups can be different for each message type.

The field Status (S) identifies the elements in the structure that are Mandatory or Conditional. When a segment is mandatory it should at least occur once.

The field Repetition (R) indicates the maximum number of times an element in the structure may repeat.

A Data Element is considered available when the data element contains a value of 1 character. A composite data element is considered available if at least one of the data elements is present. A segment is available when the segment tag is present and a segment group is available when the trigger segment is present.

Compression rules
The UN/EDIFACT standard was created when bandwidth was limited and therefore several compression rules were defined to ensure that messages are as compact as possible.

These compression rules are one of the rules that makes working with EDIFACT messages difficult as you will understand later on.

* exclusion of conditional segments by omission
Conditional segments containing no data shall be fully omitted.

* exclusion of conditional data elements in a segment by omission
If a conditional data element is omitted and is followed by another data element, its position shall be indicated by retention of its data element separator.

* exclusion of conditional data element in a segment by truncation
If one or more conditional data elements at the end of a segment are omitted, the segment may be truncated by the segment terminator. Contiguous trailing data element  separators are not required to be transmitted.

The last two data elements from the previous example are omitted because these do not contain a value.

These rules count also for data elements in a composite data element except that another separator is used.

* exclusion of conditional data elements in a composite data element by omission
* exclusion of conditional data elements in a composite data element by truncation

The full overview of the UN/EDIFACT Syntax Rules can be found on the website of the UN/ECE on the webpage UN/EDIFACT Syntax Rules.

Tags van Technorati: EDIFACT

Last update: 26-11-2011