Semantische interoperabiliteit met behulp van een bedrijfsbrede taxonomie

www.via-nova-architectura.org February 2007 1

Semantische interoperabiliteit met

behulp van een bedrijfsbrede

taxonomie

Wat kunnen we leren van IBM’s IFW Business Data Concepts

Classification?

Richard Claassens

Steeds meer worden geautomatiseerde systemen aan elkaar gekoppeld die

onafhankelijk van elkaar ontwikkeld zijn. Hierbij kunnen gemakkelijk semantische

conflicten ontstaan. In veel publicaties wordt een taxonomie, als oplossing

aangedragen. Een bedrijfsbrede taxonomie waarmee veel ervaring is, is het Business

Data Concepts Classification model van IBM’s Information FrameWork. Dit model

kent een invulling voor bankbedrijven en is al meer dan 10 jaar op de markt. De

aanpak en structuur om concepten, relaties tussen concepten en termen te

specificeren is geschikt om allerlei vormen van semantische conflicten te voorkomen.

1. Inleiding

De groei van het internet, de internationalisering van de handel en de opkomst van “information economics” resulteert in een vernieuwde zienswijze op de rol van informatiesystemen in de bedrijfsvoering en het management ervan. Internet technologie levert het fundament voor nieuwe bedrijfsmodellen, nieuwe bedrijfsprocessen en nieuwe manieren van voor de distributie van kennis [Laudon, 2004].

Voordat deze nieuwe zienswijze gemeengoed was, werden de meeste toepassingen volgens “tight coupled” principes ontwikkeld. Daarbij zijn slechts één of enkele database(s) betrokken en draait de gehele toepassing op één of een beperkt aantal platform(s)/machine(s). Bij een dergelijke aanpak is een groep van analisten en ontwikkelaars redelijk in staat om zonder strikte en volledig expliciete semantische beschrijvingen een semantisch consistente toepassing te realiseren.

Vrij vertaald schetst L. Orbst [2004] in zijn presentatie: ‘Ontologies and the Semantic Web: An Overview’, een meer actueel beeld:

“Geautomatiseerde systemen worden steeds meer samengesteld uit delen

gedistribueerde functionaliteit die onafhankelijk van elkaar ontwikkeld zijn, die zich op

verschillende platforms bevinden en die zich in principe overal kunnen bevinden. Met

deze toenemende complexiteit van systemen en IT-behoeften en een grotere afstand

tussen de systemen, is het noodzakelijk om oplossingen te adopteren die beter

aansluiten op het niveau waarop menselijke interactie plaatsvindt. Het is van belang om

gebruik te gaan maken van semantiek en deze expliciet te gaan beschrijven. Tevens is

het noodzakelijk om aansluiting te verkrijgen van het niveau van gegevens en


informatie, ofwel het semantische niveau waarop menselijke individuen met elkaar

communiceren. Semantische beschrijvingen en semantische interoperabiliteit/integratie

worden in toenemende mate belangrijk.”

In het vervolg van dit paper zullen de problemen die door Orbst worden geschetst meer in detail worden toegelicht (Hoofdstuk 2), inclusief de oplossingsrichting(en) waar hij naar verwijst (hoofdstuk 3 en 4). Hierbij zal de nadruk komen te liggen op semantische interoperabiliteit/integratie binnen het bedrijf. Vervolgens wordt in hoofdstuk 5 een oplossing beschreven die gebruik maakt van een taxonomievorm die uit de bibliotheekwetenschap afkomstig is. Vervolgens wordt IBM’s Business Data Concepts Classification gepositioneerd, beschreven (hoofdstuk 6 en 7) en geëvalueerd (hoofdstuk 8). Na een korte verhandeling over investeringen in bedrijfsbrede taxonomieën (hoofdstuk 9) wordt met conclusies afgerond (hoofdsstuk 10).

2. Communicatieproblemen

Aan de hand van de “meaning triangel” van Ogden en Richards [1923], zullen een aantal type van communicatieproblemen worden beschreven en mogelijke oplossingen.

2.1. Communicatie tussen mensen

Wanneer we het niveau beschouwen waarop mensen direct of indirect met elkaar communiceren (Human to Human = H2H) dan treden daar veelvuldig problemen op die onder andere worden veroorzaakt door semantische onduidelijkheden. Dave McComb [2004 :16], illustreert dit met het volgende tekstfragment: “Er zijn 880.000 juristen in de Verenigde Staten die een industrie vertegenwoordigen met een omzet van $100 miljard. Een van de meest lucratieve bezigheden is het opstellen en interpreteren van contracten en het procederen in geval er geschillen in relatie tot de contracten ontstaan.” Dit betekent dat het vanuit een financieel oogpunt de moeite waard is, om de kans op het optreden van semantische verschillen te verminderen.

Een van de belangrijke oorzaken van conflicten in de menselijke communicatie wordt veroorzaakt doordat dezelfde gecommuniceerde symbolen kunnen leiden tot verschillende concepten, bij personen die de gecommuniceerde gegevens ontvangen en interpreteren. Dit is te illustreren met behulp van de “meaning triangle” van Odgen en Richards [1923]. In figuur 1 is te zien dat als gevolg van de ambiguïteit van woorden, bijvoorbeeld term “jaguar”, dezelfde term kan leiden tot verschillende interpretaties en daarmee tot verschillende abstracte beelden (concepten). Het verhaal wordt nog moeilijker wanneer we te maken krijgen met concepten, die niet direct in de werkelijke wereld zijn waar te nemen.

Stands for

Refers toSymbolize

Concept(s) (in mind)

–or•thougt•idea•intension

“Jaguar”

1) The Meaning Triangle

2) Example of the ambiguity of symbols

Symbol(s) –or•term•label•code

