Hoi Jan, 
 
In je slot alinea spreek je over "Nieuwe wereld – nieuwe toekomst" en het feit dat het voor bedrijven steeds belangrijker wordt om snel en betrouwbaar (lees ook: zinvol en betekenisvol) te kunnen gecommuniceerd met/tussen wisselende interne en/of externe (keten)partners (X2Y). 
 
Probleem met core components specificatie binnen UN/CEFACT is inderdaad dat deze hiervoor een te smalle basis vormen. Ze bevatten geen bedrijfsematiek welke voorwaarde is om zinvol en betekenisvol te communiceren. 
Het zijn slecht afspraken mbt de letters die we gebruiken maar zeggen niets over de betekenis van de woorden en zinnen die we ermee maken. We snappen allemaal dat een p een p is maar niet dat een "product" een "product" is laat staan een "bestelling van producten" een "bestelling van producten" is en "wijziging van een bestelling van producten" een "wijziging van bestelling van producten" is. Essentiele informatie voor elk a2b proces. 
 
Dit soort semantiek is bij de leveranciers van de bedrijfsapplicatie systemen soms tientallen jaren bekend maar helaas (wegens historische redenen en Intellectual property) over de leveranciers heen niet eenduidig. Zij participeren nu gelukkig actief binnen de standaardisatie groepen om deze zo belangrijke symantische kennis in te brengen. 
 
Binnen SAP is UN/CEFACT derhalve een zeer belangrijke organisatie. Ze helpt om samen met het ECO systeem gezamelijk de Core data type te verrijken met bedrijfsemantiek.  
 
Een core data type krijgt door toevoeging van elementen als ProductID en Address ineens bedrijfssemantiek en wordt een zgn Global Data Type. Als we ook nog attributen als PurchaseoderDeliveryElements en invoicemessage toevoegen krijgt een inkooporder ook nog sematiek betreffende de levering en facturatie. Een breede acceptatie van dit soort uitbereidingen van standaarden is crucial om de snel en betrouwbaar (lees ook: zinvol en betekenisvol) te kunnen gecommuniceerd met/tussen wisselende interne en/of externe (keten)partners (X2Y). 
 
Door actief samen te werken met bedrijven en standaardisatiegroepen wordt getracht tot een eenduidige semantiek te komen. Bedrijven uit verschillende branches werken hier graag actief aan mee want idereen heeft baat bij een eenduidige, en breed geaccepteerde, definitie binnen elke waarde keten. Hierdoor blijft immers meer tijd en energie over om zich te richten op het ondersteunen van innovatieve processen en, zoals je zelf zegt: "gezond en concurrerend te zijn" 
 
Meer informatie vind je op https://www.sdn.sap.com/irj/sdn?rid=/webcontent/uuid/b84a7a14-0b01-0010-eba9-ea7518f74cc2

Pim, 
 
Hartelijk dank voor je reactie! Ja, klopt: Nieuwe wereld – nieuwe toekomst! Èchte X2Y zonder vooraf ingebakken beperkingen als gevolg van vooraf vastgestelde betekenis en contextcategorieën. En – ook mee eens! – Core Components vormen daarvoor inderdaad geen (goede) basis. 
 
In schril contrast hiermee staat – gek genoeg – het vervolg van je reactie. Mijn indruk is dat je zinsneden uit mijn artikel aanhaalt, ze uit verband haalt en ze vervolgens laat buikspreken ten faveure van zoiets als standaardisatie a la CCTS. 
 
“Een breede acceptatie van dit soort uitbereidingen van standaarden is crucial om de snel en betrouwbaar (lees ook: zinvol en betekenisvol) te kunnen gecommuniceerd met/tussen wisselende interne en/of externe (keten)partners (X2Y)”, schrijf je (voor een deel over).  
Je verzuimt echter te vermelden dat in de door jou opgevoerde context voor X en Y sterk beperkende waarden moeten worden ingevuld: X=B en Y=B is naar mijn idee al veel te ruim gekozen. Hoe dan ook: het lijkt in de verste verte niet meer op èchte X2Y – duurzame interoperabiliteit vraagt om radicaal andere benadering!  
 
