Semantische interoperabiliteit met behulp van een bedrijfsbrede taxonomie

Transcriptie

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 February

2 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 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 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. 1) The Meaning Triangle Concept(s) (in mind) or thougt idea intension Symbolize Refers to Symbol(s) or term label code Stands for Referent(s) -or thing object extension Jaguar 2) Example of the ambiguity of symbols (Based on Ogden & Richards, 1923) Figuur 1 Een voorbeeld van semantische misinterpretatie February

3 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 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 ISAraamwerk 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 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 February

4 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 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.... Human Agent 1 (HA1) Human Agent 2 (HA2) Machine Agent 1 (MA1) Machine Agent 2 (MA2) The Meaning Triangle Concept Symbolize Refers to Symbol Referent Stands for exchange signs, e.g. nat. language JAGUAR exchange signs, e.g. protocols (H2H) (H2A),(H2A2H),(A2H) (A2A) Symbols / Syntactic structures HA1 Internal models HA2 MA1 Formal models MA2 Concepts / Semantic structures a specific domain, e.g. animals Things in the real world (H2H) (H2A),(H2A2H),(A2H) (A2A) Human to human Human to application & Application to human Application to application (Based on Maedche, 2002) = flow of communication and also the flow of semantics Figuur 2 Verschillende vormen van modellen en de verschillende vormen van communicatie February

5 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 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 en commitment gepositioneerd, in relatie tot de omgeving.... Human Agent 1 (HA1) Human Agent 2 (HA2) Machine Agent 1 (MA1) Machine Agent 2 (MA2) The Meaning Triangle Concept Symbolize Refers to Symbol Referent Stands for exchange signs, e.g. nat. language JAGUAR Ontology Description exchange signs, e.g. protocols Symbols / Syntactic structures Formal Semantics HA1 Internal models commit HA2 commit Ontology commit MA1 commit Formal models MA2 Concepts / Semantic structures a specific domain, e.g. animals Things in the real world commit (Based on Maedche, 2002) =The ontological commitment refers to agreements on the use of the shared vocabulary by the agents committed to the 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] February

6 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 -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. VIEW LEVEL SUBJECT PURPOSE LANGUAGE FORMALIZING philosophical pragmatic top level universal specific domain general task task independant specific specific application specific language independant formal not formal language independant Bodil Nistrup Madsen (2002), based on a.o.: 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, Ed. Nicola Guarino. Amsterdam: IOS Press. 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. February

7 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 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. February

8 1) Top-down Postulated Ontology 2) Bottom-up Synthesized Clusters 3) Revising & validating Ontology is modified based on how it maps to discovered clusters x s v w t u Clusters are mapped to D F E B A R. Prieto-Díaz (2002) C 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 bank- en 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 February

9 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. The Information Framework Types of infomation I) Organisation View II) Business View III) Technical View Levels of constraint Deconstruction level Composition level Implementation level Domain Concept (A-level) Domain Classification (B-level) Generic Template (C-level) Design Context (C -level) Operational Bound (D-level) Structure Strategy Skills Data Functions Workflow Solutions Interface Networks Platforms -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 February

10 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 February

11 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 ERschema 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 B-level Deconstruction level Involved Party (IP) Arrangement (AR) A-level Conditions (CN) Product (PD) Conceptual Location (LO) Event (EV) Classification (CL) Resource Item (RI) Business Direction Item (BD) 27 classification hierarchies 9 data concepts C-level & C -level Logical Composition level Physical Implementation level 54 business objects D-level 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. February

12 Explanation of the B-level -Concept Involved party (IP) scheme = Question + Answer(s) Individual INDIVIDUAL GENDER Female Male Involved Party(IP) 1. Fundamental hierarchy INVOLVED PARTY TYPE Organization INDIVIDUAL EMPLOYMENT STATUS ORGANIZATION LEGAL STRUCTURE TYPE Working Individual Not Employed Individual Corporation Partnership IP Descriptor 2. Descriptive hierarchy IP DESCRIPTOR TYPE IPName component IP NAME COMPONENT TYPE Given Name Name Initial Family name IP Relationship IP RELATIONSHIP TYPE IP/IP-relationship IP/IP RELATIONSHIP TYPE IP is spouse of IP IP is employee of IP 3. Relationship hierarchy IP is customer of 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. February