Referent(s) -or•thing•object•extension

(Based on Ogden & Richards, 1923)

Figuur 1 Een voorbeeld van semantische misinterpretatie


Het is niet realistisch om te veronderstellen dat er één eenvoudige oplossing voor dergelijke problemen te bedenken is. Het is wel zinvol om oplossingen te zoeken die bovengenoemde problemen minimaliseren, voor die situaties waarvoor dit zinvol is. Aangezien dat er bij steeds meer communicatie, geautomatiseerde systemen betrokken zijn, moeten deze in de oplossing worden meegenomen.

2.2. Het ontwikkelen van geautomatiseerde systemen

De grote uitdaging van het ontwikkelen van geautomatiseerde systemen is het omzetten van de kennis en wensen uit een expertisedomein naar de syntax die door het geautomatiseerde systeem kan worden geïnterpreteerd. De uitdaging is nog groter wanneer een geautomatiseerd systeem gerealiseerd moet worden dat een oplossing moet bieden voor meer expertisedomeinen en individuen met hun eigen kennis en ervaring. Er zou in dit verband gesproken kunnen worden van H2H-communcatie met het doel om een geautomatiseerd systeem te ontwerpen en te realiseren.

John Zachman [1987] onderkent binnen zijn Information System Architecture (ISA) vijf ontwerpniveaus: “Scoop, Bedrijfsmodel, Systeemmodel, Technologiemodel, Component”, om van een bedrijfsmodel tot een geautomatiseerd systeem te komen. Daarnaast bevat het ISA-raamwerk zes perspectieven: “Wat, Hoe, Waar, Wie, Wanneer en Waarom”, die bij de specificatie van een te bouwen geautomatiseerd systeem meegenomen zou moeten worden.

Bij de bovenste drie ontwerpniveaus zijn systeemanalisten betrokken, die werken op de grens van het geautomatiseerde systeem en de buitenwereld [Sowa, 2000: 188]. Dit betekent dat zij moeten afstemmen met de expertise- en gebruikersdomeinen waarin het geautomatiseerde systeem moet gaan opereren. Een van de verantwoordelijkheden van de systeemanalisten is dat de semantische conflicten met de buitenwereld zo veel mogelijk worden uitgesloten. Een van de hulpmiddelen die vaak hierbij gebruikt wordt is een bedrijfsbreed gegevensmodel, gebaseerd op een ER-diagram. In het ISA-raamwerk vormt dit model de uitwerking van het Wat-perspectief op het ontwerpniveau van het bedrijfsmodel. Uit de volgende publicatie blijkt dat een dergelijke aanpak niet altijd tot de gewenste resultaten leidt. Darke & Shanks [1999: 20] hebben op basis van een onderzoek de volgende conclusie getrokken:

Een groot probleem met bedrijfsbrede gegevensmodellen is dat ze moeilijk te begrijpen

zijn. Hun abstractie ofwel generieke concepten komen onvertrouwd over voor zowel de

gebruikers als de IS-professionals, en staan vaak ver weg van hun lokale

organisatorische context. Empirische studies geven de indicatie dat veel organisaties

zijn geconfronteerd met significante problemen bij ontwikkelen en het gebruik van een

bedrijfsbreed datamodel.

De ontwerpniveaus Technologiemodel en Component hebben betrekking op de techniek. De specificaties uit hogere niveaus moet door ontwikkelaars worden vertaald naar een computerprogramma waarbij semantische afspraken worden meegenomen. Er bestaat niet zo iets als een vaag computerprogramma [Sowa, 2000]. Een programma functioneert altijd zeer precies (een formeel model), maar desondanks is het mogelijk dat het geen enkele relatie heeft met datgene waarvoor het ooit bedoeld is. De beslissingen en beschrijvingen op de hogere niveaus vormen de basis voor dat het programma zich semantisch correct gedraagt en dat gebruikers de semantiek correct kunnen interpreteren.

2.3. Het gebruik van geautomatiseerde systemen door mensen

Wanneer het geplande geautomatiseerde systeem operationeel is, zullen de gebruikers van het systeem met semantisch juiste gegevens moet vullen (Human to Application = H2A) en/of door het systeem verstrekte gegevens op een juiste wijze gaan interpreteren (Aplication to human = A2H). De meeste traditionele applicaties zijn een combinatie van H2A en A2H, een zogenaamde H2A2H-apllicatie waarbij het verstrekken van gegevens en de invoer van gegevens wordt gecombineerd [McComb, 2004: 27].

Geautomatiseerde systemen zijn niet of nauwelijks in staat om gegevens semantisch te interpreteren en te valideren. Dit betekent dat de verantwoordelijkheid hiervoor bij mensen ligt. Om semantische interpretatie en validatie te kunnen uitvoeren, moeten de gebruikers wel


over de noodzakelijke informatie, kennis en ervaring beschikken. Om de gebruiker op de hoogte te brengen van de betekenis van de gegevens is een termenlijst ofwel thesaurus een veel gebruikt middel. Een dergelijke lijst werkt vaak goed in een omgeving waarbij de gegevens exclusief tot een expertisedomein zijn toe te wijzen. Gegevens die afkomstig zijn, of betrekking hebben op verschillende expertisedomeinen, kunnen niet met een eenvoudig gestructureerde termenlijst inzichtelijk worden gemaakt.

2.4. Het koppelen van geautomatiseerde systemen

Geautomatiseerde systemen worden steeds meer samengesteld uit delen gedistribueerde functionaliteit die:

• vaak onafhankelijk van elkaar ontwikkeld zijn;

• zich op verschillende platforms bevinden;

• zich in principe overal kunnen bevinden [Orbst, 2004].