“Bedrijven uit verschillende branches werken hier graag actief aan mee want idereen heeft baat bij een eenduidige, en breed geaccepteerde, definitie binnen elke waarde keten. Hierdoor blijft immers meer tijd en energie over om zich te richten op het ondersteunen van innovatieve processen en, zoals je zelf zegt: "gezond en concurrerend te zijn"”, schrijf je.  
En, oh, wat klinkt dat mooi! Wie kan daar nu tegen zijn? Niemand toch?  
Maar de vraag hoort te zijn of CCTS dat ook werkelijk waarmaken kàn. En dáár wringt de CCTS-schoen; dáár komt die “te smalle basis” zich wreken. Nogmaals: duurzame interoperabiliteit vraagt om een radicaal andere benadering.  
 
Of... zijn we zelf ook van gisteren?

De discussie of Core Components wel of niet op context gebaseerd moeten zijn is voor mij van geen belang. Waar het om gaat is dat er een oplossing komt voor het interoperabiliteitsvraagstuk - de problematiek van het ontbreken van informatieinteroperabiliteit tussen bedrijfsondersteunende systemen en B2B standaarden.  
 
Er zijn slechts een paar ontwikkelingen wereldwijd die streven naar het aanreiken van zo'n oplossing voor deze problematiek: semantic translation (web ontology) en Core Components Technical Specification. 
 
Een zoektocht via Google toont aan dat metapattern in relatie tot B2B niet de aandacht krijgt die CCTS en semantic translation krijgen. 
 
Van de twee opties is de Core Components Technical Specification één van de wereldwijde initiatieven die op dit moment het verst is. En ja in essentie komt het eropneer dat in elektronische gegevensuitwisseling het gegeven Name = Naam = Nom. Voor ons mensen allemaal vanzelfsprekend maar voor systemen gaat dat niet op. Voor elektronisch gegevensuitwisseling via B2B oplossingen en standaarden is de belangrijkste voorwaarde eenduidigheid: een gegeven in de velden Invoice, Factuur en Facture heeft dezelfde betekenis (semantiek) ongeacht de context of het nu gaat om een energierekening, een factuur van de computergigant of de factuur van een hotelovernachting. 
 
De Core Components Technical Specification en de UN/CEFACT organisatie hebben jarenlange ervaring met deze problematiek en kunnen putten uit bestaande informatiebibliotheken. Daarnaast hebben tal van bedrijven waaronder SAP. OASIS, OAGI, ACCORD, GEFEG, AIAG het gebruik van core components in hun standaarden geadopteerd en onderschrijven daarmee de aanpak. 
 
Het Core Component Technical Specification initiatief maakt dat het steeds eenvoudiger wordt om gegevens uit verschillende berichtstandaard aan elkaar te koppelen. Het opstellen van deze transformatieregels blijft voorlopig mensenwerk maar in de nabije toekomst gebeurt dit eveneens automatisch. 
 
"Duurzame interoperabiliteit vraagt om een radicaal andere benadering" MAAR heeft alleen maar kans van slagen als alle standaardisatiegroepen zich achter zo'n benadering scharen. Een concept wordt pas een succes wanneer het wordt gerealiseerd door grote vooraanstaande bedrijven en algemeen geaccepteerd door anderen. 
 
We zullen het moeten doen met de middelen en initiatieven van dit moment.

Het voorbeeld van de factuur is juist een aardige illustratie waar de standaardisatie mank gaat: in de Nederlandse horeca context kennen we verrekenbaarheid van BTW, een vinding die bij mijn weten puur Nederlands is en op de factuur vermeld moet worden. Voor een ondernemer die van de Horeca gelegenheid gebruik heeft gemaakt is het heel relevant omdat het een recht tot vooraftrek (ook al zo'n mooi Nederlands woord) van een DEEL van de BTW aanduidt ... Ik heb het niet gecontroleerd maar kan me niet voorstellen dat zo'n 'couleur locale' in de CCTS is uit te drukken ...