13 Management Objectives Increased control Better information Better integration Improved quality Business integration Flexibility & agility Reduced marginal cost of IT Reduced IT costs over time Standardization Positionering van de investering in taxonomieën Informational Strategic Transactional Infrastructure -Types of IT investments- Increased sales Competitive advantage Competitive necessity Market positioning Innovative services Cut costs Increased, throughput 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; February

14 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. Ing. R.H.W. Claassens MIM SNS Bank Richard.Claassens@SNS.NL Referenties [Darke, 1999] [Evernden, 1996] [Gruber, 1993] [Gruber, 1993] [Gruninger, 2002] Darke P. & Shanks G., Understanding corporate data models, Information & Management, Volume 35, Issue 1, 4 January Evernden R., The Information Framework. IBM Systems Journal, Vol. 35, No Gruber, T., A Translation Approach to Portable Ontology Specifications. In Knowledge Acquisition, 5(2), 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 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, [IBM, 2002a] [IBM, 2002b] [IBM, 2002c] [IBM, 2004] [Laudon, 2004] [Madsen, 2004] [Maedche, 2002] IBM, IFW Critical Business Process Models. General Information Manual, IBM, Implementing Message Based Integration Using the IFW / IAA Object Models, Release 1.0, First Edition, July IBM, Building Components with the IFW / IAA Object Models, Release 1.0, First Edition, July IBM, Information FrameWork Object Models solution from IBM, on/ html, Laudon K. & Laudon P., Management Information Systems, Managing the digital firm, 8th Ed. New Jersey, Pearson Education, Madsen, B.,Terminological ontologies, Ph.d. course on representation formalisms for ontologies, Copenhagen, Maedche, A., Ontology Learning for the Semantic Web. Kluwer Academic Publishers, Boston, MA, February

15 [McComb, 2003] [Modelware, 1999] [Ogden, 1923] [Orbst, 2005] [Prieto-Díaz, 2002] [Ranganathan, 1967] [Reimer, 2001] [Smith, 2000] [Sowa, 1992] [Sowa, 2000] [Toivonen, 2003] [Uschold, 1996] [Weill, 1998] [Welty,2000] [Zachman, 1987] McComb, D., Semantics in Business Systems -- The Savvy Manager's Guide, Morgan Kaufmann, Modelware International, White paper: The Business Classisfication Model, Ogden, C. K. & Richards, I. A., "The Meaning of Meaning." 8th Ed. New York, Harcourt, Brace & World, Inc, Orbst, L., Ontologies and the Semantic Web: An Overview, MITRE Information Semantics Center for Innovative Computing & Informatics, Obrst-Semantic_Web- Intro11.ppt, Prieto-Díaz R., A Faceted Approach to Building Ontologies, Commonwealth Information Security Center, James Madison University, Ranganathan, S.R., Prolegomena to Library Classification. Asian Publishing House, Bombay, India, 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, Smith B., Ontology: philosophical and computational, html, Sowa, J.F. & J.A. Zachman, Extending and formalizing the framework for information systems architecture, IBM Systems Journal, Vol. 31, No. 3, Sowa, J. F. Knowledge Representation, Logical, Philosophical and Computational Foundations. Brooks Cole Publishing Co, Toivonen, S., Ontologies, Course : Software Agent Technology, VTT Information Technology 3.3, Uschold, M. & Gruninger, M., Ontologies: principles, methods, and applications, Knowledge Engineering Review, 11(2), Weill, P. & Broadbent, M., Leveraging the new infrastructure. Harvard Business School Press, Welty, C., Ontology-Driven Conceptual Modeling, IBM Watson Research Center, ChrisWelty_ /OntoClean-2004v1--ChrisWelty_ ppt Zachman, J. A., A Framework for Information Systems Architecture, IBM Systems Journal 26, No. 3, February