In situaties waarbij gegevens uit verschillende expertisedomeinen en van verschillende applicaties worden gecombineerd en met elkaar in verband worden gebracht, is een expliciete beschrijving van de gegevens noodzakelijk. Niet alleen een expliciete beschrijving, maar een beschrijving van onderlinge afhankelijkheden tussen de gegevens en de afhankelijkheid met de omgeving wordt dan steeds meer een noodzaak. Die situatie kan al vrij snel optreden wanneer verschillende geautomatiseerde systemen met elkaar gekoppeld worden (Application to Application =A2A).

In figuur 2 is weergegeven welke type modellen en welke vormen van communicatie op elkaar afgestemd dienen te worden. De formele modellen in deze figuur zijn een onderdeel van de geautomatiseerde systemen en zijn een resultaat van systeemontwikkeling. Een systeemontwikkeling alleen al is een complex proces waarbij veel communicatie bij nodig is en waarbij de nodige semantische conflicten kunnen optreden. Met de term agent wordt een autonoom “handelend iets” bedoeld en dat “iets” is tevens in staat is met andere agents te communiceren. Die agents kunnen zowel mensen als machines zijn.

• ...HumanAgent 1(HA1)

HumanAgent 2(HA2)

exchange signs,e.g. nat. language

‘‘JAGUAR“

Internalmodels

Formalmodels

exchange signs,e.g. protocols

MA1HA1 HA2 MA2

a specific domain,e.g. animals

MachineAgent 1(MA1)

MachineAgent 2(MA2)

(H2H) (H2A),(H2A2H),(A2H) (A2A)

= flow of communicationand also the flow of semantics(H2H) (H2A),(H2A2H),(A2H) (A2A)

Human to human Human to application Application to human Application to application

Stands for

Refers toSymbolize

Symbol Referent

Concept

Things in the

real world

Concepts / Semantic structures

Symbols /Syntactic structures

The Meaning Triangle

&

(Based on Maedche, 2002)

Figuur 2 Verschillende vormen van modellen en de verschillende vormen van communicatie


3. Mogelijke oplossingsrichting

Voor de geschetste problemen wordt in een overweldigend aantal publicaties de volgende oplossing aangedragen: Het gebruik van een ontologie.

In de volgende opsomming wordt een globaal overzicht van de toepassingsmogelijkheden van een ontologie weergegeven [Ushold,1996]:

• communicatie – tussen mensen en organisaties;

• interoperabiliteit – tussen systemen;

• software engineering – specificaties, kwaliteit, herbruikbare componenten en kennisacquisitie.

De ontologie wordt gebruikt om de ontology commitment te beschrijven, wat Gruber [1993] omschrijft als de overeenstemming over objecten en relaties waarover gecommuniceerd wordt. Verder is er een overeenkomst om een gezamenlijk vocabulair op een coherente en consistente wijze te hanteren.

In figuur 3 zijn de concepten ontology en ontology commitment gepositioneerd, in relatie tot de omgeving.

• ...HumanAgent 1(HA1)

HumanAgent 2(HA2)

exchange signs,e.g. nat. language

‘‘JAGUAR“

Internalmodels

Formalmodels

exchange signs,e.g. protocols

HA1MA2

a specific domain,e.g. animals

MachineAgent 1(MA1)

MachineAgent 2(MA2)

Ontology Description

Ontology

Formal Semantics

=The ontological commitment refers to agreements on the use

of the shared vocabulary by the agents committed to the

ontology

Stands for

Refers toSymbolize

Symbol Referent

Concept

Things in the

real world

Concepts / Semantic structures

Symbols /Syntactic structures

The Meaning Triangle

commit

MA1

commit

commit commit

HA2

commit

(Based on Maedche, 2002)

Figuur 3 Een ontologie: Een oplossing om verschillende vormen van modellen en de verschillende vormen van communicatie aan elkaar te kunnen relateren

Uitgaande van de drie voorgaande Figuurn zou een ontologie opgevat kunnen worden als een gezamenlijke, eenduidige en consistente “meaning triangle” die, door met elkaar communicerende agents wordt gehanteerd. In de volgende paragraaf worden een aantal gepubliceerde inzichten op het begrip ontologie behandeld.

4. Wat is een ontologie?

De klassieke vorm, de wetenschap van ontologie, is een discipline van de filosofie die zich bezig houdt met de aard en de organisatie van de realiteit. Vanuit een andere invalshoek wordt het nu gebruikt om de wereld te beschrijven, met het doel om ondersteuning te bieden aan de ontwikkeling van informatiesystemen. In die context worden vaak de volgende definities gehanteerd:

• an explicit specification of a conceptualization [Gruber, 1993: 199]


• a shared understanding of some domain of interest [Uschold, 1996]

In veel publicaties worden naar deze (vage) definities verwezen maar er is ook de nodige kritiek op. Chris Welty [2000], een onderzoeker die zich met ontology-driven conceptual modeling bezig houdt, hanteert de volgende definitie:

De beschrijving van de soorten van aanwezige entiteiten en de wijze waarop ze met

elkaar gerelateerd zijn

Hij geeft tevens aan dat een ontologie de volgende aspecten moet bevatten: betekenis, organisatie, taxonomie, overeenstemming, vocabulair, relatie met de reële wereld.

Er zijn veel afwijkende inzichten over de vorm waarin een ontologie moet worden beschreven. Gruber [1995] geeft aan dat een ontologie elke vorm kan krijgen om algemene en complexe structuren te beschrijven (language independant). B. Smith [2000], een onderzoeker die zich bezig houdt met formele ontologie, onder andere voor informatiesystemen, geeft een aantal aanwijzigen voor het ontwikkelen van een bruikbare ontologie:

Een ontologie moet niet bestaan uit een enkele boomstructuur maar uit een familie van

boomstructuren, die elk een weerspiegeling zijn van specifieke zienswijzen (facetten of

elementen) van het doeldomein. Naast de verschillende zienswijzen moeten

verschillende gegranuleerdheden (of levels) worden ondersteund, bijvoorbeeld:

microscopisch, mesoscopisch, macroscopisch.

B. Madsen [2002] heeft een schematisch overzicht (figuur 4) gemaakt met een aantal aspecten van een ontologie, inclusief de verschillende opties, waar ontologie in de doelstelling en de wijze van uitwerking van elkaar kunnen verschillen. Een aspect dat centraal staat in veel discussies, is hoe formeel een ontologie dient te zijn en op welk moment er niet meer van een ontologie gesproken mag worden. Vaak wordt een lichtgewicht ontologie aangeduid als taxonomie. In deze categorie zijn begrippen als: catalogus, glossarium, thesaurus en directory te plaatsen.

philoso-

phicalontology

pragmatic

ontology

top level

ontology

universalontology

domain

specific ontology

general

ontologytask

specificontology

task inde-

pendantontology

language

inde-pendant ontology

language

inde-pendant

ontology

formal

ontologynot

formal onto-

logy

VIEW

specific ontology

LEVEL SUBJECT PURPOSE LANGUAGE FORMALIZING

application

specific

ontology

Guarino, Nicola (1998). Formal Ontology and Information Systems,. In: Formal Ontology in Information Systems, Proceedings of the First International

Conference (FOIS'98), June 6-8, Trento, Italy, 3-15. Ed. Nicola Guarino. Amsterdam: IOS Press.

Bodil Nistrup Madsen (2002), based on a.o.:

ontology

Figuur 4 Aspecten van een ontologie en mogelijke opties binnen die aspecten

Reimer [2001] definieert een taxonomie als een gecontroleerd vocabulair die is geordend in een concept hiërarchie. Een ontologie definieert hij als een taxonomie waar de betekenis van elk concept gedefinieerd is door de specificatie van de eigenschappen, relaties naar andere concepten en axioma’s die zorgen voor een inperking van de interpretatie.


Waarin verschilt een ontologie nu van een gegevensmodel? S. Toivonen [2003] geeft aan dat er geen strikte scheidslijn tussen deze twee type modellen te trekken is maar dat een ontologie:

• meer algemeen en meer herbruikbaar is;

• toepasbaar is voor meer doelstellingen en gebruikersgroepen;

• eenvoudiger gemeenschappelijk te delen is;

• meer gericht zijn op de semantiek van concepten (in tegenstelling tot een zuivere structuur en integriteit).

Uit de voorafgaande verhandeling is te concluderen dat er veel voordelen worden toebedeeld aan het gebruik van een ontologie maar dat er veel manieren zijn waarop een ontologie kan worden gecreëerd en vormgegeven. Om de veronderstelde voordelen daadwerkelijk te kunnen behalen moeten behoorlijk wat afwegingen en keuzes worden gemaakt. Aangezien het ontwikkelen en het onderhouden van ontologie voor informatiesystemen nog een relatief nieuwe discipline is, zijn er nog maar weinig goede voorbeelden te vinden, die als leidraad kunnen dienen.

5. Het ontwikkelen en onderhouden van een ontologie/taxonomie

In een speciale uitgave van de ACM over ontology engineering, geven Gruninger & Lee [2002] aan dat het creëren van ontologieën een moeilijke, tijdrovende kostbare aangelegenheid is. Vooral wanneer het ontwerp formeel genoeg moet zijn om geautomatiseerd redeneren te ondersteunen. Deze laatste genoemde mogelijkheid zal binnen de meeste ondernemingen op dit moment geen hoge prioriteit hebben. Het is daarom de moeite waard om naar oplossingen te zoeken die wat minder formeel en wat meer pragmatisch zijn.

In tegenstelling tot de informatie technologie beschikt de bibliotheekwetenschap wel over een uitgebreide ervaring op het gebied van een ontwikkelen en onderhouden van taxonomieën. Hier worden twee type classificatieschema’s toegepast: enumerative en faceted. De enumerative-aanpak verlangt een kennisdomein dat successievelijke verdeeld wordt in engere klassen die alle mogelijk subklassen bevatten, inclusief samengestelde klassen. De faceted aanpak, die door Ranganathan [1967] in 1939 is voorgesteld, baseert zich niet op een uitsplitsing van het universum van kennis, maar is gebaseerd op het opsplitsen van complexe subjecten in beperkt subjectdomein, in groepen van simpele concepttermen, die ook wel facets worden genoemd [Prieto-Díaz, 2002]. In de tweede fase worden deze facets gesynthetiseerd in een gecontroleerd vocabulair inclusief beschrijvingen van samengestelde subjecten. In de bibliotheekwereld is het gebruikelijk om daarnaast nog een coderingsschema te ontwikkelen voor de onderdelen binnen de classificatieboom.

R. Prieto-Díaz [2002] beschrijft in het artikel: ‘a facetted Approach to building Ontologies’, een aanpak die gebaseerd is op facetted classifications. Eerst wordt top-down, met behulp van aanwezige expertise, een initiële classificatiehiërarchie opgesteld. Vervolgens worden gerelateerde termen in informatieobjecten in categorieën gegroepeerd (bottom-up). Als laatste wordt de initiële classificatiehiërarchie via een iteratief proces met de gecreëerde clusters vergeleken, en als resultaat kunnen mogelijke aanpassingen op de hiërarchie worden doorgevoerd. In de figuur 5 wordt dit proces schematische afgebeeld.


Postulated Ontology Synthesized Clusters

Ontology is modified based on how it maps to discovered clusters

x s

t u

v w

D

FE

B

C

A

Clusters are

mapped to ontology

2) Bottom-up

3) Revising & validating

1) Top-down

R. Prieto-Díaz (2002)

Figuur 5 De hoofdstappen binnen het faceted domein analyseproces

R. Prieto-Diaz [2002] schrijft dat het grootste voordeel van de aanpak is, dat het praktisch en bruikbaar is. De aanpak resulteert in ontologieën die geen formele definities van concepten en axioma’s bevatten maar wel een gestructureerde gecontroleerd vocabulair dat op informele wijze concepten definieert. Het resultaat biedt wel voldoende informatie om de specificatie van een formele ontologie en bijbehorende formele documentatie te ondersteunen. Zijn eigen ervaringen zijn zeer positief en deze zijn opgedaan in het beschrijven van domeinmodellen voor command&control-systemen en systemen voor banken verzekeringsinstellingen.

Er zijn geen aanwijzingen dat deze specifieke aanpak verder breed in de praktijk wordt toegepast. Dit is wel het geval met een oplossing die sterke overeenkomsten met deze aanpak kent: het IBM Business Data Concepts Classification model.

6. IBM Information FrameWork (IFW)

Het Business Concepts Classification model is een onderdeel van het IBM Information Framework (IFW). Dit informatie raamwerk is afgeleid van het Information Systems Framework (ISA) dat door J.A. Zachman [1987] in IBM Systems Journal 26, beschreven is. In een tweede artikel over ISA: extending and formalizing the framework for Information Systems Architecture [Sowa, 1992], wordt het raamwerk meer formeel beschreven en heeft een uitbreiding van het aantal kolommen plaatsgevonden. Omdat de bedenkers van IFW al tegen onduidelijkheden en tekortkomingen van ISA waren opgelopen, hebben zij besloten om hier zelf praktische oplossingen voor te bedenken. In tegenstelling tot ISA wat een leeg raamwerk is, bestaat voor IFW een volledig uitgewerkte taxonomie voor een Bankbedrijf, inclusief daarvan afgeleide modellen en toepassingen.

IFW is ontwikkeld door IBM’s Banking Solution Centre in Dublin in samenwerking met, en met input en feedback van een aantal vooraanstaande financiële instellingen in de wereld [Evernden, 1996]. Het project is in 1991 gestart en is verder gegaan met resultaten van twee eerdere projecten op dit vlak: Financial Application Architectuur(FAA) en Financial Application Solutions (FAS90). The Financial Services Function Model (FSFM) heeft in 1993 haar eerste release gekend en is in 1994 opgevolgd door het Financial Services Workflow Model (FSWM). Inmiddels zijn deze modellen met diverse producten aangevuld, zoals een Object Model voor object georiënteerde omgevingen (FSOM), een Banking Data Warehouse oplossing (BDW), een oplossing voor het snel implementeren van datamarts (EZMart solution), en recentelijk is het object model uitgebreid met een interface design model. Deze laatste uitbreiding ondersteunt


oplossingen waarbij interfaces en hergebruik van (bestaande) componenten als uitgangpunten worden gehanteerd. Volgens de commerciële informatie op de website van IBM hebben 170 banken en verzekeringsmaatschappijen van een van de producten gebruik gemaakt en aan de verdere ontwikkeling ervan bijgedragen.

Evernden [1996] heeft een uitgebreide beschrijving over de verschillen tussen de twee raamwerken. Wat de karakterisering betreft geeft hij de volgende verschillen aan:

Daar waar ISA zich richt op een Informatie systeem Architectuur, richt IFW zich meer

op het managen van de informatie. ISA biedt een systematische taxonomie van

concepten voor gerelateerde zaken in de wereld van representaties voor de computer.

IFW richt zich meer op het beschrijven van situatie waar informatie wordt gecreëerd en

gebruikt.

ISA heeft een raamwerk van zes kolommen, vijf rijen en dertig cellen. Bij IFW wordt een meer gedetailleerde opdeling gehanteerd waarbij uiteindelijk vijftig cellen ontstaan:

Horizontale groepering: Types of information (Inclusief de verdere opdeling):

• Organization – Strategy (1), Structure (2), Skills (3)

• Business – Data (4), Function (5), Workflow (6), Solution (7)

• Technical – Interface (8), Network (9), Platform (10)

Verticale groepering: Levels of constraints, (Inclusief de verdere opdeling):

• Deconstruction - Domain Concept (A-level), Domain Classification (B-level)

• Composition – Generic Template (C-level), Design Context (C’-level)

• Implementation -Operational Bound (D-level)

Voor de overzichtelijkheid is het raamwerk in figuur 6 schematisch afgebeeld.

III) Technical ViewII) Business View

The Information Framework

I) Organisation View

Structure SkillsStrategy Data Functions Workflow Solutions Interface Networks Platforms

Domain Concept(A-level)

Domain Classification(B-level)

GenericTemplate(C-level)

DesignContext(C’-level)

OperationalBound(D-level)

Deconstructionlevel

Compositionlevel

Implementationlevel

Types of infomation

Levels of constraint

-Three views-Three levels

-Ten columns-Five rows

-Fifty cells -Six dimensions(See next page)

Modelware International (1999)

Figuur 6 Het IFW-raamwerk

De opdeling van de kolommen, samen met de basisstructuur, is ontworpen om hergebruik van informatie in elk van de andere cellen mogelijk te maken. In IFW is “informatie” een samenstelling van informatiecomponenten om de kennis en ervaring over een gegeven domein te kunnen omvatten, zoal bijvoorbeeld de financiële industrie. Deze componenten kunnen elementair of geaggregeerd zijn. Kenmerkend is dat “informatie” wordt opgevat als een


complexe groepering van componenten die vanuit verschillende gezichtspunten kunnen worden beschouwd. Een van deze gezichtpunten is het “data”-perspectief. “Data” is een van de basisbouwblokken om informatie te kunnen creëren. Informatie is opgeslagen als een combinatie van stukjes data. IFW wordt gebruikt om een deel van informatie te analyseren, de informatie op te breken in constitueerde componenten en vervolgens de componenten in de aangewezen cel van het raamwerk te plaatsen.

Het opbreken van informatie in componenten bewerkstelligt dat ieder informatie component slechts een maal beschreven hoeft te worden. Zoals bij elke dossiersysteem is het belangrijk dat het plaatsen van informatiecomponenten in cellen, volgens bepaalde regels of richtlijnen gebeurt. IFW maakt gebruik van een faceted classification systeem waarbij elke samenstelling van informatie wordt gevormd uit onderdelen die uit de verschillende perspectieven of aspecten geselecteerd worden.

7. IFW Business Data Concepts Classification

Voor de beschrijving van IFW Business Data Concepts Classification zal het white paper:

Business Classification Model, van Modelware International [1999], worden samengevat. Dit

bedrijf was de leverancier van het geautomatiseerde hulpmiddel voor de ondersteuning van

IFW.

In veel systeemontwerpmethoden is het gebruikelijk om onderscheid te maken in de volgende beschouwingniveaus:

• Conceptueel – hier worden de concepten in het te beschouwen domein beschreven (Business);

• Logisch – dit is een implementatieonafhankelijk ontwerp;

• Fysiek – dit is een implementatieafhankelijk ontwerp.

Vaak worden voor al de drie beschouwingniveaus nagenoeg vergelijkbare diagrammen gebruikt die bekend staan onder de namen: object relatie (OR) model en entiteit relatie (ER) model. De bedenkers van IFW zijn van mening dat deze modellen niet geschikt zijn om domeinbrede beschrijving te maken waarbij alle apecten vanuit verschillende gezichtpunten een plaats in het model krijgen. Bij de ER/OR-modellen bestaat het gevaar dat een gezichtpunt de overhand krijgt en dat vanuit dit gezichtpunt data-elementen worden gegroepeerd. Bij het tot stand komen van deze modellen wordt vaak bewust of onbewust rekening gehouden met de datastructuren waar de data-elementen hun plek gaan krijgen. Het gevolg is dat een deel van de gebruikers hun eigen view op het domein niet meer terug zien.

Om het genoemde nadeel te voorkomen is binnen IFW voor de uitwerking van conceptueel niveau gekozen voor een classificatie model ofwel een taxonomie. Op het hoogste niveau, het A-level, worden negen data domeinconcepten beschreven:

• Betrokken partij - involved party (IP);

• Overeenkomst – arrangement (AR);

• Conditie – condition (CN);

• Product/services – product/service (PD);

• Locatie – location (LC);

• Classificatie – classification (CL);

• Business richtinggevende waarden - Business Direction Items (BD);

• Gebeurtenis – event (EV);

• Hulpbron – resource (RC).

Het concept classification is een uitzondering en wordt gebruikt voor die (deel)taxonomieën waarvan uit meer dan één concept kan worden gerelateerd. Voorbeelden van concepten


waarvoor dit geldt zijn: meeteenheden, talen, rating modellen en structureren voor financiële verslaglegging.

Deze A-level concepten vormen de basis voor een onderliggende verzameling deeltaxonomieën, die samen het B-level vormen. Vanuit het B-level worden logische ER-schema’s samengesteld (het C- en C’-niveau), die vervolgens worden vertaald in een database schema (het D-niveau). Deze opdeling is in figuur 7 afgebeeld.

IFW Framework-3 Layers of the data column

Deconstruction

level

Composition

level

Implementation

level

Conceptual

Logical

Physical

Involved

Party (IP)

Arrangement

(AR)

Conditions

(CN)

Product

(PD)

Location(LO)

Classification(CL)

BusinessDirection

Item (BD)

Event(EV)

ResourceItem(RI)

A-level

B-level

C-level & C’-level

D-level

9 data concepts

27 classification

hierarchies

54 business

objects

Based on: Modelware International (1999)

Figuur 7 Onderdelen van het data concepts classification model en de afhankelijkheid met de overige gegevensgeoriënteerde modellen

Vanuit elk A-level data concept worden drie hiërarchieën opgebouwd, die samen het B-level vormen.

Ten eerste een fundamentele hiërarchie die de fundamentele concepten meer in detail uitwerkt en bevat subtypes van het A-level concept en de status waarin een concept zich kan bevinden.

Ten tweede een associatieve hiërarchie waarin relaties tussen onderlinge concepten worden beschreven. Dit kunnen relaties zijn tussen concepten die zich willekeurig binnen de taxonomie bevinden. Dergelijke relaties worden uitgedrukt op domein conceptniveau. Voorbeeld daarvan is: ‘IP is spouse of IP’. De relatie kan worden voorzien van beperkingen en bij het beschrijven daarvan kunnen concepten uit de verschillende hiërarchieën worden toegepast. Zo kan bijvoorbeeld worden vastgelegd dat één IP in de ‘IP is spouse of IP’-relatie het geslacht vrouw is terwijl de tweede IP van het mannelijk is.

Ten derde: Een descriptor hiërarchie beschrijft op welke wijze concepten in de werkelijkheid worden geïdentificeerd. Vaak gebeurt dit op basis van een verzameling van kenmerken, bijvoorbeeld: naam, adres, geboortedatum.

Elk beschreven dataconcept kan worden vervolgd met één of meer labels die elk een vraag impliceren. Het antwoord erop bestaat uit een opsomming van één of meer concepten. Een combinatie van een vraaglabel en de antwoorden wordt een schema genoemd. De schema’s ontstaan door verschillende gezichtpunten die op de business bestaan. De aanpak biedt de mogelijkheid om de gezichtpunten die diverse bedrijfsdomeinen op het bedrijf hebben, op een ordelijke wijze onder te brengen. In figuur 8 is het resultaat van een dergelijke ordening afgebeeld.


Involved Party(IP)INVOLVEDPARTY

TYPE

Individual INDIVIDUAL GENDERFemale

Male

OrganizationORGANIZATION LEGAL STRUCTURE

TYPE

Corporation

Partnership

IP Descriptor

IP

DESCRIPTORTYPE

IPName component

IP

NAMECOMPONENT TYPE

Given Name

Name Initial

Family name

IP RelationshipIP RELATIONSHIPTYPE

IP/IP-relationshipIP/IPRELATIONSHIPTYPE

IP is spouse of IP

IP is employee of IP

IP is customer of IP

INDIVIDUAL

EMPLOYMENTSTATUS

Working Individual

Not Employed Individual

1. Fundamental hierarchy

2. Descriptive hierarchy

3. Relationship hierarchy

Answer(s) Question = +scheme

Explanation of the B-level-Concept Involved party (IP)

Based on: Modelware International (1999)

Figuur 8 De opsplitsing van een concept op het A-level, in drie hiërarchieën

8. Evaluatie van IFW Business Data Concepts Classification

Veel informatie met betrekking tot IFW en het Financial Services Data Model is proprierty. Desondanks is er toch de nodige vrij verkrijgbare informatie beschikbaar. Zelf ben ik aanwezig geweest bij een tweedaagse sessie, waarbij IFW-specialisten uitleg hebben gegeven over het model en de inhoud. Specialisten uit diverse afdelingen van een bank waren aanwezig, om het model te beoordelen voor gebruik in een data warehouse project. De informatie architecten van de bank hadden in het verleden al de ambitie opgegeven om tot een geïntegreerd gegevensmodel over de afdelingen heen te komen. Tijdens die sessie bleek dat de beelden die de specialisten over de gegevens in bank hadden, nauwelijks van elkaar afweken. Afdelingsspecifieke details bleken al vaak al in de hiërarchie aanwezig of konden vrij gemakkelijk aan het model worden toegevoegd. Na aanpassing in het model konden binnen een uur aangepaste prototypes van rapporten worden getoond, met daarin de nieuwe gegevenselementen verwerkt.

In de communicatie tussen personen met verschillende expertise is het Business Data Concept model een bruikbaar hulpmiddel. Het biedt het een goede basis voor verschillende technische modellen die in automatiseringtrajecten worden toegepast. Het business data concept model in combinatie met daarvan afgeleide modellen worden al meer dan 10 jaar succesvol commercieel op de markt gebracht. Binnen het domein bankbedrijf lijkt IFW Business Data Concepts Classification de belofte te kunnen waarmaken die aan ontologieën worden toegekend.

9. Investeren in een organisatiebrede taxonomie

Investeringen in taxonomieën zullen zelden of nooit op directe wijze tot kostenbesparingen omzetverbeteringen leiden. Het kan het beste worden gepositioneerd als een infrastructurele investering om bedrijfsbrede strategische doelen te ondersteunen. Dit is te illustreren aan de hand van het model (figuur 9) van Weill en Broadbent [1998] om investeringen in een IT investeringsportfolio te positioneren.


�Management Objectives

Infor-mational Strategic

Transactional

Infrastructure

�Increased control�Better information�Better integration�Improved quality

�Business integration�Flexibility & agility�Reduced marginal cost of IT�Reduced IT costs over time�Standardization

�Increased sales�Competitive advantage�Competitive necessity�Market positioning�Innovative services

�Cut costs�Increased , throughput

Positionering

van de

investering in taxonomieën -Types of IT investments-

Based on Weill, P. & Broadbent, M, 1998)

Figuur 9 Een opdeling in type IT-investeringen, afgezet tegen mogelijke management doelstellingen

De investering kan indirect een bijdrage leveren aan:

• de snellere realisatie van business integratie oplossingen:

• een hogere flexibiliteit en wendbaarheid van de geautomatiseerde systemen (Infrastructural);

• een betere informatie en een verbeterde kwaliteit en integratie van informatie (Informational);

• E-business initiatieven waarmee de strategische concurrentie positie van een bedrijf kan worden verbeterd (Strategic).

De positieve bijdragen die een organisatiebrede taxonomie kunnen bieden is als volgt samen te vatten:

• Het sneller en op een semantisch verantwoorde wijze kunnen koppelen van heterogene en geautomatiseerde systemen.

• Minder fouten en conflicten als gevolg van minder onduidelijkheden over de semantiek van gegevens.

Investeringen kunnen pas iets kunnen opleveren wanneer de taxonomieën actief in projecten en het dagelijkse werkzaamheden worden toegepast.

10. Conclusies

In veel publicaties worden ontologieën en de lichtgewichte versie ervan, een taxonomie, als oplossing aangedragen voor een groot aantal communicatieproblemen waarbij geautomatiseerde systemen betrokken zijn. Veel minder informatie is beschikbaar over de wijze waarop een ontologie of taxonomie in de praktijk het beste ontwikkeld, onderhouden en toegepast kan worden. Voor bedrijfsbrede taxonomieën blijkt de facetted classification aanpak tot praktisch bruikbare resultaten te leiden. In het bijzonder de specifieke invulling die binnen IBM’s IFW wordt gehanteerd, heeft zich in de praktijk bewezen. Het biedt:

• ondersteuning bij het oplossen van communicatieproblemen tussen verschillende expertisedomeinen;


• vorm en structuur waardoor redundantie in concepten en bijbehorende termen eenvoudig kan worden voorkomen;

• uitbreidbaarheid zonder dat de hoofdstructuur van de taxonomie gewijzigd hoeft te worden;

• een stabiel uitgangspunt voor meer formele modellen, die noodzakelijk zijn voor volledige geautomatiseerde communicatie en verwerking;

• een mogelijke basis voor een kennisapplicatie waar gebruikers geïnformeerd worden over de betekenis van de termen en hun afhankelijkheden, die binnen een bedrijf worden gehanteerd.

Indien een bedrijf besluit om met een ontologie te gaan aanschaffen en/of ontwikkelen, dan is het aan te bevelen om kennis te nemen en eventueel gebruik te maken best practices die binnen IBM’s IFW Business Data Concepts Classification zijn toegepast.

Referenties

[Darke, 1999] Darke P. & Shanks G., Understanding corporate data models, Information & Management, Volume 35, Issue 1, 4 January 1999.

[Evernden, 1996] Evernden R., The Information Framework. IBM Systems Journal, Vol. 35, No. 1. 1996

[Gruber, 1993] Gruber, T., A Translation Approach to Portable Ontology Specifications. In Knowledge Acquisition, 5(2), 1993.

[Gruber, 1993] Gruber, T., Towards Priciples for the Design of Ontologies Used for Knowledge Sharing. - In: N. Guarino, R. Poli (Eds.), Formal Ontology in Conceptual Analysis and Knowledge Representation. Boston: Kluwer Academic Publishers,1995.

[Gruninger, 2002] Gruninger M. & Lee J., Ontology Applications and Design, Communications of the ACM, February 2002, Vol. 45, No.2.

[IBM, 2002] IBM, IFW Object Models, General Information Manual, 2002.

[IBM, 2002a] IBM, IFW Critical Business Process Models. General Information Manual, 2002.

[IBM, 2002b] IBM, Implementing Message Based Integration Using the IFW / IAA Object Models, Release 1.0, First Edition, July 2002.

[IBM, 2002c] IBM, Building Components with the IFW / IAA Object Models, Release 1.0, First Edition, July 2002.

[IBM, 2004] IBM, Information FrameWork Object Models solution from IBM, http://www1.ibm.com/industries/financialservices/doc/content/solution/391981103.html, 2004.

[Laudon, 2004] Laudon K. & Laudon P., Management Information Systems, Managing the digital firm, 8th Ed. New Jersey, Pearson Education, 2004.

[Madsen, 2004] Madsen, B.,Terminological ontologies, Ph.d. course on representation formalisms for ontologies, Copenhagen, 30.10.-1.11.02

[Maedche, 2002] Maedche, A., Ontology Learning for the Semantic Web. Kluwer Academic Publishers, Boston, MA, 2002.

Ing. R.H.W. Claassens MIM

SNS Bank

[email protected]


[McComb, 2003] McComb, D., Semantics in Business Systems -- The Savvy Manager's Guide, Morgan Kaufmann, 2003.

[Modelware, 1999] Modelware International, White paper: The Business Classisfication Model, 1999.

[Ogden, 1923] Ogden, C. K. & Richards, I. A., "The Meaning of Meaning." 8th Ed. New York, Harcourt, Brace & World, Inc, 1923.

[Orbst, 2005] Orbst, L., Ontologies and the Semantic Web: An Overview, MITRE Information Semantics Center for Innovative Computing & Informatics, www.xml.saic.com/icml/ic_mwg/ Obrst-Semantic_Web-Intro11.ppt, 2005.

[Prieto-Díaz, 2002] Prieto-Díaz R., A Faceted Approach to Building Ontologies, Commonwealth Information Security Center, James Madison University, 2002.

[Ranganathan, 1967] Ranganathan, S.R., Prolegomena to Library Classification. Asian Publishing House, Bombay, India, 1967.

[Reimer, 2001] Reimer, U., Tutorial on Organizational Memories for Capturing, Sharing and Utilizing Knowledge. International Conference on Enterprise Information Systems, ICEIS 2001, Setubal, Portugal, July 7-10, 2001. http://research.swisslife.ch/~reimer/OM_Tutorial/index.html

[Smith, 2000] Smith B., Ontology: philosophical and computational, http://wings.buffalo.edu/philosophy/faculty/smith/articles/ontologies.html, 2000.

[Sowa, 1992] Sowa, J.F. & J.A. Zachman, Extending and formalizing the framework for information systems architecture, IBM Systems Journal, Vol. 31, No. 3, 1992.

[Sowa, 2000] Sowa, J. F. Knowledge Representation, Logical, Philosophical and Computational Foundations. Brooks Cole Publishing Co, 2000.

[Toivonen, 2003] Toivonen, S., Ontologies, Course 582407: Software Agent Technology, VTT Information Technology 3.3, 2003.

[Uschold, 1996] Uschold, M. & Gruninger, M., Ontologies: principles, methods, and applications, Knowledge Engineering Review, 11(2), 1996.

[Weill, 1998] Weill, P. & Broadbent, M., Leveraging the new infrastructure. Harvard Business School Press, 1998.

[Welty,2000] Welty, C., Ontology-Driven Conceptual Modeling, IBM Watson Research Center, 2000. http://ontolog.cim3.net/file/resource/presentation/OntoClean--ChrisWelty_20041118/OntoClean-2004v1--ChrisWelty_20041118.ppt

[Zachman, 1987] Zachman, J. A., A Framework for Information Systems Architecture, IBM Systems Journal 26, No. 3, 1987.

Semantische interoperabiliteit met behulp van een bedrijfsbrede taxonomie

Data & Analytics

Transcript of Semantische interoperabiliteit met behulp van een bedrijfsbrede taxonomie