Catalogus van instrumenten voor semantische interoperabiliteit Deliverable D3

INTEGRATE Fase 1

Catalogus van instrumenten voor semantische interoperabiliteit Deliverable D3

Datum: Versie: Auteur(s):

24 september 2008 1.11 Rogier Brussee (Telematica Instituut), Matthijs Punter (TNO), Jasper Roes (TNO) Opdrachtgever(s): Stichting Kennisnet, Forum Standaardisatie, TNO Informatie- en Communicatietechnologie, Telematica Instituut

INTEGRATE-project Postbus 589 7500 AN Enschede +31 (0)53 485 0485 Colosseum 27 7521 PV Enschede +31 (0)53 483 5200 http://www.integrate-project.nl

De Creative Commons Naamsvermelding-Niet-commercieel 3.0 Nederland Licentie is van toepassing op dit werk. Ga naar http://creativecommons.org/licenses/by-nc/3.0/nl/ of stuur een brief naar Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, VS om deze licentie te bekijken.

TNO-rapport | Catalogus van instrumenten voor semantische interoperabiliteit

3 / 63

Integrate

Inhoudsopgave 1 1.1 1.2 1.3

Inleiding .......................................................................................................................... 5 Doelstelling...................................................................................................................... 5 Aanpak............................................................................................................................. 6 Leeswijzer........................................................................................................................ 6

2 2.1 2.2 2.3 2.4 2.5

Definities en onderzoeksvraag ...................................................................................... 7 Definitie semantische interoperabiliteit ........................................................................... 7 Definitie semantisch model ............................................................................................. 8 Definitie semantische interoperabiliteitsprobleem........................................................... 9 Hoofdvraag en subvragen ................................................................................................ 9 Gebruik instrument .......................................................................................................... 9

3 3.1 3.2

Beslisboom .................................................................................................................... 13 Suggesties voor antwoorden .......................................................................................... 13 Boom ............................................................................................................................. 15

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Semantische modellen.................................................................................................. 17 Vergelijkingstabel.......................................................................................................... 17 Strings ............................................................................................................................ 18 Gecontroleerd vocabulaire............................................................................................. 20 Thesaurus....................................................................................................................... 23 Taxonomie ..................................................................................................................... 25 Metadata schema ........................................................................................................... 28 Gegevenscatalogus......................................................................................................... 31 Ontologie ....................................................................................................................... 32 Object gebeurtenismodel ............................................................................................... 38

5 5.1 5.2 5.3

Stappenplan voor ontwikkeling semantisch model................................................... 41 Inleiding......................................................................................................................... 41 Beschikbare methoden................................................................................................... 41 Stappenplan.................................................................................................................... 41

6 6.1 6.2 6.3 6.4

Checklist voor beheer van semantische modellen..................................................... 45 Inleiding......................................................................................................................... 45 Beheergebieden.............................................................................................................. 45 Beheergebieden gekoppeld aan semantische modellen ................................................. 47 Checklist ........................................................................................................................ 48

7 7.1 7.2

Tooling .......................................................................................................................... 49 Tools .............................................................................................................................. 49 Overzichtstabel tools en mogelijkheden ........................................................................ 55

8 8.1 8.2

Conclusies en aanbevelingen....................................................................................... 57 Conclusies...................................................................................................................... 57 Aanbevelingen ............................................................................................................... 57

9

Referenties .................................................................................................................... 59

TNO-rapport | Catalogus van instrumenten voor semantische interoperabiliteit Integrate

Bijlage(n) A Bestaande modellen voor inrichting van de beheergebieden B EDEX NTA C Uitwerking processen SETU case

4 / 63


5 / 63

Integrate

1

Inleiding Het delen van informatie en het koppelen van bedrijfsprocessen, binnen maar vooral ook tussen organisaties in ketens en netwerken, wordt meer en meer een noodzakelijke voorwaarde voor levensvatbaar commercieel handelen (in het bedrijfsleven) en voor het effectief aanpakken van maatschappelijke uitdagingen (voor de overheid). Tegelijkertijd bestaat er geen professioneel vak “Interoperabiliteit” waarmee deze uitdaging kan worden aangepakt. Zo hier en daar zijn technische en organisatorische ingrediënten wel versnipperd bekend of aanwezig, maar wordt het wiel steeds opnieuw uitgevonden. Andere onderdelen van het vak ontbreken nog grotendeels. Binnen de eerste fase van het Integrate project worden door het Telematica Instituut, TNO Informatie- en Communicatietechnologie, Kennisnet en Forum Standaardisatie een drietal instrumenten ontwikkeld die gebruikt kunnen worden om specifieke interoperabiliteitsproblemen aan te pakken, te weten: Instrumenten voor business case analyses voor interoperabiliteit, Kwaliteitsraamwerk voor standaarden en de Catalogus van instrumenten voor semantische interoperabiliteit. Dit document beschrijft de één van de drie instrumenten, de catalogus van instrumenten voor semantische interoperabiliteit. In dit document worden instrumenten gedefinieerd die gebruikt kunnen worden bij het bereiken van semantische interoperabiliteit tussen twee samenwerkende partijen.

1.1

Doelstelling Bij het uitwisselen van informatie tussen twee samenwerkende partijen is er regelmatig onduidelijkheid over de betekenis van de informatie die uitgewisseld wordt. De instrumenten die beschreven worden in dit document dragen bij aan het helder definiëren van de betekenis van de informatie die uitgewisseld wordt waarmee de interoperabiliteit tussen twee samenwerkende partijen versterkt wordt. Om het bereiken van semantische interoperabiliteit tussen twee samenwerkende partijen te ondersteunen definieert dit document een vijftal instrumenten: • Beslisboom: Als instrument te gebruiken voor het maken van een keuze tussen semantische modellen voor het vastleggen van de betekenis van informatie die uitgewisseld wordt tussen twee samenwerkende partijen. • Definities van semantische modellen: Te gebruiken als instrument voor het verkrijgen van inzicht in de semantische modellen. De definities van de volgende acht semantische modellen worden gegeven: − Strings − Vocabulaire − Thesaurus − Taxonomie − Metadata schema − Gegevenscatalogus − Ontologie − Object gebeurtenismodel


6 / 63

Integrate

• •

•

Stappenplan voor het ontwikkelen van een semantisch model: Als instrument te gebruiken bij het ontwikkelen van een semantisch model voor het vastleggen van de betekenis van informatie. Checklist voor het inrichten van een organisatie voor het beheer van semantische modellen: Te gebruiken als instrument om te controleren of een beheerorganisatie volledig is en om te dienen als lijst van benodigde zaken bij het inrichten van een beheerorganisatie. Overzichtstabel met tooling voor ondersteuning van ontwikkeling en beheer van semantische modellen: Te gebruiken als instrument om een tool te vinden die ondersteuning kan bieden bij de ontwikkeling van een semantisch model, of bij het beheer van een semantisch model.

De bovenstaande vijf instrumenten kunnen in combinatie gebruikt worden voor het ondersteunen van het proces van de keuze voor een semantisch model, het ontwikkelen van het semantische model en het beheren van een semantisch model. Dit hele document kan daarom zelf ook als een instrument worden beschouwd, waarbij de hierboven beschreven vijf instrumenten onderdeel zijn van het grotere instrument. De toepassing van dit document als instrument wordt toegelicht in paragraaf 2.5. 1.2

Aanpak Deze catalogus van instrumenten voor semantische interoperabiliteit wordt ontwikkeld op basis van desk research naar semantische modellen en procesbeschrijvingen rondom het ontwikkelen en beheren van semantische modellen. Omdat dit vakgebied echter nog in de kinderschoenen staat, is er niet direct literatuur gevonden die 1-op-1 betrekking heeft op het onderzoek dat voor dit instrument wordt uitgevoerd. Naast de desk research worden daarom ook casestudies uitgevoerd om te zorgen voor toepasbaarheid van de resultaten. De casestudies komen zowel uit de literatuur als vanuit de partners binnen het Integrate project.

1.3

Leeswijzer De opbouw van dit document is als volgt: • In hoofdstuk 2 worden de hoofdvraag en de subvragen gepresenteerd waarvoor dit document een antwoord biedt. • Hoofdstuk 3 presenteert een beslisboom om te bepalen welk semantische model het meest geschikt is om de informatie bij een interoperabiliteitsprobleem vast te leggen. • In hoofdstuk 4 worden een achttal semantische modellen besproken die gebruikt kunnen worden om semantiek vast te leggen. • Hoofdstuk 5 beschrijft het proces om een semantisch model te ontwikkelen • Hoofdstuk 6 beschrijft de processen waarmee de semantische modellen beheerd kunnen worden. • Hoofdstuk 7 geeft een overzicht van tools die beschikbaar zijn om zowel de ontwikkeling als het beheer van semantische modellen te ondersteunen. • In het laatste hoofdstuk, hoofdstuk 8, worden conclusies gepresenteerd en worden aanbevelingen gedaan voor vervolgonderzoek.


7 / 63

Integrate

2

Definities en onderzoeksvraag Dit hoofdstuk geeft de definitie van semantische interoperabiliteit die binnen dit instrument gehanteerd wordt. Hiernaast wordt in dit hoofdstuk ook vastgelegd wat de definitie is van een semantisch model en wat het semantische interoperabiliteitsprobleem waar over gesproken wordt precies is. Naast deze definities wordt de hoofdvraag, en de daaraan gerelateerde subvragen welke in dit instrument worden beantwoord gepresenteerd.

2.1

Definitie semantische interoperabiliteit Semantische interoperabiliteit betekent dat samenwerkende partijen aan gegevens, die uitgewisseld worden, dezelfde betekenis toekennen. Soms verdient het de voorkeur om deze betekenis van gegevens expliciet vast te leggen in een afspraak, een semantische interoperabiliteitsafspraak. Het vastleggen van de gegevens binnen de semantische interoperabiliteitsafspraak kan met behulp van de semantische modellen die in dit document worden beschreven. Semantische interoperabiliteit is niet gelijk aan syntactische interoperabiliteit. Waar het bij semantische interoperabiliteit gaat om het vastleggen van de betekenis van gegevens, gaat het bij syntactische interoperabiliteit om het vastleggen van de schrijfwijze (vorm of syntax) van de gegevens. Als voorbeeld van syntactische interoperabiliteit, waarbij de syntax wel expliciet is vastgelegd maar de semantiek niet, zou er gekeken kunnen worden naar een kommagescheiden bestand. Stel het bestand ziet er als volgt uit: Henk;Pietersen;ja;Molenweg;5;6543AB;Amsterdam Jan;Janssen;ja;Boomstraat;89;5124GH;Rotterdam Klaas;Franssen;nee;Amsterdamseweg;173;3645TG;Almere

In het bovenstaande voorbeeld is alleen de syntax beschreven van de informatie die uitgewisseld wordt. De afspraak hierbij is dat ieder gegeven bestaat uit zeven aparte delen, die worden gescheiden door een puntkomma. De semantiek is in bovenstaand voorbeeld niet vastgelegd. Voor de meeste mensen die bovenstaand voorbeeld zien is het niet moeilijk om de semantiek uit bovenstaande lijst af te leiden. De meeste mensen zullen al snel concluderen dat het gaat om persoonsgegevens, waarbij de voornaam, achternaam, adres, postcode en plaats zijn vastgelegd. Echter, voor computers is dit niet zomaar af te leiden. Tevens zou het ook nog zo kunnen zijn dat niet iedereen dezelfde betekenis toekent aan deze gegevens. De ene persoon zou ervan uit kunnen gaan dat het adres het huisadres van de persoon betreft, een ander persoon zou ervan uit kunnen gaat dat het gaat om het werkadres. Door de beoogde interpretatie van de gegevens ook expliciet vast te leggen kan ervoor worden gezorgd dat hierover eenduidigheid ontstaat. Door de semantiek te documenteren kan er voor gezorgd worden dat iedereen de gegevens op dezelfde manier interpreteert. Het maakt het ook mogelijk om computers de gegevens te kunnen laten interpreteren. Hieronder is hetzelfde voorbeeld wederom opgenomen, alleen is er nu ook semantiek van de gegevens vastgelegd door middel van de eerste regel.


8 / 63

Integrate

Voornaam;Achternaam;Thuisadres;Straat;Huisnummer;Postcode;Plaats Henk;Pietersen;ja;Molenweg;5;6543AB;Amsterdam Jan;Janssen;ja;Boomstraat;89;5124GH;Rotterdam Klaas;Franssen;nee;Amsterdamseweg;173;3645TG;Almere

De semantische modellen (een definitie van wat een semantisch model is wordt gegeven in paragraaf 2.2) die in dit document beschreven worden hebben als doel om de semantiek van informatie vast te leggen. Ze zijn niet direct bedoeld om te dienen als uitwisselingsstandaard of als basis om een systeem op te bouwen. Om deze zaken te regelen moet de semantiek uit de modellen gecombineerd worden met een syntactisch model. Samen zorgen deze twee zaken ervoor dat de informatie op een gestandaardiseerde manier uitgewisseld kan worden waarbij de betekenis van de informatie ook eenduidig is vastgelegd. 2.2

Definitie semantisch model De Linguïstische theorie van betekenis1 is gebaseerd op het werk van [Ogden & Richard, 1923] en [de Saussure, 1986]. Volgens Ullman’s theorie, is de betekenis van een woord de associatie van mensen tussen een concept, de referent, dat wil zeggen iets in de realiteit en een woord, dat wil zeggen een teken of symbool.

Figuur 1: Ogden-Richard’s driehoek

We vatten symbool nu meer algemeen op als georganiseerde informatie, en komen tot de volgende definitie: Een semantisch model is een klasse van informatie elementen en de wijze waarop deze informatie is georganiseerd. In de Ogden-Richard driehoek is het semantisch model dus de klasse van symbolen samen met de structuur van deze symbolen. De semantiek van een semantisch model is dan de beschrijving, met andere woorden de correspondentie tussen referent en symbool. Omdat deze gepaard is met conceptuele kennis (aannames, afspraken, procedures, conventies) is de betekenis, de semantiek, van het semantisch model extern aan het model zelf. Verschillende semantische modellen maken het wel mogelijk om verschillende aspecten van de realiteit effectief te beschrijven en vragen daarom meer 1

de z.g. Ullman Driehoek [Ullmann, 1972]

9 / 63


of minder gedeelde kennis om met behulp van symbolen uit dit model effectief over de referent te communiceren. 2.3

Definitie semantische interoperabiliteitsprobleem Het semantische interoperabiliteitsprobleem heeft steeds de volgende structuur. Twee partijen willen communiceren over een concept uit de reële wereld. Dit betekent dat beide partijen kennis moeten hebben van die reële wereld, en dat er overeenstemming moet zijn over de manier waarop die wereld wordt beschreven. Deze relatie tussen de manier van beschrijven en de concepten uit de reële wereld worden vastgelegd met een semantisch model. We onderscheiden twee vrijheidgraden voor een semantisch model. De horizontale vrijheid (of dekking), is de mate waarin het model de verschillende te beschrijven concepten kan omvatten. De verticale vrijheidsgraad is de mate van precisie waarin een gegeven beschrijving de reële concepten ook daadwerkelijk vastlegt. Deze vrijheidsgraden kunnen complementair zijn: meer precisie in een model kan ten koste gaan van beperkingen van het domein en meer gedeelde aannames of meer complexiteit om aannames expliciet te maken. Omgekeerd, een grote mate aan omvattendheid of genericiteit kan ten koste gaan van de precisie of vraagt om complexiteit om in expliciete stappen vanuit heel generieke gedeelde aannames verder te specialiseren. Of de dekking en precisie van een semantisch model voldoende zijn, heeft te maken met het doel van de samenwerking, de pragmatiek.

2.4

Hoofdvraag en subvragen De hoofdvraag die in dit document beantwoordt wordt luidt: ‘Hoe ontwerp, beheer en implementeer ik een geschikt semantisch model voor mijn interoperabiliteitsprobleem?’. Om deze hoofdvraag te beantwoorden zijn er meerdere subvragen opgesteld. Elk van deze vragen wordt beantwoord in de hoofdstukken die volgen na dit hoofdstuk. We onderkennen de volgende subvragen: Subvraag Welk semantische model is het meest geschikt om de betekenis van informatie bij mijn interoperabiliteitsprobleem vast te leggen? Welke semantische modellen bestaan er en wat zijn hun definities? Hoe ontwikkel ik een semantisch model? Hoe richt ik een organisatie in om de semantische modellen te beheren? Welke tooling is beschikbaar om semantische modellen te creëren? Welke tooling is beschikbaar om de ontwikkelen beheerprocessen te ondersteunen?

2.5

Hoofdstuk 3 4 5 6 7 7

Gebruik instrument Zoals beschreven in het eerste hoofdstuk is het mogelijk om ieder hoofdstuk zelfstandig te gebruiken als instrument. Het is echter ook mogelijk om de instrumenten die in de verschillende hoofdstukken worden gepresenteerd in combinatie te gebruiken. Door de instrumenten te combineren ontstaat er een nieuw instrument, waarbij de kans kleiner is dat er een essentieel onderdeel om semantische interoperabiliteit te bereiken wordt vergeten of overgeslagen.


10 / 63

Integrate

Het stappenplan om de combinatie van instrumenten volledig toe te passen ziet er als volgt uit:

1. Bepaal wat het meest geschikte semantische model is

1a. Doorloop de beslisboom door middel van de vragen

1b. Gebruik de vergelijkings tabel

2. Ontwikkel het semantische model

2a. Gebruik het stappenplan uit hoofdstuk 5

2b. Zoek naar geschikte tooling in hoofdstuk 7

1. Bepaal wat het meest geschikte semantische model is a. Doorloop de beslisboom door het beantwoorden van de vragen en bepaal wat het meest geschikte semantische model is. b. Indien 1a overgeslagen wordt: Maak als gevorderde gebruiker gebruik van de vergelijkende tabel in hoofdstuk 4 om een keuze te maken.

2. Ontwikkel het semantische model a. Gebruik het stappenplan dat beschreven is in hoofdstuk 5 om het semantische model te ontwikkelen. b. Zoek in hoofdstuk 7 tooling op die geschikt is om de ontwikkeling van het semantische model te ondersteunen.


11 / 63

Integrate

3. Richt het beheerproces in

3b. Geen beheerorganisatie: Richt een beheerorganisatie in 3c. Zoek naar geschikte tooling in hoofdstuk 7

3a. Indien er een beheerorganisatie is: kijk of deze volledig is

3. Richt het beheerproces in a. Indien er al een beheerorganisatie bestaat: bekijk of deze past binnen de beschrijving van het beheerproces zoals beschreven in hoofdstuk 6, en pas waar nodig de beheerorganisatie aan. b. Indien er nog geen beheerorganisatie bestaat: richt een beheerorganisatie in aan de hand van de beschrijving van het beheerproces in hoofdstuk 6. c. Zoek in hoofdstuk 7 tooling op die geschikt is om de beheerorganisatie in te richten of zoek tooling op die geschikt is om het beheerproces te ondersteunen.


12 / 63


13 / 63

Integrate

3

Beslisboom In dit hoofdstuk wordt een beslisboom gepresenteerd waarmee aan de hand van vragen die gerelateerd zijn aan eigenschappen van de semantische modellen kan worden bepaald welk semantisch model het meest geschikt is voor het vastleggen van de betekenis van informatie die uitgewisseld wordt tussen twee samenwerkende partijen. Bij deze beslisboom moet wel de kanttekening geplaatst worden dat er voor sommige interoperabiliteitsproblemen meerdere modellen geschikt zijn, en dat de uitkomst van de zoekboom dus niet altijd het enige bruikbare model biedt. In deze gevallen kan de beslisboom gebruikt worden om een eerste schifting te maken tussen de verschillende semantische modellen.

3.1

Suggesties voor antwoorden De beslisboom bevat vragen waarbij het niet altijd even eenvoudig kan zijn om een antwoord op de vraag te geven. Om het beantwoorden van de vragen makkelijker te maken is hieronder een tabel opgenomen met voor iedere vraag suggesties wanneer welk antwoord gegeven zou moeten worden. Tabel 1: Antwoord suggesties beslisboom

Vraag

Antw.

Suggestie

Moeten er in het model naast gegevens ook gebeurtenissen vastgelegd kunnen worden?

Gegevens en gebeurtenissen

Indien gebeurtenissen van belang zijn in het domein moeten deze opgenomen worden in de modellen. Voorbeeld van een gebeurtenis die van belang is: Het ontvangen van een urenbriefje, dit geeft namelijk aanleiding tot het opstellen en versturen van een factuur. Indien er geen gebeurtenissen zijn die van belang zijn in het domein van de interoperabiliteit is het alleen nodig om gegevens vast te kunnen leggen. Voorbeeld: Het vastleggen van de hiërarchie binnen het dierenrijk. Indien de gegevens zelf opgenomen moeten worden in het model moet dit antwoord gegeven worden. Voorbeeld: Een vastleggen van de opsomming van categorieën voor video’s (actie, humor, etc.).

Alleen gegevens

Moeten er in het model gegevens vastgelegd worden, of moet er vastgelegd worden welke informatie er over de gegevens opgenomen kan worden? Zijn er relaties tussen de gegevens, en is het relevant om deze vast te kunnen leggen

Gegevens

Informatie over

Ja

Indien de gegevens zelf niet in het model opgenomen moeten worden, maar er alleen vastgelegd moet worden welke informatie er vastgelegd moet worden moet dit antwoord gegeven worden. Een voorbeeld: Bij een video vastleggen dat de titel, leeftijdscategorie en de naam van de regisseur opgenomen moeten worden. Indien er relaties zijn tussen de gegevens en deze zijn ook nodig voor de uitwisselende partijen moeten ze opgenomen worden in de modellen. Voorbeeld: Beide organisaties hebben een andere naam voor extra gemaakte uren op een dag (overwerk en overuren), het is van belang dat in het model is


14 / 63

Integrate

in het model? Nee

Zijn de gegevens die vastgelegd moeten worden strikt hiërarchisch?

Zijn er meer relaties nodig dan: algemener, specifieker, gerelateerd, synoniem, geprefereerd, context? Is de informatie over de gegevens vast te leggen in één kolom, of zijn er meerder kolommen nodig? Moet de invulling van de gegevens vrij zijn, of moet deze beperkt zijn?

Ja

Nee

Ja

Nee

Één kolom

Meerdere kolommen

Vrij

Beperkt

vastgelegd dat de termen synoniem zijn. Indien er geen relaties zijn, of deze zijn niet relevant voor de uitwisseling. Voorbeeld: Twee organisaties hebben beide volledig hetzelfde begrip en kennis van het domein waardoor het niet nodig is om relaties vast te leggen. Indien de structuur van de gegeven strikt hiërarchisch is, moet hier ‘ja’ worden geantwoord: Voorbeeld: Het dierenrijk is strikt hiërarchisch georganiseerd en kan dus in een strikte hiërarchie worden vastgelegd. Indien de structuur niet hiërarchisch is, moet hier ‘nee’ worden geantwoord. Voorbeeld: Uursoorten die bij de ene partij als overuren worden geclassificeerd kunnen bij een ander bedrijf onder de gewone uren worden geclassificeerd. Indien met de genoemde relaties de gegevens die uitgewisseld worden onderling gerelateerd kunnen worden moet hier ‘ja’ worden geantwoord. Voorbeeld: Lijsten met steekwoorden en personen die gebruikt worden om audiovisueel materiaal te annoteren. Indien er ook andere relaties van belang zijn, moet hier ‘nee’ worden geantwoord. Voorbeeld: De relatie ‘gemaakt_in’ die vaak van belang is bij auto onderdelen is geen onderdeel van de genoemde set. Indien de informatie die vastgelegd moet worden uit één term bestaat kan er worden volstaan met één kolom. Voorbeeld: Termen om een video te classificeren bestaan uit één term. Indien de informatie die vastgelegd moet worden bestaat uit meerder termen, zijn er meerdere kolommen benodigd. Bijvoorbeeld het vastleggen van de naam, beschrijving en lengte van een stuk gereedschap. Indien beide partijen dezelfde kennis hebben van het domein, of er niet van tevoren een set met termen opgesteld kan worden kan de invulling van de gegevens vrijgelaten worden. Voorbeeld: Het annoteren van foto’s op het internet, iedereen kan er zijn eigen termen aan verbinden. Het antwoord ‘beperkt’ moet worden gegeven indien er een beperkte lijst moet zijn met mogelijkheden. Voorbeeld: Een beperkte lijst van videogenres.

15 / 63


3.2

Boom Onderstaande beslisboom kan worden gebruikt om, aan de hand van vragen welke gerelateerd zijn aan eigenschappen van de semantische modellen, te bepalen welk semantisch model het meest geschikt is voor het vastleggen van de betekenis van informatie die uitgewisseld wordt tussen twee samenwerkende partijen. Moeten er in het model naast gegevens ook gebeurtenissen vastgelegd kunnen worden? gegevens en alleen gegevens

gebeurtenissen

Moeten er in het model gegevens vastgelegd worden, of moet er vastgelegd De gegevens en

welke informatie er over de gegevens opgenomen kan worden?

gebeurtenissen worden georganiseerd met behulp van

informatie

een object-gebeurtenis model.

over

objecten

De gegevens die opgenomen kunnen worden

Zijn er relaties tussen de gegevens, en is het relevant

wordt vastgelegd in een schema dat de structuur

om deze vast te kunnen leggen in het model?

van de data weergeeft, een metadata schema. ja

Indien de velden in een metadata schema

nee

beperkt moeten worden tot een lijst is het mogelijk om hiervoor een vocabulaire, thesaurus

Is de informatie over de gegevens vast te leggen in

of taxonomie voor te gebruiken.

één kolom, of zijn er meerdere kolommen nodig? meerdere één kolom

kolommen

Zijn de gegevens die vastgelegd moeten worden strikt hiërarchisch?

Moet de invulling van de gegevens volledig

De gegevens kunnen ja

nee

vastgelegd worden een

vrij zijn, of moet deze beperkt zijn?

gegevenscatalogus. De volledig vrij

kolommen in de gegevens-

beperkt

catalogus kunnen vastgelegd worden met behulp van een

De informatie kan

metadata schema.

vastgelegd worden in een taxonomie.

Zijn er meer relaties nodig dan: algemener, specifieker, gerelateerd, synoniem, geprefereerd, context?

De gegevens kunnen

De gegevens kunnen

vastgelegd worden in

vastgelegd worden in

een string. De

een gecontroleerd

invulling van de string

vocabulaire. Er is een

is volledig vrij.

vastgestelde lijst met mogelijkheden.

ja

nee

De gegevens kunnen vastgelegd worden in een

De gegevens kunnen

ontologie. In het bijzonder zal de hiërarchie

vastgelegd worden in een

(meestal) kunnen worden geïnterpreteerd en

thesaurus.

gecodeerd als een ‘is_een’ hiërarchie. Andere formele relaties kunnen ook gedefinieerd worden.


16 / 63


17 / 63

Integrate

4

Semantische modellen In dit hoofdstuk wordt in paragraaf 4.1 een vergelijkingtabel gepresenteerd die door de gevorderde gebruiker gebruikt kan worden als vervanging van eerder gepresenteerde beslisboom. In de paragrafen 4.2 tot en met 4.9 worden acht veel gebruikte typen semantische modellen beschreven. De modellen worden daarbij grofweg van modellen met weinig structuur naar modellen met veel structuur beschreven. Per semantisch model worden daarbij de volgende zaken besproken: • Definitie, een definitie van het type semantische model, met een korte toelichting • Voorbeeld, een voorbeeld van het type semantisch model • Gebruik, een situatie waarin dit type semantisch model wordt ingezet • Gedeelde kennis, de gedeelde kennis die nodig is om effectief over de realiteit te communiceren bij gebruik van symbolen uit een semantisch model van dit type. • Semantiek, de wijze waarop de correspondentie tussen symbool en referent tot stand komt • Interoperabiliteit, de wijze waarop het gebruik van dit type semantisch model interoperabiliteit helpt, en wat de inherente valkuilen van het model op interoperabiliteitsgebied zijn. • Lopend voorbeeld `video annotatie’, de manier waarop het type semantisch model wordt gebruikt binnen de concrete context van het annoteren van video (toevoegen van informatie aan de video’s).

4.1

Vergelijkingstabel Deze paragraaf presenteert een vergelijkingstabel voor de semantische modellen. Voordat de tabel gepresenteerd wordt, wordt er aangegeven hoe iedere kolom geïnterpreteerd dient te worden en wat een ‘x’ in een rij betekend. Gebeurtenissen: Gebeurtenissen slaat op de mogelijkheid om binnen het model gebeurtenissen vast te leggen die van invloed zijn om het interoperabiliteitsprobleem dat opgelost dient te worden. Indien er in deze kolom een ‘x’ staat kan het model gebeurtenissen vastleggen. Informatie over: Sommige modellen leggen de gegevens vast die van belang zijn voor het interoperabiliteitsprobleem, andere modellen leggen vast welke informatie vastgelegd kan worden over de gegevens. Indien er in deze kolom een ‘x’ staat legt het model informatie over het object vast. Relaties: Modellen kunnen wel of geen relaties vastleggen tussen objecten. Een ‘x’ in deze kolom betekent dat het model relaties tussen de gegevens vast kan leggen. Relaties beperkt: Niet alle modellen bieden de mogelijkheid om zelf de relaties te bepalen die vastgelegd worden. Indien in deze kolom een ‘x’ staat betekend dit dat het model alleen de volgende relaties vast kan leggen: algemener, specifieker, gerelateerd, synoniem, geprefereerd, context. Hiërarchisch: Indien het model dat gebruikt wordt alleen een hiërarchische structuur vast kan leggen staat er in deze kolom een ‘x’.

18 / 63


Eén kolom: Indien de gegevens die opgeslagen moeten worden in één kolom op te schrijven zijn staat er een ‘x’ in de kolom. Vrije invulling: Sommige modellen staan toe dat de gegevens die opgenomen worden volledig vrij ingevuld kunnen worden, andere modellen beperkte de mogelijkheden om de gegevens vast te leggen. Indien de gegevens volledig vrij ingevuld kunnen worden bevat deze kolom een ‘x’.

Strings Gecontroleerd vocabulaire Thesaurus Taxonomie Metadata schema Gegevenscatalogus Ontologie Object Gebeurtenismodel

4.2

x x x x

Vrije invulling

Eén kolom

Hiërarchisch

Relaties beperkt

Relaties

Informatie over

Gebeurtenissen

Tabel 2: Vergelijkingstabel semantische modellen

x

x x

x x x

Strings Definitie. Een string is een eindig rijtje karakters uit een alfabet2. Een string is een zeer elementair semantisch model. Andere typen semantische modellen bouwen vaak voort op strings. Voorbeeld. Voorbeelden van strings zijn “abc xyz” en “123äø”. Gebruik. Strings worden overal gebruikt voor vrije tekstuele data. In het bijzonder worden strings gebruikt voor naamgeving. Zulke naamgeving strings kunnen voor mensen leesbaar gekozen worden. De ruimte van (oneindige) strings is oneindig groot en raakt dus nooit uitgeput 3. Tekstuele data zoals door mensen geschreven teksten wordt ook vaak opgevat als een lange string of een verzameling van strings. Computers kunnen strings in grote hoeveelheden verwerken en ongelofelijk snel zoeken naar het voorkomen van een string of string patroon. Ze zijn daarom erg geschikt voor volledige tekst zoekmethoden, met als duidelijkste voorbeeld zoekmachines als Google. Zonder dat Google ook maar iets van teksten begrijpt of aannames hoeft te maken over de woorden die op het internet voorkomen, kan ze toch het grootste deel van het internet indexeren en statistiek opbouwen over teksten en het voorkomen van string patronen zoals woorden en afkortingen. 2 3

De toevoeging ‘alfabet’ geeft hier aan dat de set van karakters vooraf beperkt is. Voor een string van 8 bit characters met lengte l zijn er 8l = 23l mogelijkheden.


19 / 63

Integrate

Gedeelde kennis. Voor het gebruik van strings als naamgeving is meestal heel weinig gedeelde kennis nodig buiten wereldkennis als het kennen van een naam. Ook voor het gebruik waarbij tekst als verzameling strings wordt opgevat is bijna geen kennis nodig. Dit geldt in het bijzonder voor de makers van software. Een applicatie ontwikkelaar hoeft bijna geen kennis te delen met de gebruiker anders dan gestandaardiseerde keuzes als karakter encoderingen. Daar staat tegenover dat het goed interpreteren van strings heel veel kennis kan vereisen. Een duidelijk voorbeeld is de manier waarop mensen als string gecodeerde woorden en grammatica gebruiken. Ook veel computertoepassingen kennen een zelfde soort gelaagdheid waarbij een veel ingewikkelder semantisch model is gecodeerd als tekst. Semantiek. Semantisch worden strings meestal gebruikt voor naamgeving van willekeurige referenten, inclusief gebruik als naamgeving voor informatie objecten als files of webpagina’s. In de laatste gevallen gebruiken we dan echter vaak strings met een iets ingeperkte vorm zoals “http://dit/is/een/url”. Merk op dat dezelfde referent verschillende namen kan hebben. Strings worden ook veel gebruikt voor het zoeken in teksten in natuurlijke taal. De semantiek van de string in een zoekopdracht is dan dat een zoekmachine al die teksten teruggeeft die deze zoek string bevatten. Google is daar een goed voorbeeld van. Interoperabiliteit. Strings zijn van belang voor semantische interoperabiliteit omdat voor veel toepassingen heel weinig specifieke gedeelde kennis nodig Als er geen expliciete afspraken hoeven te worden gemaakt over betekenis of notatie, maakt dit het gebruik van strings zeer breed toepasbaar. Voor veel naamgeving toepassingen kan worden vertrouwd op algemeen aanwezige wereldkennis over de naam van reëel bestaande objecten. De naam is belangrijke informatie over een object en vaak de ingang tot verdere informatie. Juist omdat strings zo eenvoudig zijn is op dit niveau tot standaardisatie te komen en het voorkomen van strings in teksten of databases effectief te checken. Strings hebben een grote dekkingsgraad (d.w.z. hebben een grote horizontale vrijheidsgraad: De referenten die door naamgeving met strings worden afgedekt vallen in wezen samen met de mogelijkheid van mensen om dingen te benoemen. Deze grote vrijheid levert ook problemen op. Gebruikers die content taggen met een vrije string zullen naast overwegend correct gespelde onderwerp woorden als “Economie” ook woorden gebruiken die een affect uitdrukken als “interessant” of woorden die alleen in de context van de gebruiker zin hebben als “Scriptie”. De grote vrijheid van het gebruik van strings leidt inherent tot een grotere variabiliteit en daarmee verminderde recall. Vrijheid lijdt ook tot het gebruik van woorden met een grotere ambiguïteit (dat wil zeggen een grote verticale vrijheidsgraad) en daarmee verminderde precisie Voor een preciezere interpretatie van een string, is meestal niet expliciet aanwezige contextinformatie nodig. Als gevolg hiervan is het zoeken naar de betekenis van teksten met behulp van strings een weinig precieze aangelegenheid. Om na te gaan of op het internet iets te vinden is

20 / 63


over een onderwerp, moet een zoeker bedenken welke strings gebruikt zouden kunnen zijn door een schrijver en dan Google (of een andere zoekmachine) vragen na te gaan welke documenten deze strings bevatten. We nemen daarbij op de koop toe dat er mensen zijn die een andere spelling of uitdrukking gebruiken of dat de string in een andere context een andere betekenis heeft. Bovendien accepteren we dat de volgorde waarin een zoekresultaat terugkomen een onduidelijke betekenis heeft. Er zullen weinig mensen zijn die zullen bestrijden dat Google zijn nut heeft en dat de interface met Google laagdrempelig is.

“Huisje”

“Boompje”

“Beestje”

“V1g@_”

Figuur 2: Strings voor benaming. Bijna alle strings worden niet als naam gebruikt

Lopend voorbeeld: Video Annotatie. Er zijn twee veelvoorkomende manieren om video materiaal te annoteren met strings. Een model is het annoteren video’s met willekeurige string tags zoals dat is gepopulariseerd door YouTube en del.icio.us . Omdat deze string tags volledig ongestructureerd zijn, kan een grote verscheidenheid aan tags worden uitgedeeld. Tags worden echter door mensen uitgedeeld. Aangezien het zowel handig als sociaal gewaardeerd is om tags uit te delen die iets met de video te maken hebben (meestal over de inhoud, aangezien titel en maker vaak al zijn aangegeven), en tags die aan een privé context refereren een grotere variabiliteit plegen te vertonen, zullen inhoudstags relatief vaak worden gebruikt. Daarnaast worden video’s natuurlijk geannoteerd met beschrijvende teksten in natuurlijke taal. 4.3

Gecontroleerd vocabulaire Definitie. Een gecontroleerd vocabulaire4 is een eindige opsomming van woorden of termen [ANSI-NISO, 2005]. Van een oneindige (of heel erg grote) ruimte van strings beperkt een gecontroleerd vocabulaire de ruimte van mogelijkheden tot een beperkt aantal termen. De betekenis van de term wordt meestal impliciet gelaten of buiten het gecontroleerd vocabulaire gedocumenteerd. Voorbeeld. Voor de Nederlandse taal is het archetypische gecontroleerd vocabulaire het groene boekje. 4

Engels: controlled vocabulary


21 / 63

Integrate

Gebruik. Een gecontroleerd vocabulaire geeft aan welke woorden binnen een bepaalde context gebruikt kunnen worden. Het dwingt mensen om hun woordgebruik in te perken en verhoogt de kans dat alle deelnemers aan een communicatie proces het zelfde bedoelen met een woord, omdat van te voren duidelijk is wat de mogelijke keuzes zijn. Omdat er meestal geen synoniemen en afwijkende spellingen worden toegestaan, is een woord uit een gecontroleerd vocabulaire per definitie correct gespeld. Een typisch voorbeeld van een rolverdeling bij gebruik van een gecontroleerd vocabulaire is de volgende: Een annotator voegen een sleutelwoord toe aan content en een zoeker moet op basis van sleutelwoorden die content moet terugvinden. De zoeker heeft een grotere kans om te zoeken op een zinvol toegevoegd sleutelwoord als beiden kiezen uit een zelfde gecontroleerd vocabulaire. Het kunnen maken van een opsomming veronderstelt dat de context waarin het woord gebruikt wordt beperkt is. Het groene boekje bevat ruim 100.000 woorden5, en de Engelse taal nog veel meer. Inperken tot een lijst van bestaande woorden, kan daarom nog steeds een enorme vrijheid over laten. Aan grotere gecontroleerde vocabulaires worden daarom structuur toegevoegd en ontwikkelen zich tot thesauri en taxonomieën. Veel gecontroleerde vocabulaires die van toepassing zijn op een ingeperkt gebied zijn daarom veel kleiner en georganiseerd als platte keuze lijstjes6. Voor computersystemen betekent een beperkte lijst dat effectief kan worden gecontroleerd of te accepteren input is gegeven. In andere gevallen kan het gecontroleerd vocabulaire zo beperkt zijn dat de betekenis van elke term kan worden gestandaardiseerd en bijvoorbeeld een computersysteem of een organisatie op elk woord anders kan reageren. Heel kleine gecontroleerd vocabulaires vinden we terug in keuzemenu’s in gebruikersinterfaces of als expliciet genummerde mogelijkheden voor waarden van velden in metadata schema’s7.

Huis

Boom

Figuur 3: Gecontroleerd vocabulaire met afgebakend toepassingsgebied. Doorgestreepte objecten vallen buiten het toepassingsgebied en hebben geen term in het gecontroleerd vocabulaire.

5

http://www.hetgroeneboekje.nl/meerweten.html Engels: pick-list [ANSI-NISO, 2005] 7 Een voorbeeld hiervan is het IntendedEndUser veld in de IEEE-LOM. De LOM kent ook velden zoals Contributor.Role waar woorden uit een gecontroleerd vocabulaire een geprefereerde status hebben als best practice met de onderliggende aanname dat deze in elk geval begrepen worden, zonder dat andere woorden worden uitgesloten 6


22 / 63

Integrate

Gedeelde kennis. De gedeelde kennis voor het gebruik van een gecontroleerd vocabulaire is de passieve kennis van de betekenis van de termen daarin. Een gebruiker moet dus de referenten van de termen in het gecontroleerd vocabulaire kennen en in een gegeven geval de beste (of een goede) keuze uit de lijst maken. Het gecontroleerd vocabulaire zelf is een expliciet gedeelde context. Semantiek. Een gecontroleerd vocabulaire wordt semantisch gebruikt voor naamgeving van een van te voren begrensd aantal dingen, bijvoorbeeld onderwerpen waarop content wordt gerubriceerd of mappen op een computer. Het toekennen van een term uit een gecontroleerd vocabulaire levert onmiddellijk een vaste categorisering op, met een categorie voor iedere afzonderlijke term uit het gecontroleerd vocabulaire. Interoperabiliteit. Gecontroleerde vocabulaires kunnen semantische interoperabiliteit vergroten omdat actief bedenken van termen door verschillende mensen grotendeels wordt gereduceerd tot passief herkennen met de lijst als gedeelde context. In het bijzonder kan vooraf een geprefereerde term uit een verzameling synoniemen of spellingsvormen worden gekozen en kunnen ambigue termen worden vermeden. Ook kunnen expliciet afspraken worden gemaakt over de betekenis van elke term van het gecontroleerd vocabulaire. Dit is vooral praktisch als het gecontroleerd vocabulaire klein is, zoals binnen een menu van een grafische gebruikersinterface of binnen een standaard voor een beperkt aantal toegelaten termen als waarden van een veld. Bij een gecontroleerd vocabulaire is de dekking (horizontale vrijheidsgraad) bij voorbaat beperkt tot de termen die het bevat. De precisie (verticale vrijheidsgraad) van een gecontroleerd vocabulaire (verticale vrijheidsgraad) hangt sterk af van de mogelijkheid om het domein bij voorbaat voldoende in te perken. In een breed domein moeten we accepteren (of wensen!) dat dezelfde term voor een veelheid aan objecten wordt gebruikt. Het van te voren opsommen van alle relevante termen kan in de praktijk een moeizame exercitie zijn. Bovendien kan een domein in de loop der tijd veranderen, en kan er daarmee behoefte ontstaan aan termen die niet in het gecontroleerd vocabulaire zijn opgenomen. Lopend voorbeeld `Video Annotatie’. Bij video annotatie wordt vaak een genre toegevoegd uit een beperkte lijst. Een voorbeeld van een beperkte lijst met genres is de Internet Movie Database (IMDb) [IMDb, 2008]. Dit is een lijst van 27 genres bedoeld voor films. We zien hier meteen de kracht en de beperking van een vaste lijst. Voor elk van de genres kan een lijst van meest geliefde films in het genre worden samengesteld, maar ook is een alom gebruikt genre als soap opera niet aanwezig, ondanks dat IMDB tegenwoordig ook Tv-programma’s in haar database heeft zitten. Een technisch voorbeeld van een gecontroleerd vocabulaire is de lijst van bestandextensies en mime types. Deze moeten bij Windows worden geregistreerd samen met het programma dat moet worden opgestart om het bestand af te spelen, bijvoorbeeld Windows Mediaplayer voor een .avi bestand en Quicktime voor een .mov bestand.

23 / 63


4.4

Thesaurus Definitie. Een thesaurus is een opsomming van woorden met een welgedefinieerde ordening en gestandaardiseerde onderlinge relaties [ANSI-NISO, 2005]. Het Engelse woord thesaurus betekent synoniemen woordenboek. Dit geeft de goede intuïtie. Een thesaurus is een verbijzondering van een gecontroleerd vocabulaire waarin we naast een opsomming van termen ook een aantal van te voren bepaalde relaties tussen die termen aangeven. Deze relaties liggen grotendeels op het niveau van de betekenis van de termen, bijvoorbeeld de synonymie relatie, en maakt het mogelijk termen te organiseren meestal hiërarchisch in meer en minder specifieke termen. Voorbeeld. Een typisch voorbeeld zijn die thesauri die zijn opgebouwd volgens de ANSI/NISO Z39.19-2005 standaard voor eentalige thesauri [ANSI-NISO, 2005] voortbouwend op ISO-ANSI 2788:1986. Deze veel gebruikte standaard definieert relaties tussen termen op semantisch niveau (i.h.b. algemenere term (broader term, BT), specifiekere term (narrower term, NT), gerelateerde term (related term, RT) en synoniem (synonym SY) ) gebruiksniveau (i.h.b. geprefereerde term (preferred term USE, SEE), niet geprefereerde term (used for UF) en context noot (scope note SN)), en verklaringsniveau (i.h.b. verklaring ook gevat als scope note (SN) ). Een goed voorbeeld van een dergelijke thesaurus is de GTAA, Gemeenschappelijke Thesaurus Audiovisuele Archieven van het instituut voor beeld en geluid. [De Jong, 2007; Choice, 2008b]. Het dekt een breed scala aan onderwerpen aangezien hij bedoeld is voor alles wat op de Nederlandse Radio of TV wordt uitgezonden. De GTAA bevat ongeveer 160.000 termen onderverdeeld in 6 groepen (facetten), steekwoorden (3800 geprefereerde termen), locaties (14000), persoons-, organisatie-groep-overige en maker namen (97000 +27000 +18000) en genres (113). Een vergelijkbaar voorbeeld is de Engelse thesaurus UKAT die is gemaakt op basis van een thesaurus van de UNESCO [UKAT, 2008a; UKAT, 2008b].

Huis

Dier

Boom BT

Gebouw

BT

BT Plant

BT

Figuur 4: Thesaurus met relaties tussen termen

Natuur

Boom (wisk) USE Beest


24 / 63

Integrate

Gebruik. Een thesaurus wordt als gecontroleerd vocabulaire vaak gebruikt voor onderwerp steekwoorden en andere content annotaties. Ze zijn vaak groot en tijdrovend om te maken. Hoewel een thesaurus als een gecontroleerd vocabulaire woorden of termen organiseert, geeft de ordening naar semantische relaties de termen voor mensen ook de rol van de begrippen die ze representeren. Een verzameling van synoniemen (de synsets of synoniem ringen) wordt de facto een representatie van een semantisch begrip met de geprefereerde term als naam. Content geannoteerd met een term uit een thesaurus, is niet alleen geannoteerd met de term als steekwoord maar via de thesaurus relaties, de facto ook met al zijn synoniemen, de geprefereerde term en daarmee met het begrip dat de geprefereerde term representeert. Daarnaast is een verbinding gelegd met gerelateerde, bredere en smallere termen. Dit veronderstelt echter wel dat er een ondersteuning aanwezig is die deze verbindingen met synoniemen en gerelateerde termen ook daadwerkelijk laat zien. Omdat een thesaurus wereldkennis vastlegt worden thesauri ook gebruikt om een conceptueel overzicht van een domein te geven. Daarbij ligt dan de nadruk op het begrip dat een woord representeert. Gedeelde kennis. Net als bij het gebruik van een gecontroleerd vocabulaire veronderstelt het gebruik van een thesaurus dat mensen de betekenis van termen kennen en de juiste keuze kunnen maken bij een gegeven onderwerp. In een zeer grote lijst wordt dit een lastige opgave en is de kans dat verschillende mensen, bijvoorbeeld annotator en zoeker binnen hun eigen context tot de zelfde keuzes komen gering. De thesaurus relaties overbruggen die scheiding echter omdat zowel zoeker en annotator met de thesaurus termen kunnen vinden, door uitgaande van algemene termen naar een toepasselijke bijzondere en geprefereerde term te navigeren. Ze kunnen bovendien op gerelateerde termen wordt gewezen die ook van toepassing zouden kunnen zijn. De thesaurus fungeert daarbij gedeelde gestructureerde context. Semantiek. Een thesaurus wordt semantisch gebruikt voor een van te voren begrensde naamgeving i.h.b. voor steekwoorden van conceptuele zaken als onderwerpen. De semantische relaties als SY, BT, NT and RT geven aan dat het om namen van respectievelijk, de zelfde, meer algemene, bijzonderder en gerelateerde onderwerpen gaat. Semantische relaties als broader term of narrower term zijn daarbij min of meer informele begrippen die aansluiten bij onze intuïtieve begrip voor meer en minder algemeen zonder gebonden te zijn aan streng formele eigenschappen. In het bijzonder wordt de BT relatie niet altijd opgevat als transitieve relatie. Interoperabiliteit. Als gecontroleerd vocabulaire kan de thesaurus interoperabiliteit vergroten door de keuzevrijheid te beperken (zie de interoperabiliteitssectie van het gecontroleerd vocabulaire). Een thesaurus helpt daarbij het probleem van een grote hoeveelheid benodigde gedeelde kennis op te lossen (zie gedeelde kennis sectie). Thesauri dekken meestal een groot gebied af op heel brede termen (grote horizontale vrijheidsgraad). De mate waarin smallere termen deelgebieden afdekken kan nogal verschillenen. Dit betekent dat de precisie (verticale vrijheidsgraad) per deelgebied nogal kan verschillen.


25 / 63

Integrate

Aangezien thesauri snel zo groot kunnen worden dat mensen niet meer op de hoogte zijn (en blijven!) van alle ins en outs van de thesauri, is de mogelijkheid om systeemondersteuning te kunnen bieden vaak essentieel voor de meerwaarde van de extra relaties. Een andere valkuil is dat er vaak veel nadruk ligt op een hiërarchische organisatie van termen (broader term / narrower term), maar dat dit net altijd een goede weerspiegeling geeft van semantische verwantschap. Zo een hiërarchie werkt goed voor termen als “Piloten” en “Mensen”. In de UKAT vinden we een bijvoorbeeld een pad Pilots BT Transport Personel BT Personel BT BT People

Er lijkt in de UKAT echter geen pad te zijn van Pilot naar Aviation. In de GTAA vinden we overigens wel een pad Piloten RT Vliegtuigen RT Luchtvaart. Lopend voorbeeld `Video Annotatie’. Het annoteren van video materiaal met steekwoorden uit een thesaurus is een typisch geval van de manier waarop archivarissen te werk gaan. Binnen het Nationale Audiovisuele Archief Beeld en Geluid zijn er bijvoorbeeld 45 personen mee bezig. De GTAA is speciaal voor dit doel samengesteld en is een integraal onderdeel van het informatie model (iMMix) van het beeld en geluid archief [De Jong, 2007]. Archivarissen hebben een fijn gevoel ontwikkeld om thesaurus termen te vinden die verschillende aspecten van de video afdekt en kennen bovendien een groot deel van de bovenste lagen. Niettemin wordt computerondersteuning gebruikt om snel de weg te vinden in de thesaurus. Er is een compleet NWO project (Choice) om archivarissen extra ondersteuning te geven door thesaurus termen te suggereren op basis van bij de video geleverde beschrijvingen [Choice, 2008a]. Programmamakers maken gebruik van de thesaurus bij het zoeken naar video content voor programma’s. 4.5

Taxonomie Definitie. Een taxonomie is een hiërarchische ordening van klassen [Van Dale, 1997; Wikipedia, 2008a]. Het woord taxonomie komt uit de biologie waar organismen hiërarchisch worden gegroepeerd in klassen van organismes die nauwer aan elkaar verwant zijn naarmate ze meer classificatie criteria gemeenschappelijk hebben. Het vinden van zulke classificatie criteria voor de verschillende groepen (taxa) is een klassiek onderdeel van de biologie. Tegenwoordig weten we dat de “tree of life” is terug te voeren op fundamentele genetische verwantschap en evolutionaire ontwikkeling8. Hiërarchische classificaties worden echter in veel meer domeinen gebruikt. Daarbij gaat het vaak om een ordening van meer of minder specifieke concepten binnen een bepaald domein. Voorbeeld. Een thesaurus met alleen broader term en narrower term en synoniem relatie levert9 een hiërarchisch georganiseerde taxonomie van termen (of preciezer, van synonymie klassen van termen). Dit is de zin waarin de term taxonomie wordt gebruikt in ANSI/NISO Z39.19-2005.

8

Dichtbij de wortel is de ``tree of life’’ strict genomen geen boom omdat primitieve organismen DNA van elkaar hebben overgenomen en organellen als mitochondrien en chloroplasten van Eukaryoten uit symbiose met bacteriën zijn ontstaan. 9 Eventueel door transitieve afsluiting van de BT relatie tot een BTtrans relatie


26 / 63

Integrate

Een typisch voorbeeld van een onderwerp taxonomie is de Library of Congres Classification (LCC) [LCC, 2008]. De bovenste laag van deze LCC classificatie ziet er als volgt uit * A -- GENERAL WORKS * B -- PHILOSOPHY. PSYCHOLOGY. RELIGION * C -- AUXILIARY SCIENCES OF HISTORY * D -- WORLD HISTORY AND HISTORY OF EUROPE, ASIA, AFRICA, AUSTRALIA, NEW ZEALAND, ETC. * E -- HISTORY OF THE AMERICAS * F -- HISTORY OF THE AMERICAS * G -- GEOGRAPHY. ANTHROPOLOGY. RECREATION * H -- SOCIAL SCIENCES * J -- POLITICAL SCIENCE * K -- LAW * L -- EDUCATION * M -- MUSIC AND BOOKS ON MUSIC * N -- FINE ARTS * P -- LANGUAGE AND LITERATURE * Q -- SCIENCE * R -- MEDICINE * S -- AGRICULTURE * T -- TECHNOLOGY * U -- MILITARY SCIENCE * V -- NAVAL SCIENCE * Z -- BIBLIOGRAPHY. LIBRARY SCIENCE. INFORMATION RESOURCES (GENERAL) De classificatie is een laat 19de-eeuws Amerikaans systeem, bedoeld om boeken en documenten te ordenen (letterlijk hun plaats in de boekenkast). De ordening ontbeert een solide theoretische basis. De classificatie is gebaseerd op praktische overwegingen voor een bibliotheek en niet op basis van epistemologie Wikipedia, 2008d]. De LCC is verder verfijnd naarmate we dieper afdalen in de hiërarchie: de papieren versie omvat eenenveertig delen. Op nationaal niveau is er in Nederland momenteel ook een ‘taxonomie’ in ontwikkeling: de Nederlandse Taxonomie. We classificeren de Nederlandse Taxonomie echter als een ontologie, en bespreken de Nederlandse Taxonomie daarom in sectie 4.8. Gebruik. Een taxonomie wordt op grote schaal gebruikt in bibliotheken, archieven en andere instellingen die grote hoeveelheden content rubriceren. De namen van de onderwerpen vormen een gecontroleerd vocabulaire voor onderwerpen en worden vaak gebruikt in nauwe relatie met een thesaurus. Hiërarchisch geordende classificatie systemen zijn echter in veel gebieden van toepassing, bijvoorbeeld de computer bestanden in mappen, of instanties van klassen in georiënteerde computer taal in objecthiërarchieën. Op wetenschappelijk gebied vinden we taxonomieën variërend van organismen tot grondsoorten en sterrenstelsels. Gedeelde kennis. Een taxonomie vraagt van partijen dat ze de begrippen en de structuur van de taxonomie kennen. Bij de taxonomie hoort een classificatie systeem aan de hand van eigenschappen. In een goed opgezette taxonomie volgt de


27 / 63

Integrate

beslissingsboom van die classificatie de taxonomische klasse indeling. Het doorlopen van zo een beslissingsboom kan heel gespecialiseerde kennis vragen zoals in het voorbeeld van de ”tree of life”. Semantiek. De semantiek van een taxonomie is een classificatie van objecten, begrippen of onderwerpen aan de hand van eigenschappen. Daarbij geeft de thesaurus de structuur van de beslissingsboom en de naam (of identifier) van de klasse. Meestal is de classificatie horend bij de taxonomie terug te voeren op een “is een” relatie waarbij elk geclassificeerd object of onderwerp in het bijzonder een object of onderwerp is in de boven liggende klasse. Deze “is een” relatie is echter vaak wat verborgen in de naam van de klassen en wordt vaak pas duidelijk nadat duidelijk wordt wat feitelijk geclassificeerd wordt (bijvoorbeeld onderwerpen gerelateerd aan de naam van de klasse, of bestanden toegankelijk vanuit een bepaalde map). Een taxonomische klasse heeft vaak alleen een eenduidige naam in het hele classificatie systeem als het volledige taxonpad van de wortel tot aan de klasse wordt meegenomen (vergelijk een bestandsnaam op een computer, die pas eenduidig is als het hele pad er voorstaat). Soms wordt dit taxon pad in de gecodeerde vorm in naam meegenomen zoals QA75.5 voor onderwerpen uit de informatica binnen de LCC.

Boom

Plant

Insect

Eukaryoot

Zoogdier

Dier

Figuur 5: Een beperkt deel van een taxonomie van levende wezens

Interoperabiliteit. Een taxonomie, vergroot semantische interoperabiliteit door voor verschillende partijen een classificatie schema te documenteren. Is een object eenmaal geclassificeerd (in een zinnig classificatie systeem) dan weten we iets zijn eigenschappen en hebben we daarmee een toegespitste context voor interpretatie. Het is redelijk dat in content met als onderwerp informatica (LCC codes QA75.5-QA76.95) het steekwoord boom moet worden geïnterpreteerd als datastructuur in plaats van een organisme. De namen (of identifiers) van taxonomie klassen vormen een gecontroleerd vocabulaire met de daarbij horende voordelen. Een taxonomie kan een breed veld beslaan (horizontale vrijheidsgraad) maar de precisie waarmee wordt geclassificeerd (verticale vrijheidsgraad) kan sterk variëren afhankelijk van het deel van de classificatie.


28 / 63

Integrate

Het nut van een van een taxonomie wordt grotendeels bepaald door de bijbehorende classificatie methode. Sluit een classificatie schema niet (meer) aan bij de te classificeren objecten of zijn de classificatie criteria niet duidelijk dan zullen verschillende partijen alsnog tot een verschillende classificatie komen. Taxonomieën kunnen erg groot worden zoals in het voorbeeld van de LCC. Typische redenen zijn de ontwikkeling van een domein, het steeds breder nemen van een domein, of de behoefte aan een fijnere classificatie die meer recht doet aan uitzonderingen. Een hiërarchische classificatie geeft vaak aanleiding tot andere relaties tussen klassen. Hiervoor is binnen een taxonomie strikt genomen geen plaats, maar taxonomieën kunnen wel onderdeel zijn van een rijker organisatie model. Bijvoorbeeld, in een thesaurus vinden we een taxonomie in de beperkte interpretatie van termen met alleen maar een breder dan, en synonymie relatie. Dit thema wordt verder uitgewerkt in paragraaf 4.8. Lopend voorbeeld “Video annotatie”. Video’s worden geclassificeerd op genre. De eerder genoemde IMDB-genres kunnen we verder opsplitsen in verdere verfijningen. Bij beeld en geluid worden video’s met een duidelijk onderwerp zoals journaals of documentaires ingedeeld op onderwerpen die verdeeld zijn in deelonderwerpen. Hierbij zijn dat bepaalde steekwoorden uit de thesaurus geassocieerd aan delen van de onderwerp taxonomie. De thesaurus en de taxonomie zijn min of meer duaal, bij een onderwerp zullen bepaalde steekwoorden vaker voorkomen en omgekeerd. Er is echter wel een neiging om een video een hoofd onderwerp te geven en de steekwoorden te gebruiken als verdere verfijning en specifieke onderwerpen. Een video van een nieuws onderwerp over stakende buschauffeurs kan dan bij de taxonomie horen onder Economie, en steekwoorden krijgen als Busvervoer, Deventer, Staking, Demonstratie. 4.6

Metadata schema Definitie. Een metadata schema is een opsomming van attributen van een klasse [NC Echo, 2007]. De gegeven definitie is een abstractie van een schema van tabel uit een database. De gebruikelijke interpretatie van “klasse” in de definitie van metadata schema is van een klasse van informatie objecten, zoals webcontent, boeken, of files op een filesysteem (de ``data’’). Als attributen nemen we hier voor de eenvoudig één of meer waardige relaties met concrete datatypen als getallen strings en calender data. Om naast controle over de attributen ook controle over de waardes van de attributen te hebben beschouwen we ook termen uit een gecontroleerd vocabulaire als concreet datatype. De verschillende attributen worden ook vaak velden genoemd omdat ze in een gebruikers interface vaak corresponderen met verschillende invulvelden. De attributen zijn van te voren beperkt. Door deze beperking kan worden gedocumenteerd welke data types de waarden hebben en hoe ze moeten worden geïnterpreteerd. Voorbeeld. Het archetypische voorbeeld van een metadata schema is Dublin Core (ISO 15836) [DCMI, 2008]. Het schema heeft een beperkt aantal velden zoals auteur, titel, steekwoord, formaat en rechten voor de bibliografische beschrijving van content. De waarden van de velden zijn vrije strings ook al wordt binnen een organisatie vaak afgesproken dat de strings een bepaalde vorm hebben en/of uit een gecontroleerd vocabulaire, thesaurus of taxonomie moeten komen. De binnen de onderwijskundige wereld veel gebruikte IEEE-LOM metadata standaard is ook een metadata schema.


29 / 63

Integrate

Gebruik. Een metadata schema wordt gebruikt om structuur aan te brengen in een verzameling gegevens, d.w.z. een gegevens catalogus. In de gebruikelijke zin van metadata als data over data worden deze gestructureerde gegevens gebruikt om andere informatie te beschrijven, bijvoorbeeld content. De structuur van de gegevens stelt ons in staat onderscheid te maken tussen een werk van Shakespeare en een werk over Shakespeare, omdat Shakespeare in het ene geval in het auteur veld en in het andere geval in het onderwerp veld staat. Gedeelde kennis. De kennis die nodig is om een metadata schema te gebruiken is de betekenis te kennen van elk van de velden, met andere woorden te weten hoe de verschillende aspecten van een object uiteen worden gerafeld en hoe, binnen de context van een veld daarmee om moet worden gegaan (bijvoorbeeld volgens de string, of gecontroleerd vocabulaire model). Omgekeerd kan het nodig zijn dat partijen weten hoe deze verschillende aspecten worden geïntegreerd. Semantiek. Een metadata schema geeft de structuur van de beschrijving van verschillende aspecten van (informatie) objecten Verschillende aspecten lenen zich voor verschillende beschrijving met verschillende semantische modellen die als waarde van het veld kunnen worden gekozen.

integer

id

unsigned integer

numkamer Huis

oppm2

unsigned integer

fotoURL opm

URL string

Figuur 6: Een metadata schema voor de organisatie van een gegevens collectie over huizen

Interoperabiliteit. Metadata schema’s vergroten de interoperabiliteit doordat de beschrijving van een object in verschillende aspecten uiteen wordt gerafeld. Dit maakt duidelijk welke aspecten gebruikt kunnen worden in de communicatie tussen verschillende partijen. Bovendien hoeven die partijen elkaar alleen te begrijpen binnen de context van elk aspect afzonderlijk. Opsplitsen zorgt voor een toename van de precisie (kleinere verticale vrijheidsgraad) van de beschrijving. Verschillende aspecten kunnen een veld krijgen met een verschillend semantisch model toegespitst op het aspect. Binnen de context van een zo een aspect/veld kan een semantisch primitief model als een string of getal heel effectief zijn.


30 / 63

Integrate

Een metadata schema is gedacht voor een bepaalde klasse van objecten (beperkte horizontale vrijheidsgraad): het is volstrekt onredelijk om te verwachten dat Dublin core een zinnig beschrijvingsmodel is van vakantie huisjes. Het is echter ook gebleken dat metadata schemata voor bibliotheken moesten worden aangepast onder invloed van digitalisering [Calhoun, 2006]. Omdat alle velden van te voren moeten worden bepaald kunnen in de loop der tijd aspecten relevant worden die niet op een duidelijke manier met een veld corresponderen. Veel schemata hebben daarom een vluchtroute met een veld waarin een vrije string kan worden opgenomen, en waar zich in de loop der jaren informatie kan ophopen die men verder nergens kwijt kan. Een metadata schema kan interoperabiliteit ook in de weg staan omdat informatie versnippert raakt. Het is soms belangrijk om werken van en over Shakespeare te kunnen scheiden, maar het is ook heel natuurlijk dat men in beiden is geïnteresseerd. Naarmate de metadata complexer is wordt dus ook het zoeken complexer. Meer algemeen kunnen complexe databases nauwelijks meer los worden gezien van automatische ondersteuning die verschillende deelgegevens combineert en verwerkt. Omgekeerd kunnen complexe applicaties (bijvoorbeeld leer omgevingen) gebaseerd zijn op de aanname dat rijke metadata voorhanden is. Inter-operabel zijn met deze applicatie betekend dan kosten en ongemak aangezien het toevoegen van metadata aan content een kostbaar en tijdrovend proces is. Een dergelijk situatie nodigt uit tot rijke metadata die aan alle standaarden voldoet en welgevormd is binnen de formele grenzen van het beschrijvingsmodel (bijvoorbeeld een DTD of een XML-schema) maar feitelijke onjuistheden bevat10 Lopend voorbeeld `Video Annotatie’. Zodra men over meer dan een paar dozijn video’s beschikt is een lijst van filenamen eindigend op ‘mpg’ geen zinvolle organisatie meer. Zelfs laagdrempelige sites als YouTube vragen daarom een titel, een maker/uploader en eventueel een kanaal. Afgaande op de YouTube site houdt Google daarnaast bij wat het commentaar is, en hoe vaak de video wordt bekeken. Simpele maar belangrijke bibliografische metadata wordt ook voor video afgedekt door Dublin Core. De canonieke Video metadata standaard is echter MPEG7 [ISO, 2004]. Dit is een complexe standaard die alles wat maar enigszins over video gezegd kan worden tracht te vangen: van data als maker, titel en rechten en formaat zoals in Dublin Core, tot de manier waarop de video kan worden opgedeeld in fragmenten (met elk hun eigen metadata) en gedetailleerde beeldanalyse karakteristieken. Ondanks dat MPEG7 al jaren als de “officiële” manier wordt gezien om video te annoteren, heeft het (nog) niet veel adoptie in de markt. Bovendien worden in de praktijk alleen kleine delen van MPEG7 gebruikt en geïmplementeerd. Bij beeld en geluid wordt het archief georganiseerd volgens het iMMix model waarin naast min of meer voor de hand liggende zaken als titel, maker, meewerkenden, beschrijving steekwoorden volgens de GTAA thesaurus ook zorgvuldig de relaties tussen verschillende content objecten en de ontstaansgeschiedenis wordt bijgehouden [De Jong, 2006].

10 Bijvoorbeeld, metadata die aangeeft dat een design bureau auteur is van een document omdat dit bureau de document templates met logo’s heeft ontworpen.


31 / 63

Integrate

4.7

Gegevenscatalogus Definitie. Een gegevenscatalogus met een metadata schema is een opsomming van alle instanties van de klasse samen met hun attribuut waarden [Wordnet, 2008]. Een gegevens catalogus is met andere woorden een abstractie van een gevulde database tabel met objecten. . Voorbeeld. Een voorbeeld van een gegevenscatalogus is een database met beschikbare MP3 files met metadata zoals maker, titel, rechten en prijs van de muziek. Ook een database met de inventaris lijst van onderdelen in een magazijn is een gegevenscatalogus. Gebruik. Gegevenscatalogi worden gebruikt om bij te houden welke objecten in de reële wereld beschikbaar zijn (in een zin die afhangt van de context) en wat de eigenschappen zijn van die beschikbare dingen. Gedeelde kennis. Zoeker en aanbieder worden geacht beiden het metadata schema en de betekenis daarvan te kennen. Semantiek. De semantiek van een gegevenscatalogus is dat één instantie van de catalogus (record in de database) correspondeert met één referent (aanwijsbaar object) in de realiteit. De velden van een record zijn een representatie van de eigenschappen van dat specifieke object. Hoe deze informatie moet worden geïnterpreteerd hangt dus af van het semantische model dat is gekozen om de eigenschappen van een object te beschrijven. Een gegevenscatalogus werkt met een gesloten wereld model, als een query geen resultaat oplevert zit er geen record in de database met die eigenschappen. Of dat betekent dat het een corresponderend object niet bestaat (gesloten wereld model) of dat het onbekend is of het bestaat (gesloten wereldbeeld) hangt af van het proces waarmee de correspondentie tussen database records en objecten in stand wordt gehouden is opgezet.

Huis:id;numkamer;oppm2;fotoURL;opm 1; 4; 150; http://www.opvakantie.com/persin.jpg ;”prachtig uitzicht op vrijstaande boom”

Huis:id;numkamer;oppm2;fotoURL;opm 2; 3; 110; http://www.Ferien.de/Wülfte3.jpg ;“Mit Bad”

Figuur 7: Een gegevens catalogus van huizen, georganiseerd volgens een database schema

Interoperabiliteit. Gegevenscatalogi bevorderen de interoperabiliteit omdat ze een het een zoeker mogelijk maakt te vragen naar objecten die alleen aan de aanbieder bekend zijn op basis van de gedeelde context van het schema. Het semantische interoperabiliteitsprobleem wordt daarmee gereduceerd tot het metadata schema.


32 / 63

Integrate

Een gegevenscatalogus heeft (per definitie) de kleinst mogelijke dekking (horizontale vrijheidsgraad) en de grootst mogelijke precisie (verticale vrijheidsgraad): voor elke instantie precies één referent. Het gevaar van een gegevenscatalogus is dat hij niet weergeeft wat feitelijk beschikbaar is. Het blijft immers een afbeelding van de werkelijkheid, die niet altijd hoeft te kloppen met de werkelijkheid. Lopend voorbeeld ‘Video Annotatie’. Elk video archief is een voorbeeld van een gegevens catalogus. Elk record in de database van het archief correspondeert met een video die beschikbaar is, en de typische attributen van een video als titel, auteur, jaar van uitgifte e.d. zijn velden van een metadata schema. 4.8

Ontologie Definitie. Een ontologie is een transitieve hiërarchische ordening van klassen, samen met relaties tussen klassen, attributen van klassen, eigenschappen van relaties, instanties van klassen, de relaties die tussen instanties gelden, en de attributen die instanties hebben [Wikipedia, 2008b; Metacyc, 2008; Magenta, 2008; GeneOntology, 2008]. Interpreteren we elke klasse als een begrip, relaties als relaties tussen begrippen en instanties als instanties van die begrippen dan zien we dat een ontologie een formeel begrippenkader is en de eigenschappen daarvan documenteert. Het is in feite zelfs redelijk om ontologie als een synoniem voor een willekeurig semantisch model te zien en de bovenstaande definitie als de speciale versie waarin we het model kunnen vast leggen in termen van klassen relaties en instanties, een “bolletjes en pijltjes diagram’’11. De graaf structuur van het model kan verhuld zijn omdat de deze lineair is opgeschreven in talen als RDF/RDFS/OWL of XML/XML-schema. (zie ook Figuur 9) Belangrijke relaties zijn de transitieve “subClassOf” relatie tussen klassen en de “type” relatie tussen instanties en klasses, die transitief is over de “subClassOf”relatie. We modeleren daarmee een strikte “is een” relatie zoals: “koeien zijn dieren”, “clara23 is een koe” dus “clara23 is een dier”. Formeel,geldt dat relaties als “x type A , A subClassOf B” en “B subClassOf C” impliceren dat “x type B, x type C” en “A subClassOf C”. Maar ontologieën laten het ook toe om nieuwe relaties te definiëren en daar van (simpele) eigenschappen te definiëren. Al deze eigenschappen worden geacht met wiskundige strengheid te gelden en software maakt hier gebruik.

11

Een formele definitie van bolletjes en pijltjes diagram is een gelabelde georiënteerde graaf waarin onderscheid wordt gemaakt tussen klasse en instantie knopen (“bolletjes”), met twee bijzondere typen georiënteerde kanten (pijlen) nl `type’ en `subClassOf’. Type pijlen verbinden instantie en klasse knopen, subClassOf pijlen verbinden klasse knopen. Verder zijn er axioma’s voor het voorkomen van pijlen zoals de transitiviteit van subClassOf, en de transitiviteit van type over subClassOf en van mag de ontology additionele axioma’s voor het voorkomen van pijlen bevatten. Zie [Brussee & Pokraev, 2007]


33 / 63

Integrate

x

type

type

A subClassOf B

Bestaat wegens logische structuur, wordt automatisch door software gegenereerd Figuur 8: Software gebruikt de logische structuur van een ontologie

Een variatie van het ontologie model hierboven is het (Enhanced) Entity relation diagram dat veel wordt gebruikt voor het opzetten van relationele databases. Hierin zijn geen instanties toegestaan en wordt iets anders omgegaan met relaties12. Ze hebben een vergelijkbaar doel als abstract conceptueel framework, maar zijn in de praktijk meer gericht op datastructuren en databases. Dit betekent in de praktijk dat het type logische axioma’s die gelden is beperkt tot relaties die relationele databases ondersteunen, i.h.b. de eenduidigheid van een identifier (primary key). Een taxonomie is in de abstracte formulering van dit document al een speciaal geval van een ontologie mits de hiërarchie relatie als transitieve subClassOf mag worden opgevat. Zie het SKOS taxonomie voorbeeld voor een geval waar dit niet zo is. Een metadata schema in de abstracte zin van dit document is al een gedegenereerde ontologie waarin maar een klasse en alleen attributen worden gedefinieerd. Eenmaal opgevat als ontologie ligt het echter voor de hand bij bijvoorbeeld een metadata schema voor document beschrijving het auteur veld te herdefiniëren als een relatie tussen een Document en een Persoon klasse. De naam van de auteur vinden we dan terug als een naam attribuut gedefinieerd op de Persoon klasse. Deze techniek is een variant van de klassieke database normalisatie en een preciezere formulering van wat er aan de hand is: een document wordt immers door een persoon en niet door zijn naam geschreven, en over een persoon kan veel meer gezegd worden dan alleen wat zijn of haar naam is. Een gegevenscatalogus is zelf ook een voorbeeld van een ontologie (in een gelijksoortig voorbeeld eerder kennisdatabase genoemd) waarin maar een klasse en instanties met attributen zijn opgenomen. Voorbeeld. Omdat ontologie een nogal algemeen begrip is geven we een aantal voorbeelden De meeste ontologieën worden tegenwoordig geformuleerd in RDFS of OWL (Resource Description Format Schema en Ontology Web Language). [W3C, 2004a; W3C, 2004b]. Dit is een simpele13 taal die vrij precies aansluit bij het organiseren in hiërarchische klassen, het definiëren van relaties tussen klassen met simpele eigenschappen en van instanties die al of niet voldoen aan extra relaties.

12

Om ze in het ontlogie model hier boven in te passen moeten ER-relaties worden opgevat als klassen van associaties. 13 Helaas worden RDF en OWL ontsiert door een bijzonder verwarrende XML serialisatie en een overdreven preferentie voor URL’s als identifier. Deze hebben die talen de onterechte reputatie van grote complexiteit en diepzinnigheid gegeven. In andere serialisaties zoals N3 en turtle zijn zowel de eenvoud als de beperktheid van deze talen beter zichtbaar.


34 / 63

Integrate

Een goed voorbeeld van een simpele OWL/RDFS ontologie is FOAF (Friend of a Friend) [FOAF, 2008]. Deze ontologie definieert klassen als Persoon, Document Afbeelding, Project, en relaties als heeftEmailAdress, isBevriendMet, isAfgebeeldOp, isMakerVan. In termen van deze ontologie kan men dan een profiel over zich zelf vastleggen. Door deze profielen van een groep naast elkaar te leggen krijgt men dan een beschrijving van een sociaal netwerk. De FOAF ontologie fungeert daarbij als een schema om zulk soort netwerken vast te leggen in een database. Een heel ander soort ontologie is de gêneontologie waarin genen, klassen van genen, hun relaties met eiwitten, biologische processen ontdekkers en patenthouders worden beschreven. Deze ontologie is zeer groot en bevat een grote hoeveelheid zeer gespecialiseerde kennis. Deze ontologie wordt in OWL overgezet, maar de “native” representatie is in een speciaal zogenaamd. OBO formaat en SQL tabellen. Voor een ontologie voor thesauri voeren we voor elke term een instantie van een klasse “Term” in met als attribuut zijn schrijfwijze voor elk begrip een instantie van de klasse “Begrip” en een relatie “heeft_term” die aan een begrip een term voor dat begrip toevoegt. Verder voeren we de relaties “breder”, “smaller” en “gerelateerd” tussen begrippen in die aangeven of de begrippen in conceptuele zin breder smaller of gerelateerd zijn. De SKOS (Simple Knowledge Organisation) ontologie [W3C, 2008] levert precies zulke relaties en klassen (de klasse Term blijkt overbodig aangezien men toe kan met alleen de schrijfwijze). Zodoende kan men een thesaurus met iso2788 formulering (BT, NT SY, …) beschrijven als instanties van klassen uit deze ontologie, dat wil zeggen als een database met SKOS als schema. Voor de concrete bibliografische taxonomieën die niet zich niet altijd strikt als een formele subClassOf hiërarchie laten opvatten blijkt het beter een taxonomie klasse op te vatten als een instantie van een klasse TaxonomieBegrip met een apart gedefinieerde hiërarchie relatie. SKOS voorziet ook in zulke taxonomieën. De taxonomie van het NTP (Nederlands Taxonomie Project) [NTP, 2008] is ook een ontologie in de zin hierboven. Het is in zoverre een atypisch voorbeeld dat het geformuleerd is in een XML dialect genaamd XBRL. XBRL ontologieën zijn bedoeld als (XML-)database schema voor financieel economische rapporten, die door financieel analisten, beurstoezichthouders of belastingdienst kunnen worden verzameld en automatisch worden verwerkt. Hoewel over een taxonomie wordt gesproken gaat het om een ontologie in de zin dat er begrippen (zoals verschillende soorten belastingen en posten op een winst en verlies rekening) worden gedefinieerd in hiërarchische klassen, met daarnaast andere relaties tussen die klassen. Verder worden formele eigenschapen van relaties vastgelegd zoals (bedrag_x is per definitie bedrag_y1 + bedrag_y2 – bedrag_z). XBRL is een basisraamwerk waarop verder gebouwd kan worden [Wikipedia 2008c]. Het steunt zwaar op XML technologieën, in het bijzonder XML-schema en X-link. Een XBRL taxonomie (ontologie) is een ingewikkeld mengsel van een XML datamodel en een formalisering van de semantiek van boekhoudkundige begrippen met behulp van relaties die worden gerepresenteerd met behulp van X-link. Het semantische deel is daarbij een variatie op het georiënteerde graaf model met een aantal semantische regels om boekhoudkundige identiteiten zoals “het totaal is de som van de bijdragen” uit te kunnen drukken. Door de manier waarop dit model verpakt is in XML-schema en Xlink heeft dit mogelijk op sommige plaatsen ontoereikende uitdrukkingskracht.


35 / 63

Integrate

Een XBRL taxonomie bestaat uit: • Een XML-schema file met “concepten” corresponderend met onze abstracte klassen. Elk concept is een element in een XML-schema en in het bijzonder bevat in een namespace. Een voorbeeld van een dergelijk concept is . Dit is meteen een voorbeeld van de poging om een (voor financiële specialisten) duidelijke naamgeving te gebruiken. Bijna alle concepten zijn rapporteerbaar, dat wil zeggen, het zijn concreet gedefinieerde XML-schema typen. Het concept wordt daarbij min of meer met dit XML-datamodel geïdentificeerd. Dit betekent dat zo een element kan worden geinstantieerd in een financieel rapport, een XBRL instance file. Vele van deze elementen corresponderen direct met bedragen in een bepaald jaar voor een bepaald bedrijf of deel organisatie. Bijvoorbeeld, in het geval van het bovenstaande voorbeeld concept is dit bedrag de waarde van het verlies over een bepaalde periode van een bepaalde organisatie, met een aan te geven aantal significante cijfers net zoals dat in een traditioneel jaarverslag is opgenomen. • Een link-base: een XML-file waar met behulp van X-link relaties worden gelegd o Tussen concept elementen onderling, bijvoorbeeld dat het ene concept hiërarchisch ondergeordend is aan het andere14 o Voor het “opheffen” van relaties om ze aan te passen, bijvoorbeeld om met iets verschillende juridische definities van verschillende begrippen in verschillende landen rekening te houden. o Voor een rekenschema tussen elementen, bijvoorbeeld dat twee waarden samen opgeteld een derde oplevert o Voor de presentatie structuur van concepten, o Voor referenties naar authoritieve (bijv. juridische) bronnen, o Voor Labels die aan elementen moeten worden gegeven mogelijk in verschillende talen, o Voor voetnoten als toelichting voor een formeel feit. Dit is in het ontologie model vergelijkbaar met het definiëren van relaties tussen klassen, het aangeven welke relaties tussen instanties bestaan en het aangeven van eigenschappen van klassen. XBRL is uitbreidbaar. Dit betekent dat verschillende overheden of bedrijven hun eigen begrippen en relaties invoeren. Het is van belang voor het afbeelden van bestaande administratieve praktijken en ERP posten op een XBRL rapportage. Er zijn hier kennelijk hoge verwachtingen over, bijvoorbeeld dat controleurs hun eigen vocabulaire toevoegen en aan de locale situatie aanpassen. In elk geval wordt bestaande software zoals Microsoft Dynamics [Semansys, 2008b] aangepast om met XBRL te kunnen werken. Om financiële mensen niet te confronteren met een overdosis XML-vishaken (bar), zijn er speciale XBRL taxonomie editors en viewers verkrijgbaar. [Semansys, 2008b]. Er zijn een groot aantal basis taxonomieën beschikbaar waarop gespecialiseerde begrippen kunnen voortborduren. Deze basis taxonomieën zijn te beschouwen als bibliotheken die de werkelijke formalisaties van financiële begrippen vormen terwijl de XBRL slechts de “taal” is waarin deze formalisaties zijn uitgedrukt. Feitelijke rapportage vindt plaats in een XBRL instantiefile met een XBRL taxonomie als schema en als template voor presentatie van de informatie op hoofdlijnen. De instantiefile bevat de feitelijke financiële informatie over een bedrijf zoals zijn jaarrekening en voetnoten met uitleg, titels e.d. De instantie files kunnen door een 14

Dit is te vergelijken met broader term (BT) en minder precies dan een subClassOf relatie.


36 / 63

Integrate

boekhoudprogramma worden gegenereerd om dan aan de Belastingdienst of Kamer van Koophandel te worden verder gegeven. Het bevat de feitelijke waarden, voornamelijk bedragen. Bijvoorbeeld, in de jaarrekening van een concreet bedrijf wordt een veld als ingevuld met een specifiek bedrag in een specifieke munteenheid voor een specifiek jaar met een specifiek aantal significante cijfers. Als laatste voorbeeld is in appendix B een stuk van de EDEX NTA (EDEX NTA-2032) te vinden die gebruikt wordt voor het uitwisselen van leerling-gegevens [Wikipedia, 2008e]. Deze NTA is in de bijlage opgeschreven als OWL ontologie in de N3 serialisatie (in wezen RDF in ASCII in plaats van XML). Gebruik. Ontologieën worden gebruikt om een formeel begrippenkader te formuleren. Daarbij wordt uitgegaan van een open wereld aanname: van de klassen en instanties die in de ontologie worden genoemd mag worden verondersteld dat zij bestaan, maar uit de afwezigheid van een instantie mag niet worden geconcludeerd dat een dergelijke instantie niet bestaat. De meer succesvolle ontologieën modelleren vrij concrete begrippen: documenten, mensen, afbeeldingen, onderwerp classificatoren (dat wil zeggen onderwerpcodes als in LCC), genen of processen. Ondanks dat een ontologie allereerst een conceptueel beeld van het relevante deel van de werkelijkheid geeft, zijn veel ontologieën op te vatten als een soort database schema. Een ontologie wordt dan gebruikt als een taal om gegevens mee uit te drukken. Om die gegevens ook in grotere hoeveelheden te kunnen gebruiken is wel infrastructuur nodig, zoals een triple database als Sesame [Sesame, 2008]. De gebruikelijke opsplitsing is daarbij dat klassen voor het structurele schema worden gebruikt en instanties voor gegevens. Het structurele deel kan daarbij publiek worden gemaakt als ``de ontologie’’ en de database met instanties en klassen als ``de kennisdatabase’’. Het is niet altijd duidelijk waar het structurele schema ophoud en de in die structuur gedefinieerde gegevens begint omdat ontologieën beide kunnen bevatten, bijvoorbeeld een ontologie over landen en steden zou naast de begrippen Land en Stad ook het bestaan van de stad Parijs en de ligging van Parijs in Frankrijk kunnen bevatten. Ook ontleent een in SKOS geformuleerde thesaurus zijn waarde als semantisch model aan de database met termen in vergelijking waarmee de SKOS ontologie heel beperkt is. Slaan we zo een thesaurus op in een triple database dan vormen SKOS en de thesaurus een onlosmakelijk geheel waarin op de zelfde manier naar structuur, klassen en relaties, als naar inhoud, instanties, kan worden gezocht. Gedeelde kennis. De hoeveelheid gedeelde kennis die nodig is om een ontologie te gebruiken hangt af van de ontologie. Aangenomen dat beide partijen toegang hebben tot dezelfde ontologie. Moeten beide partijen begrijpen hoe de realiteit wordt gemodelleerd. Daar staat echter tegenover dat een ontologie de mogelijkheid geeft om expliciet(er) te maken wat de onderliggende aannames zijn die in de communicatie worden gebruikt en een rijk(er) model geven om die communicatie in uit te drukken. Gegeven deze gemeenschappelijke context kan een zoekende partij een hem onbekende, in deze ontologie geformuleerde database van een aanbiedende partij bevragen. Semantiek. De semantiek van een ontologie hangt sterk af van de ontologie maar typisch is het model dat collecties van onderscheidbare, mogelijk bestaande objecten worden gemodelleerd op klassen, en individueel voorkomende objecten op individuen van die klassen. Eigenschappen van individuen worden gemodelleerd met relaties

37 / 63


tussen klassen of met attributen van een klasse met waarde in een string, getal, datum of een ander concreet datatype. De eigenschappen van individuen worden vastgelegd als triples (individu1, relatie, individu2) of (individu, attribuut, waarde). In OWL en RDFS ontologieën wordt daarbij gewerkt met een open wereld model.

ex:house1 ∈

bld:hasInView ex:tree3

bld:numRoom

bld:House ⊆ bld:Building

4

∈ nat:Animal

nat:Tree ⊆

⊆ nat:Plant

⊆

nat:Eukaryote

math:Tree

rdfs:label “Dier”@nl

Figuur 9: Een aantal ontologieën en daarin uitgedrukt gegevens over een bepaald huis en een bepaalde boom. De symbolen ∈ en ⊆ betekenen respectievelijk heeft type (irdf:type) en is een deelklasse van (irdfs:subClassOf).

Interoperabiliteit. Ontologieën zijn geen oplossing voor alle semantische interoperabiliteitsproblemen. Door meer structuur met in potentie meer formele consequenties als expliciete context te delen zijn wel minder aannames nodig. Ook wordt meer precisie en explicietheid in de communicatie gegeven (kleinere verticale vrijheidsgraad). Deze extra precisie is daarbij vaak belangrijker naarmate de context waarin de communicatie plaats vindt minder helder is, en een groot deel van de extra precisie komt van het feit dat de webachtige structuur van een ontologische beschrijving er toe uitnodigt om een groter deel van de context mee te beschrijven. De dekking (horizontale vrijheidsgraad) van een ontologie hangt sterk van de ontologie af. Zinvolle zeer algemene ontologieën zijn moeilijk te maken. Een belangrijk doel van ontologie standaardisatie talen als OWL en RDFS is dan ook om waar praktisch en nodig verschillende ontologieën naast elkaar te kunnen gebruiken, en zo voor grotere dekking te zorgen. Ook is het mogelijk om binnen een nieuwe context nieuwe klassen en relaties in te voeren en aan te geven hoe deze zich verhouden in termen van bestaande ontologieën, daarmee in elk geval gedeeltelijk weergevend wat de aannames van het nieuwe deel van het model zijn. In een RDF gebaseerd systeem zijn klassen en relaties, net zo goed data waarnaar gezocht kan worden. Dit geeft in potentie de mogelijkheid om een bootstrap procedure uit te voeren uitgaande van heel beperkte aannames en een groot gebied af te dekken. Het gevaar van een ontologie is zoals met alle modellen dat de modellering niet correct is gedaan. Het gevaar daarvoor is met ontologieën zowel groter dan kleiner dan bij de


38 / 63

Integrate

andere modellen. Groter omdat veel complexere modellen kunnen worden gemaakt die moeilijker zijn te overzien, maar ook kleiner omdat er meer natuurlijke mogelijkheden zijn om iets te formuleren. In de publiciteit rond het semantisch web is er veel aandacht voor complexe ontologieën om subtiele wereldkennis mee vast te leggen en ingewikkelde consequenties te kunnen beredeneren Succesvolle en nuttige ontologieën als FOAF zijn echter doelbewust simpel en beperkt in scope gehouden en gebruiken alleen uiterst basale logische beperkingen. Op het praktisch niveau van interoperabiliteit met de infrastructuur leveren ontologieën (op het moment) problemen op. De rigidere logische structuur die een standaard als OWL of XBRL veronderstelt, moet door een software infrastructuur worden geïmplementeerd en dat gaat uiteraard niet vanzelf. Er bestaan triple databases [Sesame, 2008] en bibliotheken waarmee omgegaan kan worden met RDF [Jena, 2008] of XBRL [Batavia, 2008] maar de infrastructuur voor XML en relationele databases is veel beter ontwikkeld en er zijn veel meer mensen die er ervaring mee hebben. Lopend voorbeeld `Video Annotatie’. Annotatie van content is de oorspronkelijke reden voor de ontwikkeling van RDF De “resources” in Resource Description Format waren gedacht als webpagina’s of andere content waaraan een URI kan worden gegeven. Met RDF files kan de metadata beschrijving van de content dan worden losgekoppeld van de content zelf, waarbij oorspronkelijk vooral gedacht werd aan eenvoudige bibliografische metadata zoals die in de Dublin Core metadata set voorkomen. Met de invoering van schemata konden ook complexere relaties tussen content worden beschreven en werd het bovendien makkelijk om ook te doen of “resources” als mensen een URL hebben. Complexere ontologieën zijn voortgekomen uit de behoefte om het soort structuur dat al aanwezig is in thesauri en taxonomieën te kunnen gebruiken. Door deze thesauri ook als ontologie te verpakken word het mogelijk om van meer verschillende bronnen structuur te gebruiken en bovendien metadata schema en thesaurus en externe structuur met elkaar te integreren in een geïntegreerde geünificeerde infrastructuur. Zoals te verwachten lopen mensen daarbij op tegen het feit dat thesauri en taxonomieën volgens minder strenge formele principes zijn opgebouwd dan ontologische klassen, zodat men er toe over gegaan is deze niet direct te coderen maar in te pakken in een data model zoals dat door SKOS ontologieën wordt gedefinieerd. In de researchgemeenschap is hier veel werk voor verricht (zie bijvoorbeeld het CHOICE project [Choice, 2008a]). Van een andere kant bekeken voorziet ook MPEG7 in zogenaamde semantic descriptors. Er is werk gedaan om MPEG7 als een RDFS-ontologie te kunnen gebruiken [Hunter, 2008]. Vermoedelijk omdat MPEG7 niet zoveel wordt gebruikt, wordt ook dit idee niet heel veel gebruikt. 4.9

Object gebeurtenismodel Definitie. Een object gebeurtenismodel is een model waar objecten en gebeurtenissen in worden vastgelegd. In de objecten wordt vastgelegd wat de attributen zijn die van belang zijn voor het betreffende object. Bij de gebeurtenissen wordt aangegeven wanneer ze op kunnen treden, wat de verschijnselen in het domein zijn en hoe de objecten betrokken zijn bij de gebeurtenissen [Snoeck et.al., 1999].


39 / 63

Integrate

Een object gebeurtenismodel kan worden vastgelegd met een Entity Relationship diagram, in combinatie met een Activity diagram, een State Transition diagram en een object gebeurtenis tabel [Snoeck et.al., 1999; Rumbaugh et.al., 2005]. Voorbeeld. Een voorbeeld van een object model is het vastleggen van de objecten die van belang zijn in het uitwisselen van gegevens bij het uitlenen van een uitzendkracht. Objecten die dan onderscheiden worden zijn een Aanvraag, Aanbod, Uitzendkracht en een Plaatsing. Naast de objecten worden ook de relevante gebeurtenissen in het uitleenproces vastgelegd, waaronder het doen van een aanvraag, het doen van een aanbod, het uitwisselen van plaatsingsgegevens. Gebruik. Object gebeurtenis modellen worden gebruikt om de objecten in de reële wereld vast te leggen in een systeem, om de onderlinge relaties die in de reële wereld aanwezig zijn vast te leggen. Tevens worden in de modellen ook gebeurtenissen vastgelegd, waardoor het mogelijk is om dynamische verschijnselen vast te leggen in het model. Gedeelde kennis. De hoeveelheid gedeelde kennis die nodig is om een object gebeurtenismodel te gebruiken hangt sterk af van de mate waarin de processen tussen de partijen op een eenduidige manier vastgelegd kunnen worden. Het voordeel van deze modellen is wel dat er expliciet vastgelegd kan worden welke objecten en gebeurtenissen van belang zijn in de communicatie, waardoor het duidelijker kan worden wat er precies gebeurd tijdens de uitwisseling van gegevens. Semantiek. De semantiek van een object gebeurtenismodel is dat elk object in het model correspondeert met een aanwijsbaar object in de realiteit. De gebeurtenissen leggen de dynamische verschijnselen binnen het domein weer. De objecten in het model zijn betrokken bij de gebeurtenissen die optreden in het domein.

Figuur 10: Voorbeeld van een object model waarin de objecten die van belang zijn bij het doen van een aanvraag en een aanbod, vacature (position), aanbod (offer) en uitzendkracht (employee) opgenomen zijn.


40 / 63

Integrate

Figuur 11: Voorbeeld van een state transition diagram waarin is vastgelegd welke gebeurtenissen er optreden bij het aanmaken (create), updaten (Update), afwijzen (Reject), afsluiten (Close), heropenen (Reopen) en archiveren (Archive) van een vacature.

Interoperabiliteit. Object gebeurtenis modellen helpen bij het creëren van interoperabiliteit door het vastleggen van de objecten, maar zeker ook de gebeurtenissen die van belang zijn bij interoperabiliteit. In veel gevallen zit er namelijk een bepaalde volgordelijkheid in het uitwisselen van gegevens tussen partijen. Deze volgordelijkheid is goed te vatten in een object gebeurtenis model waardoor het duidelijk wordt wat er precies gebeurd tijdens het proces van uitwisseling. In de objecten kan verder worden vastgelegd welke informatie er uitgewisseld wordt waardoor het ook helder is om welke informatie het gaat. Lopend voorbeeld `Video Annotatie’. Van iedere video zou een object gebeurtenis model gemaakt kunnen worden waarbij bijvoorbeeld de acteurs opgenomen zouden kunnen worden als objecten, waarbij de gebeurtenissen die de acteurs meemaken opgenomen zouden kunnen worden als gebeurtenissen in het model. Hierdoor zou er een model ontstaan van de video, waardoor er later makkelijker over gecommuniceerd kan worden.


41 / 63

Integrate

5

Stappenplan voor ontwikkeling semantisch model In dit hoofdstuk wordt een stappenplan gepresenteerd voor het ontwikkelen van een semantisch model. .

5.1

Inleiding Het ontwikkelen van een semantisch model is in de meeste opzichten vergelijkbaar met het ontwikkelen van een willekeurig ander soort model, zoals het beschrijven van een bedrijfsproces, bedrijfsarchitectuur, netwerktopologie, etc. In alle gevallen is er immers sprake van een beschrijving van de werkelijkheid, of van een gewenste situatie. Daarvoor zijn een aantal algemene modelleringsvaardigheden noodzakelijk. Semantische modellen hebben, in tegenstelling tot de genoemde modellen een ander, meer specifiek doel: het vastleggen en overdragen van kennis over een bepaald domein om uiteindelijk te komen tot interoperabiliteit. In dit hoofdstuk zullen een aantal aspecten worden genoemd die in dit verband relevant zijn voor het goed laten verlopen van het ontwikkelproces. De activiteiten die in dit hoofdstuk worden genoemd kunnen worden gebruikt als stappenplan in het ontwikkelen van een semantisch model.

5.2

Beschikbare methoden Er zijn verschillende methoden en technieken beschikbaar die gebruikt zouden kunnen worden voor het ontwikkelen van een semantisch model: • Algemene ontwikkeltechnieken (vaak gericht op software), zoals Rational Unified Process en Agile. • Werkwijzen gericht op het modelleren van een semantisch model in een specifieke softwaretool. Deze methoden gaan vooral in op de werking van en omgang met deze softwaretool. Deze werkwijzen worden doorgaans beschreven in de ondersteunende documentatie van een softwaretool (bijvoorbeeld Protégé) en gaan hoofdzakelijk in op de formalisatie van een model in de betreffende tool. • Werkwijzen die strikt gekoppeld zijn aan een bepaald type semantisch model en/of een toepassing, bijvoorbeeld: • de ontwikkeling van een taxonomie ten behoeve van een bibliotheek met wetenschappelijke literatuur. • het opbouwen van een taxonomie van artikelen, zodat een indeling voor een intranet portal gemaakt kan worden. • het opzetten van een ontologie met juridische kennis Voor een overzicht van verschillende methoden wordt verwezen naar ondermeer [Jones et.al., 1998; Gomez-Perez, 1997].

5.3

Stappenplan Ondanks de verschillen tussen de diverse methoden is er wel een rode draad te ontdekken. Deze rode draad bestaat uit een aantal stappen dat in de meeste modellen doorlopen wordt. Per stap kunnen een aantal veelvoorkomende activiteiten benoemd worden. Voor het stappenplan is [Uschold, 1996] als basis genomen.


42 / 63

Integrate

1. Vastleggen van het doel; afbakening van het domein In deze stap wordt het project geïnitieerd en worden doel en scope (de afbakening van het domein) vastgelegd. Activiteiten in deze stap zijn: • Vaststellen van het doel waarvoor het semantische model wordt opgesteld. Doorgaans is dit gerelateerd aan een specifiek interoperabiliteitsprobleem. • Opstellen van een lijst met relevante scenario’s waarin het model toegepast moet gaan worden. • Bepalen welke relatie er is met andere projecten in verleden, heden en toekomst. • Vaststellen wat het domein is wat door het semantisch model beschreven dient te worden. Ook duidelijk aangeven wat niet tot het domein behoort. • Opstellen van criteria waarmee kan worden bepaald wanneer het semantische model compleet is. • Bepalen wie de stakeholders zijn bij het semantisch model. Per groep stakeholders moet worden bepaald worden wat de betrokkenheid is in het project (informeren over het project, participeren in een projectgroep of niet, etc.). • Inventarisatie van bestaande overzichten, lijsten, gegevens en relaties. Wellicht kunnen deze gebruikt worden als basis/input voor het op te stellen semantisch model. Per beschikbaar overzicht/model moet de bruikbaarheid worden vastgesteld. 2. Conceptualisatie In deze stap wordt de basis gelegd voor het semantisch model. De benodigde gegevens (zaken die mogelijk relevant zijn om opgenomen te worden in het semantisch model) worden verzameld en gestructureerd. Activiteiten in deze stap zijn: • Het verzamelen van gegevens. Dit kan handmatig (bijvoorbeeld door interviews met stakeholders te houden), maar kan in sommige gevallen ook geautomatiseerd (denk aan het verzamelen van termen uit een gegevensset). • Het omzetten van ruwe gegevens naar objecten/termen die een plek moeten krijgen in het semantisch model. Doorgaans is dit een filtering van de verzamelde gegevens. • Het kiezen van een structuur voor het model. Deze structuur moet aansluiten bij de eerder benoemde doelen en toepassing van het model. Zorgvuldigheid is geboden bij deze keuze, aangezien dit van grote impact kan zijn op de uiteindelijke toepasbaarheid van het model. Dit zou getoetst kunnen worden door de gekozen structuur naast de eerder geformuleerde toepassingsscenario’s te houden en de vraag te stellen of het model met die structuur in alle gevallen goed gebruikt kan worden. Daarnaast kan het ook zinvol zijn om het model zo in te richten dat het ook uitbreidbaar is voor andere toekomstige denkbare scenario’s. Bijvoorbeeld: een semantisch model dat nu gebruikt wordt voor het afspreken van een berichtenstandaard, zou in de toekomst wellicht ook ingezet kunnen worden voor het inrichten van een andere toepassing in hetzelfde domein. • Continu: toetsen van tussenresultaten aan de scope en het doel.


43 / 63

Integrate

• •

Iteratief kunnen nieuwe elementen/onderdelen worden toegevoegd, op basis van gesprekken met stakeholders of het ordenen van verzamelde gegevens. Gedurende het proces vindt afstemming plaats met stakeholders, voor zover deze al niet betrokken zijn. Deze afstemming is daarmee afhankelijk van de in stap 1 gekozen aanpak m.b.t. stakeholders.

3. Formalisatie In deze stap wordt het ontwikkelde semantische model formeel vastgelegd. De ontwikkelde concepten worden, doorgaans met ondersteuning van een bijpassende tool, vastgelegd. Deze stap verloopt grotendeels in samenhang (parallel) met stap 2. Sommige tools ondersteunen een parallelle conceptualisatie en formalisatie, andere tools echter niet (bijvoorbeeld bij toepassing van brainstormingsoftware – zoals Mindmanager – voor de conceptualisatiefase). 4. Evaluatie en overgang naar implementatie en beheer In deze stap wordt de ontwikkeling afgesloten en wordt het ontwikkelde semantische model overgedragen naar de implementatie- en beheerorganisatie. Activiteiten in deze stap zijn: • Het resultaat toetsen aan de hand van de in stap 1 bepaalde criteria m.b.t. compleetheid. Daarnaast vindt een laatste controle plaats op het doel en de scope. Het doorlopen en afvinken van de mogelijke gebruiksscenario’s is hiertoe een goed instrument. • Het ontwikkelde semantisch model wordt overgedragen aan de beheerorganisatie. Ook is het mogelijk dat het projectteam wordt omgevormd tot een beheerorganisatie. De beheerprocessen worden ingericht. • Overdracht van het resultaat aan andere projecten, waarbinnen het ontwikkelde model gebruikt wordt. Hierbij gaat het om de inzet van het semantisch model, bijvoorbeeld ten behoeve van de realisatie van een berichtenstandaard. Richting deze projectteams dient kennisoverdracht over het gevolgde proces en de gemaakte keuzes plaats te vinden. Eveneens dienen deze projectteams gewezen te worden op het beheerproces. • Het evalueren ontwikkelproces: wat ging er goed, wat ging er minder goed. De resultaten worden vastgelegd en worden gebruikt bij volgende ontwikkelprocessen en/of bij wijzigingsprocessen als onderdeel van het beheer. Parallel aan dit ontwikkelproces lopen een aantal ondersteunende processen, zoals: • Planning en voortgangsbewaking • Kwaliteitscontrole • Documentatie- en configuratiebeheer Hierbij kan aangehaakt worden bij de concepten uit de beheerprocessen, zoals beschreven in hoofdstuk 6. In bijlage C wordt het ontwikkelproces zoals dat gebruikt wordt binnen de SETU (Stichting Elektronische Transacties Uitzendbranche) getoetst aan het stappenplan dat in dit hoofdstuk is gepresenteerd.


44 / 63


45 / 63

Integrate

6

Checklist voor beheer van semantische modellen In dit hoofdstuk wordt een checklist gepresenteerd aan de hand waarvan een organisatie het beheer in kan gaan richten, of kan controleren of de beheerorganisatie die al ingericht is volledig is.

6.1

Inleiding De literatuur biedt nog geen standaard methoden voor het beheren van semantische modellen. Hierdoor komt het beheer van semantische modellen ad hoc tot stand. Het gebrek aan standaard werkwijze komt de kwaliteit van de semantische modellen niet ten goede. Om tot een standaard werkwijze te komen voor het beheer van semantische modellen maken wij gebruik van literatuur over beheermethoden die zijn ontwikkeld voor ictvoorzieningen, waaronder bijvoorbeeld applicaties en netwerken en maken we gebruik van cases die voorkomen aangeleverd zijn door de partners binnen het Integrate project. We onderkennen hierbij dat door de beperkte tijd die beschikbaar was voor het ontwikkelen van dit instrument het niet mogelijk is om een volledige werkwijze op te leveren, om deze reden wordt er alleen een checklist gepresenteerd die gebruikt kan worden als basisopzet voor het inrichten van een organisatie en die gebruik kan worden voor het controleren van een al bestaande beheerorganisatie. In paragraaf 6.2 worden drie beheergebieden beschreven die in de praktijk gebruikt worden bij het beheren van ict-voorzieningen. In paragraaf 6.4 worden de onderscheiden beheergebieden gekoppeld aan het beheren van semantische modellen, hierbij wordt aangegeven welke zaken binnen de beheergebieden van belang zijn. Paragraaf 6.5 presenteert de checklist.

6.2

Beheergebieden In de literatuur over het ontwikkelen en beheren van ict-voorzieningen wordt een driedeling gemaakt in de volgende beheergebieden [Looijen, 2000; Thiadens, 2002; Sieders & Pols, 2002; Meijer & Meijers, 2002]: - Functioneel beheer; verantwoordelijk voor instandhouding van de functionaliteit van applicaties en voor de dagelijkse ondersteuning van gebruikers aan de opdrachtgeverzijde. Applicatie beheer; verantwoordelijk voor instandhouding van de applicatieprogrammatuur en de gegevensbanken. - Technisch beheer15: verantwoordelijk voor de instandhouding van de operationele werking van applicaties. Een korte omschrijving van een aantal bestaande modellen die invulling bieden aan de drie beheergebieden op het gebied van het beheer van ict-voorzieningen is te vinden in bijlage A.

15

In [Thiadens, 2002] wordt dit gebied ‘Exploitatie’ genoemd.


46 / 63

Integrate

6.2.1

Functioneel beheer Het functioneel beheer is de sluis van de eigenaren en eindgebruikers naar de applicatiebeheer organisatie. Het functioneel beheer gaat alleen over de functionaliteit van de applicatie en de wijze waarop men deze functionaliteit in productie houdt. Functioneel beheer stuurt het applicatie beheer en het technische beheer aan. Hierbij wordt deels planmatig aangestuurd, deels ad hoc aan de hand van evaluaties. Op strategisch niveau functioneert het functioneel beheer als een denktank voor de eigenaar van de applicatie. Er worden voorstellen gedaan over de gewenste functionaliteit van de applicatie of applicatieportfolio op middellange en lange termijn. Hiernaast wordt er ook meegedacht over de organisatie die nodig is om gemaakte voorstellen te realiseren. Op tactisch niveau stuurt het functioneel beheer de operationele beheertaken aan. Door het functioneel beheer worden twee taken zelf uitgevoerd. Dit zijn: • De dagelijkse werkzaamheden van de helpdesk, voor contact met gebruikers bij vragen en problemen. • De vernieuwende werkzaamheden aan applicaties, zoals het geven van advies over de inhoud van nieuwe versies of releases.

6.2.2

Applicatie beheer Applicatie beheer denkt op strategisch niveau na over de toekomst van de organisatie van het beheer en van de huidige applicaties. De visie op de organisatie van het beheer wordt beïnvloed door de vragen van de markt, de gewenste relatie met de klant, mogelijkheden van de techniek en de kennis die de organisatie wil opbouwen en behouden. Hiernaast wordt er ook een visie ontwikkeld over de toekomst van de al in beheer zijnde applicaties. Deze visie wordt in veel gevallen ook het beleid voor lifecycle management van de applicaties genoemd. Naast de visie over de toekomst van de al in beheer zijnde applicaties wordt ook een beleid voor de technologiestrategie voor de hele applicatieportfolio, ook wel ict-portfoliomanagement genoemd, ontwikkeld. Op het operationele niveau worden, zeker bij grote organisaties, twee duidelijk gescheiden taken voor applicatiebeheer onderscheiden. Dit zijn: • Dagelijks beheer van een applicatie, zorg voor afdoen van incidenten, zorg voor continuïteit, zorg voor beschikbaarheid, capaciteit en configuratie. • Vernieuwend beheer van een applicatie, zorgen voor nieuwe versies en releases.

6.2.3

Technisch beheer Het technisch beheer is verantwoordelijke voor het in stand houden van de operationele kant van de applicaties. Op tactisch niveau zorgt het technisch beheer voor serviceovereenkomsten tussen eigenaren en beheerders. Door informatie vanuit verschillende operationele processen te verzamelen wordt door het technisch beheer periodiek gerapporteerd over de geleverde service. Vanuit tactisch niveau stuurt het technisch beheer het veranderen van de exploitatieomgeving aan. Op het operationele niveau wordt in het technische beheer de helpdesk door de klant aangestuurd. De helpdesk kan zelf de melding verwerken en een dergelijke melding kan ook leiden tot directe verdere actie. Op het operationele niveau kunnen daarnaast ook meer planmatige taken wordt uitgevoerd. Onder deze taken vallen bijvoorbeeld: • Wijzigingsbeheer taken. • Het in productie houden van de ict-omgeving. • Invoering van nieuwe versies of releases van infrastructuren of applicaties.


47 / 63

Integrate

6.3

Beheergebieden gekoppeld aan semantische modellen In de voorgaande paragraaf zijn een drietal beheergebieden onderscheiden (functioneel, applicatie, en technisch) die worden toegepast bij het beheren van ict-voorzieningen. Omdat deze beheergebieden niet ontwikkeld zijn met het beheren van semantische modellen in het achterhoofd zijn de processen die op basis van deze beheergebieden zijn ontwikkeld ook niet direct toepasbaar. Hiernaast spelen bij het beheren van semantische modellen binnen de beheergebieden een aantal andere zaken een rol en zijn sommige zaken minder van belang, of niet toepasbaar. In deze paragraaf zal per beheergebied worden aangegeven hoe de zaken die besproken worden bij de beschrijving van deze gebieden bij het beheer van ict-voorzieningen toepasbaar zijn bij het beheren van semantische modellen.

6.3.1

Functioneel beheer Bij het ontwikkelen en beheren van semantische modellen is het functioneel beheer van belang. Het functioneel beheer moet ook hier dienen als de sluis tussen de gebruikers van de semantische modellen en de applicatiebeheerorganisatie. Binnen het functioneel beheer van semantische modellen moet er gekeken worden naar de mogelijkheden binnen de modellen en eventueel benodigde wijzigingen. Ook het instellen van een helpdesk waar gebruikers naartoe kunnen stappen met vragen en opmerkingen is van belang bij het gebruik van semantische modellen. Ook deze modellen zullen namelijk in de loop van de jaren doorontwikkeld worden, en zonder een goede ondersteuning zal het voor veel gebruikers lastig zijn om optimaal gebruik te maken van de semantische modellen. Omdat de semantische modellen hoofdzakelijk gebruikt zullen worden bij het oplossen van interoperabiliteitsproblemen zullen beide partijen dezelfde versie van het semantische model moeten gebruiken en implementeren om te voorkomen dat de informatie verkeerd geïnterpreteerd wordt. Het schatten van deze zaken en het doen van voorstellen voor het implementeren van nieuwe functionaliteit is dus ook een belangrijk aspect bij het ontwikkelen en beheren van semantische modellen.

6.3.2

Model beheer Het inrichten van een deel van de organisatie voor model beheer, is van belang bij het beheren van semantische modellen. Het model beheer gedeelte staat op gelijke voet met het applicatie beheer gedeelte binnen het beheer van ict-voorzieningen. Eén van de taken binnen het model beheer is het onderhouden van relaties met gebruikers en ervoor zorgen dat de modellen aan blijven sluiten bij wat de gebruikers verwachten. Hiervoor moet er dus op regelmatige basis contact met de gebruikers zijn, en moet er gekeken worden naar de middellange- en lange termijn ontwikkeling van de semantische modellen. Tevens moet het applicatie beheer er, onder aansturing van het functioneel beheer, voor zorgen dat plannen met betrekking tot nieuwe versies van de modellen uitgevoerd worden. Ook het beheren en ontwikkelen van een eenduidig en duidelijk idee over de life-cycle van de modellen behoort tot de taken binnen het applicatie beheer. Tevens moet het applicatiebeheer er bij het beheren van semantische modellen, net als bij ict-voorzieningen, ook zorg voor dragen dat fouten in bestaande modellen opgelost worden.

6.3.3

Technisch beheer Indien een organisatie ook verantwoordelijk is voor het beschikbaar stellen van de modellen, is het ook van belang om het technisch beheer goed in te richten. Het technisch beheer moet ik dat geval zorg dragen dat de modellen beschikbaar gesteld


48 / 63

Integrate

worden, hierbij kan bijvoorbeeld gedacht worden aan het beheren van webservers en websites waarop de modellen beschikbaar zijn voor de gebruikers. 6.4

Checklist Onderstaande checklist kan gebruikt worden om te controleren of een organisatie het beheer van de semantische modellen op hoofdlijnen heeft ingericht. De lijst is gebaseerd op de koppeling van de beheergebieden uit de wereld van de ictvoorzieningen naar het beheer van semantische modellen zoals gepresenteerd in paragraaf 6.4. De gepresenteerde lijst is geen volledige lijst, het zou dus goed kunnen zijn dat een organisatie meer en of minder zaken heeft ingericht voor het beheer. Een uitwerking van de checklist voor het beheer van semantische modellen binnen de SETU is te vinden in bijlage C.  Functioneel beheer  Inrichten helpdesk Beschrijving: ……………………………………………………………… …………………………………………………………………………….  Verzamelen aanvragen nieuwe functionaliteit Beschrijving: ……………………………………………………………… …………………………………………………………………………….  Modelbeheer  Uitvoeren plannen voor nieuwe versies modellen Beschrijving: ……………………………………………………………… …………………………………………………………………………….  Beheren van de life-cycle van de modellen Beschrijving: ……………………………………………………………… ……………………………………………………………………………..  Oplossen fouten in modellen Beschrijving: ……………………………………………………………… ……………………………………………………………………………..  Technisch beheer  Beschikbaar stellen modellen Beschrijving: ……………………………………………………………… ……………………………………………………………………………..


49 / 63

Integrate

7

Tooling Dit hoofdstuk beschrijft tools die gebruikt kunnen worden om de semantische modellen in te ontwikkelen, maar ook tools die gebruikt kunnen worden om de verschillende stappen binnen de twee processen (ontwikkelen beheerproces) die onderscheiden zijn te ondersteunen. Per tool wordt kort aangegeven wat de tool biedt en wordt aangegeven waar meer informatie over de tool te vinden is. Naast de beschrijvingen van de tools biedt dit hoofdstuk ook een overzichtstabel waarin weergegeven wordt welke tool welke modellen en processen ondersteund. De eerste paragraaf geeft een korte beschrijving van de verschillende tools, de tweede paragraaf geeft een overzichtstabel van de tools en hun mogelijkheden. We onderkennen hierbij dat door de beperkte tijd die beschikbaar was voor het ontwikkelen van dit instrument de omschrijvingen en de tabel alleen gebaseerd zijn op beschrijvingen van de tools, en niet op uitgebreide tests per tool, waardoor de omschrijvingen en de tabel slechts een indicatie geeft van de mogelijkheden per tool.

7.1

Tools Deze paragraaf beschrijft de tools die ondersteuning bieden voor het creëren van semantische interoperabiliteit tussen twee partijen die willen samenwerken. Per tool wordt kort omschreven wat de tool biedt en wordt gerefereerd naar een locatie waar meer informatie over de tool te vinden is.

7.1.1

Adlib Adlib wordt veel gebruikt voor catalogi van archieven bibliotheken en musea. Adlib heeft ook een thesaurus builder [Adlib, 2008]

7.1.2

Protégé Protégé is een gratis, open-source platform, waarmee semantische modellen kunnen worden opgesteld. Primair is de applicatie gericht op het modelleren van ontologieën. De applicatie bestaat uit twee onderdelen: • Protégé-frames, waarmee gebruikers een semantisch model van/voor een bepaald domein kunnen maken op basis van het OKBC-protcol (Open Knowledge Base Connectivity). • Protégé-OWL, waarmee een OWL-bestand van een semantisch model (ontologie) kan worden gemaakt. Naast een gebruikersinterface is er een onderliggende component, waarin het semantische model beheerd wordt. Deze component is via API’s te benaderen, waardoor de opgeslagen informatie geautomatiseerd benaderd kan worden vanuit andere applicaties. [Protégé, 2008].

7.1.3

Semansys Taxonomy Builder Semansys Taxonomy Builder is een tool gericht op het ontwikkelen van een taxonomie ten behoeve van XBRL. De tool kan gecombineerd worden met Taxonomy Viewer, waarmee de ontwikkelde taxonomie kan worden bekeken. [Semansys, 2008].

7.1.4

Altova XMLSpy XMLSpy is een geïntegreerde ontwikkelomgeving voor diverse soorten XMLbestanden. Wanneer een semantisch model opgeslagen wordt in een XML-formaat, dan


50 / 63

Integrate

kan deze omgeving gebruikt worden voor de technische ontwikkeling, debugging en beheer van het semantisch model. Vanuit een XML-bestand kan XMLSpy code genereren voor toepassing in verschillende ontwikkelomgevingen. De nieuwste versie bevat tevens tools om vanuit een grafische werkomgeving XML-bestanden te vullen, zonder technische kennis van het XML-bestand zelf [Altova, 2008a]. 7.1.5

oXygen XML editor oXygen is een geïntegreerde ontwikkelomgeving voor diverse soorten XML-bestanden. Het bidet ondersteuning voor XML authoring, XML conversion, XML Schema, DTD, Relax NG en Schematron ontwikkeling, XPath, XSLT, XQuery debugging, testen van SOAP WSDL testing. De integratie tussen oXygen en XML document repositories wordt gemaakt door middle van WebDAV, Subversion and S/FTP protocols. biedt hiernaast ook ondersteuning voor het browsen, managen, en bevragen van XML en relationele databases. De XML editor is ook beschikbaar als Eclipse IDE plugin [oXygen, 2008].

7.1.6

Becta's Vocabulary Studio Becta’s Vocabulary Studio is een online vocabulaire management tool die in Engeland gebruikt door overheidspartijen en andere partijen in de onderwijssector. Vocabulary suite maakt het mogelijk om vocabulaires te ontwikkeling, bewerken en beheren. Tevens kan de kwaliteit van de vocabulaires bewaakt worden. Nadat een vocabulaire ontwikkeld is kan deze direct worden geupload naar de Vocabulary bank zodat meer partijen gebruik kunnen maken van de vocabulaire. De vocabulary bank maakt het ook mogelijk om termen te mappen tussen vocabulaires [Becta, 2008].

7.1.7

Altova SemanticWorks Altova SemanticWorks is een visuele RDF en OWL editor. Het is mogelijk om RDF documenten, RDFS vocabulaires en OWL ontologieën grafisch te ontwerpen [Altova, 2008b].

7.1.8

MagicDraw Met behulp van MagicDraw is het mogelijk om grafisch te werken met UML modellering, alleen of in een team. MagicDraw biedt ondersteuning voor de programmeertalen J2EE, C#, C++, CORBA IDL pr, .NET, XML Schema, WSDL. Hiernaast bied het ook ondersteuning voor database schema modellering [MagicDraw, 2008].

7.1.9

CVS In het software ontwikkelingsveld wordt een Current Versions Systems (CVS) veelvuldig gebruikt om versie controle uit te voeren. CVS is gebaseerd op open-source code. CVS kan al het werk dat gedaan wordt aan bestanden bijhouden waarmee het mogelijk wordt dat meerder ontwikkelaars gelijktijdig samenwerken [CVS, 2008].

7.1.10

Subversion (SVN) Subversion is een systeem, vergelijkbaar met CVS, waarmee versies van bestanden en programmacode kan worden beheerd. Versiebeheer vindt plaats op bestandsniveau. Door middel van plugins kan de omgeving benaderd worden vanuit verschillende ontwikkelomgevingen (waaronder Eclipse en Visual Studio). Echter, ook webinterfaces zijn beschikbaar [Subversion, 2008].


51 / 63

Integrate

7.1.11

Microsoft Visio Visio maakt onderdeel uit van de Microsoft Office suite; het is een tekenprogramma waarmee grafische modellen getekend kunnen worden. De mogelijkheden voor validatie van syntactische correctheid zijn echter beperkt. Toch kan het programma goed gebruik worden ten behoeve van brainstorming en het grafisch weergeven van een domeinscope of eerste opzet van een semantisch model. Standaard bevat Visio figuren voor databaseontwikkeling (ERD) en softwareontwikkeling (UML). Er zijn geen standaardfiguren voor de beschreven semantische modellen [Microsoft, 2008b].

7.1.12

Sybase PowerDesigner PowerDesigner is een tool voor het modelleren van data en metadata. Het wordt veel gebruikt bij de ontwikkeling van databaseschema’s. In de laatste versies is ook support aanwezig voor processchema en diverse webservices-standaarden. De ondersteuning voor scope-definitie en team-activiteiten, maken de tool echter ook geschikt voor bepaalde fasen uit het ontwikkelproces van een semantisch model. Voor het formeel vastleggen van een semantisch model is PowerDesigner minder geschikt [Sybase, 2008].

7.1.13

BiZZdesigner BiZZdesigner is gericht op het modelleren van bedrijfsprocessen. Binnen deze bedrijfsprocessen kunnen de daarin relevante objecten worden vastgelegd. Deze objecten kunnen de basis vormen voor een semantisch model. Als het doel van het semantisch model is deze bedrijfsobjecten vast te leggen, dan kan de relatie met bedrijfsprocessen mogelijk dienen als volledigheidscontrole. Vanuit de in BiZZdesigner vastgelegde procesdefinities zal dan in een andere tool een formeel semantisch model moeten worden ontwikkeld [BiZZdesign, 2008].

7.1.14

Mindmanager Mindmanager van Mindjet Gmbh. is een programma waarmee zogenaamde Mindmaps kunnen worden gemaakt, naar analogie van de technieken van Tony Buzan [Buzan, 2008]. Het programma ondersteunt het brainstormingproces en de ordening van gevonden gegevens in een hiërarchische (boom-)structuur. Er zijn beperkte mogelijkheden om relaties te leggen tussen verschillende takken van de boomstructuur. Er zijn geen mogelijkheden de gegevens te exporteren/converteren naar een formeel semantisch model. Ten behoeve van scopebepaling en conceptualisatie kan het programma goed van toepassing zijn. Ook kan het gebruikt worden voor een eerste formalisatie van een taxonomie [Mindjet, 2008].

7.1.15

TopBraid suite TopBraid is een geïntegreerde suite voor het vastleggen van semantische modellen. De primaire focus ligt op ontologieën.


52 / 63

Integrate

De suite bestaat uit drie onderdelen: • TopBraid Composer: voor de ontwikkeling van een model. • TopBraid Live: voor het publiceren van een model. • TopBraid Ensemble: waarmee verschillende personen kunnen werken aan/met een model. Onderliggend is een serverplatform waarop de modellen worden beheerd. Op dit platform kunnen regels worden gevalideerd op het semantische model [TopQuadrant, 2008]. 7.1.16

Circle Software Verseon Verseon is een records management applicatie van de Nederlandse fabrikant Circle Software. De applicatie wordt vaak ingezet als document management systeem (gekoppeld aan records als metadata), maar kan ook omgaan met losse records. Binnen Verseon is er een component ‘Studio’ waarmee gebruikers een gegevensmodel kunnen opstellen. Hierbij kan het zowel gaan om een zelfstandig gegevensmodel als om documenten met metadata. In de studio kan een workflow gekoppeld worden aan bepaalde gegevenstypes. Vervolgens kan er in een gebruikersapplicatie mee gewerkt worden. Ook kunnen de gegevens via de Verseon Integration Architecture als webservice beschikbaar worden gesteld. Hoewel de toepassing primair ligt op het gebied van document management, zijn er veel situaties denkbaar waar Verseon gebruikt kan worden voor de implementatie van een semantisch model [Circle Software, 2008].

7.1.17

Ontostudio en Ontobroker OntoStudio kan gebruikt worden voor het modelleren en beheren van ontologieën. Het biedt onder andere ondersteuning voor het mappen van de ene structuur naar de andere, het grafische bewerken van regels en het biedt een geïntegreerde test omgeving waarmee de kwaliteit van het modelleren gegarandeerd kan worden. Met behulp van de Ontobroker is het mogelijk om ontologieën te verwerken en is het mogelijk om software ontwikkeld worden welke gebaseerd is op ontologieën [Ontoprise, 2008].

7.1.18

Triple20 Triple 20 is een open source RDF/OWL editor geïntegreerd met de SWI prolog infrastructuur. De editor toont een klasse hiërarchie en de properties die een klasse als domein of bereik hebben, maar probeert verder dicht bij het triple model van RDF te blijven.Triple20 kan zeer grote RDF bestanden aan [Triple20, 2008].

7.1.19

Toko Toko is een system voor natuurlijke tekst analyse eveneens gebaseerd op SWI prolog. Met behulp van automatische tekst analyse probeert het belangrijke termen te vinden in een verzameling documenten. Deze termen kunnen dan onmiddellijk worden gebruik om een hiërarchisch georiënteerde ontologie/taxonomie op te zetten die met de geïntegreerde triple20 editor verder kan worden verwerkt [Toko, 2008].


53 / 63

Integrate

7.1.20

Total Content Recommendation vocabulary mapper The TCR vocabulary mapper is een experimenteel systeem om met behulp van statistische analyses op geannoteerde documenten, of andere video’s de betekenis van annotaties van een groep mensen af te beelden op de annotaties van een andere groep mensen. In het bijzonder kan het systeem gebruikt worden om user generated tags te vergelijken met steekwoorden uitgedeeld door professionals

7.1.21

Sesame Sesame is een open source triple database die geschreven is in Java. Het kan zowel RDF triple data als de bijbehorende ontologieën als schema’s opslaan. Tevens is het in staat om simpele redeneringen uit te voeren om te komen tot RDFS en OWL-lite semantics. Sesame kan worden bevraagd door middel van RDQL [Sesame, 2008].

7.1.22

Jena Jena is een open source Java library waarmee RDF kan worden gebruikt binnen een programmeer omgeving. Het maakt het mogelijk om een RDF graaf met hiërarchische en semantische relaties door te lopen en maakt het mogelijk om op te vragen of er nodes bestaan die een specifieke relatie hebben met andere nodes [Jena, 2008].

7.1.23

D2R D2R is een tool om een collectie van gelinkte SQL tabellen om te zetten in een RDFS ontologie en de informatie in de tabellen om te zetten in instanties in een RDF graaf. Het verkort hiermee de benodigde tijd om een relationele database om te zetten in een triple datebase die benodigd is [D2R, 2008].

7.1.24

Apolda Apolda is ontwikkeld om de gebruiksontologie van termen in een document bij te houden. Het is onderdeel van het Java Gate framework for natural language analysis [Apolda, 2008].

7.1.25

SomeHelp SomeHelp is een gratis, simpel IT helpdesk softwareprogramma dat help bij de ondersteuning van het beheer en de administratie van ondersteuningsaanvragen vanuit de organisatie. Het is ontwikkeld als een simpel programma, en ondanks dat het veel verschillende zaken ondersteund is het niet de meest uitontwikkelde oplossing die beschikbaar is [SomeHelp, 2008].

7.1.26

Topdesk Topdesk is een uitgebreid softwareprogramma waarmee medewerkers, klanten en zakenrelaties ondersteund kunnen worden. Topdesk biedt ondersteuning voor ITIL, ISO 20000 en SOX [Topdesk, 2008].

7.1.27

ServiceDesk Plus ServiceDesk Plus is een webgebaseerde helpdesk omgeving. Het biedt ondersteuning voor ITIL en tevens ondersteuning voor inkooporder processen [ServiceDesk, 2008].

7.1.28

Lexico Lexico is een tool om thesauri te ontwikkelen welke vervolgens benaderd en bewerkt kunnen worden over het internet [Lexico, 2008]


54 / 63

Integrate

7.1.29

LinKFactory LinKFactory is een formeel ontologie gebaseerd terminologie management systeem ontwikkeld om gebruikt te worden door teams. Het biedt ondersteuning voor het geven van definities met behulp van redeneer systemen [LinKFactory, 2008].

7.1.30

MetaTagger Studio MetaTagger Studie biedt ondersteuning voor het ontwikkelen en beheren van vocabulaires en thesauri [MetaTagger, 2008].

7.1.31

MIDOSThesaurus MIDOSThesaurus biedt ondersteuning voor het ontwikkelen van thesauri, waarbij het ondersteuning heeft voor alle standaard relaties. Het heeft ondersteuning voor een meertalige thesaurus welke kan bestaan uit maximaal 10 talen (inclusief primaire taal). De tool biedt ondersteuning voor naar HTML in alfabetische of hiërarchische volgorde [MIDOSThesaurus, 2008].

7.1.32

Multites Multites biedt ondersteuning voor het ontwikkelen van thesauri waarbij het automatisch kan controleren of relaties conflicterend zijn. Het biedt ondersteuning voor ANSI/NISO relaties, plus zelfgedefinieerde relaties. Tevens biedt het ondersteuning voor het exporteren van thesauri naar HTML en XML formaat [Multites, 2008].

7.1.33

Semaphore Taxonomy Manager Semaphore Taxonomy Manager biedt ondersteuning voor taxonomieën die met de hand kan worden ingevoerd of kan worden geïmporteerd via XML of het MultiTES formaat. Het beidt verder ondersteuning voor het werken met teams en het biedt meerdere niveaus voor reviewen en goedkeuren [Semaphore, 2008].

7.1.34

Unicorn Unicorn werkt met een centraal ‘ontologie model’ waarbinnen meerdere vocabulaires te onderkennen. Vanuit verschillende bronnen kunnen ‘assets’ geïmporteerd of gedefinieerd worden (bijvoorbeeld uit een XML Schema, een databaseschema, een flat file formaat, schermen, COBOL gegevensopslagformaten etc.). De assets zijn losstaande producten die geen deel uitmaken van een vocabulaire: bijvoorbeeld externe OFX XML Schema's zijn individuele producten, en er wordt geen OFX vocabulaire onderkend [IBM, 2008a].

7.1.35

SchemaLogic SchemaLogic biedt ondersteuning voor het managen van vocabulaires en metadata. Tevens wordt het beheer van referentiegegevens wordt ondersteund. Het systeem biedt ook ondersteuning voor versiebeheer door middel van synchronisatie met andere systemen (bijv. een CMS), waarbij dan telkens een ‘snapshot’ wordt gemaakt van de uitgeleverde metadata [SchemaLogic, 2008].

7.1.36

Rational Rose Enterprise IBM’s Rational Rose Enterprise biedt ondersteuning voor het creëren van software. Hiervoor biedt het UML modellering for database ontwerpen en biedt het ondersteuning voor het creëren van XML DTD’s [IBM, 2008b].

55 / 63


7.1.37

Enterprise Architect Enterprise Architect van Sparx Systems biedt ondersteuning voor het analyseren en ontwerpen van UML. Het biedt hiermee ondersteuning voor de volgende stappen in de ontwikkeling van software: analyse, ontwerpen, testen en onderhoud [Sparx Systems, 2008].

7.1.38

UMM Add-In Enterprise Architect De UMM add-in voor Enterprise Architect biedt ondersteuning voor het gebruik van de UMM methode [UMM, 2008] binnen Enterprise Architect. De UMM methode maakt het mogelijk om business informatie op te slaan ongeacht de implementatie technieken die gekozen zijn. Het doel dat UMM hiermee nastreeft is om een globale choreografie te specificeren van een samenwerking tussen partijen die gebruik kan worden als ‘overeenkomst’ tussen de samenwerkende partijen [UMM Add-In, 2008].

7.2

Overzichtstabel tools en mogelijkheden Deze paragraaf presenteert een tabel waarin per tool wordt aangegeven welke van de semantische modellen ontwikkeld kunnen worden met de betreffende tool, en welke processtappen ondersteund worden door de tool. Tooling die gebruikt kan worden om een ontologie te ontwikkelen kan over het algemeen ook gebruikt worden om strings, een vocabulaire, een thesaurus, een taxonomie, een metadata schema en een gegevenscatalogus vast te leggen. In de onderstaande tabel zetten we voor deze tools echter alleen een kruisje bij het model ontologie aangezien de tool daarvoor is ontwikkeld. Omdat de tabel alleen gebaseerd is op beschrijvingen van de tools, en niet op uitgebreide tests per tool, geeft de tabel slechts een indicatie van de mogelijkheden per tool.

SchemaLogic Total Content Recommendation Vocabulary mapper MetaTagger Studio Unicorn Becta's Vocabulary Studio Lexico MIDOSThesaurus MultiTes

Technisch beheer

Applicatie beheer

Methodiek

Functioneel beheer

Evaluatie

Formalisatie

Conceptualisatie

→

Scope en specificatie

voor

Vocabulaire Thesaurus Taxonomie Metadata schema Gegevencatalogus Ontologie Object-gebeurtenis model

ondersteuning Tooling ↓

Strings

Semantische modellen

Processen Processen voor de voor opzetten ontwikkeling organisatie van voor semantische ontwikkeling modellen en beheer

x x x x x x x x x x

x x

x x

x

x

x

x

x

56 / 63


LinKFactory Semaphore Taxonomy Manager Adlib Altova SemanticWorks Toko Protégé Triple20 Semansys Taxonomy Builder Altova XMLSpy oXygen XML editor Apolda Ontostudio en Ontobroker Sesame Jena D2R TopBraid suite MagicDraw Rational Rose Enterprise Enterprise Architect UMM add-in Enterprise Architect Microsoft Visio Mindmanager Bizzdesigner Sybase PowerDesigner Circle Software Verseon CVS Subversion (SVN) Topdesk SomeHelp ServiceDesk Plus

x x x x x x x

Technisch beheer

Applicatie beheer

Methodiek

Functioneel beheer

Evaluatie

Formalisatie

→

Conceptualisatie

voor

Vocabulaire Thesaurus Taxonomie Metadata schema Gegevencatalogus Ontologie Object-gebeurtenis model

ondersteuning Tooling ↓

Strings

Semantische modellen

Scope en specificatie

Processen Processen voor de voor opzetten ontwikkeling organisatie van voor semantische ontwikkeling modellen en beheer

x x x x x x x x x x x x x

x x x x x

x

x

x x x

x x x x x x

x x x x x x

x x x x x x x x x x x

x x

x x

x x

x x

x x x x x x x

x x x

x

x x x

x x

x x x

x x x x x x


57 / 63

Integrate

8

Conclusies en aanbevelingen Dit hoofdstuk presenteert een set van conclusies die voorkomen uit het onderzoek dat gepresenteerd is in dit document. Verder worden er aanbevelingen gedaan over voortzetting van het gepresenteerde onderzoek.

8.1

Conclusies De volgende conclusies komen uit het gepresenteerde onderzoek voort: - Dit document presenteert een beslisboom aan de hand van de eigenschappen van de semantische modellen waarmee bepaald kan worden wat het meest geschikte semantische model is voor het oplossen van een interoperabiliteitsprobleem. - Dit document presenteert een overzicht van de meest gebruikte semantische modellen en geeft voor deze semantische modellen een heldere definitie. - In dit document is een stappenplan gepresenteerd voor het ontwikkelen van een semantisch model dat zorg draagt voor een goed en gestructureerd verloop van het ontwikkelproces. - Aan de hand van beheerprocessen die gebaseerd zijn op het beheren van applicaties is er in dit document een overzicht gegeven van de belangrijke aspecten bij het opzetten van een beheerorganisatie voor het beheer van semantische modellen. - In dit document wordt een overzicht getoond van tooling die gebruikt kan worden voor het ondersteunen van het ontwikkelen en beheren van semantische modellen die beschreven zijn in dit document. - Het gebruik van dit hele document als instrument bij het ontwikkelen en beheren van semantische modellen maakt de kans op het vergeten of overslaan van een essentieel onderdeel om semantische interoperabiliteit te bereiken kleiner.

8.2

Aanbevelingen Aan de hand van het gepresenteerde onderzoek worden de volgende aanbevelingen gedaan: - Toets de beslisboom aan de hand van cases waarin in het verleden een keuze is gemaakt voor een semantisch model. Hierdoor kan gekeken worden of de beslisboom tot dezelfde keuze voor het semantische model komt. Mocht de beslisboom een andere keuze aangeven kan er gekeken worden of de beslisboom hierop aangepast moet worden. - Als de beslisboom getoetst is aan de hand van al bestaande cases is het interessant om de beslisboom ook toe te gaan passen in nieuwe cases om met behulp van de beslisboom de keuze voor een semantisch model te maken. Ook uit het uitvoeren van deze toetsing kan blijken dat de beslisboom aangepast dient te worden.


58 / 63

Integrate

- De beslisboom die gepresenteerd is, is volledig deterministisch, er komt altijd één model uit dat geschikt is. Er zullen in de praktijk echter ook gevallen zijn waar het onderscheid minder goed te maken is. Er zou in de toekomst gekeken kunnen worden of het mogelijk is om het non-deterministische karakter van de geschikte modellen voor een interoperabiliteitsprobleem ook op te nemen in de beslisboom. - De huidige beslisboom is gebaseerd op de onderscheidende eigenschappen van de semantische modellen. Het is interessant om verder onderzoek te doen naar een beslisboom gebaseerd op eigenschappen van het interoperabiliteitsprobleem omdat daarbij geen kennis nodig is van de semantische modellen. - De definities van de semantische modellen moeten in de praktijk getoetst worden aan al in gebruik zijnde definities. Hierdoor kan er getoetst worden of de definities compleet zijn en of het inderdaad de meest gebruikte definities zijn. Verder zou de beschrijving van de definities uitgebreid kunnen worden met een beschrijving van de afwijkende definities zodat helder is wat de afwijkingen zijn en hoe met deze afwijkingen in de praktijk omgegaan kan worden. - De checklist die op dit moment is opgesteld voor het beheren van semantische modellen zou uitgebreid kunnen worden tot een stappenplan voor het inrichten van het beheer en het beheren van semantische modellen. - Verder onderzoek naar tool support voor het ontwikkelen van semantische modellen en voor ondersteuning van het beheer van de semantische modellen. Hierbij kan bijvoorbeeld gekeken worden naar de sterke en zwakken punten van de tools en kan gebruiksgemak eventueel meegenomen worden. Verder zou in dit onderzoek ook gekeken moeten worden naar de definities van de semantische modellen die binnen de tool worden gehanteerd om te bepalen of deze definities aansluiten bij de gegeven definities in dit document.


59 / 63

Integrate

9

Referenties [Adlib, 2008]

Adlib, http://www.adlibsoft.nl, laatst bezocht: 15-07-2008

[Altova, 2008a]

Altova XML Spy, http://www.altova.com/products/xmlspy/xml_editor.html, laatst bezocht: 25-06-2008

[Altova, 2008b]

Altova Semantics Works, http://www.altova.com/products/semanticworks/semantic_web_rdf_owl_edit or.html, laatst bezocht: 25-06-2008

[ANSI-NISO, 2005]

ANSI-NISO Z39.19-2005, Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies, http://www.niso.org/kst/reports/standards?step=2&gid=None&project_key=7 cc9b583cb5a62e8c15d3099e0bb46bbae9cf38a, laatst bezocht: 10-07-2008

[Apolda, 2008]

Apolda, http://apolda.sourceforge.net/, laatst bezocht: 26-06-2008

[ASL, 2008]

ALS Foundation, http://www.aslfoundation.org/, laatst bezocht: 25-06-2008

[Batavia, 2008]

Batavia XBRL Java library, http://sourceforge.net/projects/batavia-xbrl/, laatst bezocht: 10-07-2008

[Becta, 2008]

Becta Vocabulary Studio, http://industry.becta.org.uk/display.cfm?resID=2073, laatst bezocht: 25-062008

[BIZZdesign, 2008]

BiZZdesigner, http://www.bizzdesign.nl/joomla/products/bizzdesigner.html, laatst bezocht: 26-06-2008

[Boer & Huijzer, 2005]

Boer, H., Huijzer, N. (2005), “ASL en Microsoft-frameworks, als twee druppels water?” In: IT Beheer, oktober 2008.

[Brussee & Pokraev, 2007]

Brussee, R., Pokraev, S. 2007, Reasoning on the semantic web, in Cardoso, J. ed. Semantic Web Services theory, tools and applications, Information Science Reference 2007.

[Buzan, 2008]

Tony Buzan, http://www.buzanworld.com/, laatst bezocht:26-06-2008

[Calhoun, 2006]

Calhoun, K. 2006, The Changing Nature of the Catalog and its Integration with Other Discovery Tools, White paper for the Library of Congres, March 17, 2006, http://www.loc.gov/catdir/calhoun-report-final.pdf

[Choice, 2008a]

Choice, Beschrijving van het Choice project, http://ems01.mpi.nl/CHOICE/, laatst bezocht: 10-07-2008


60 / 63

Integrate

[Choice, 2008b]

Choice, GTAA Thesaurus browser, http://ems01.mpi.nl:8080/GTAABrowser, laatst bezocht: 10-07-2008

[Circle Software, 2008]

Circle Software, http://www.circlesoftware.nl/producten/verseon/, laatst bezocht: 26-06-2008

[CVS, 2008]

CVS, http://www.nongnu.org/cvs, laatst bezocht: 25-06-2008

[D2R, 2008]

D2R, http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/, laatst bezocht: 2606-2008

[DCMI, 2008]

DCMI, Dublin Core Metadata Initiative, Dublin Core (ISO 15836) http://dublincore.org/, laatst bezocht: 10-07-2008

[De Jong, 2007]

De Jong, A.S.M 2007, Metadatamodel Beeld en Geluid biedt gebruiker van digitale content diepte en structuur, Informatie Professional Juni 2007, p. 24-29.

[de Saussure, 1986]

de Saussure 1916, F., Course in General Linguistics., Roy Harris (trans.), Open Court Publishing Company, 1986 (original from 1916).

[FOAF, 2008]

FOAF specificatie, http://xmlns.com/foaf/spec/, laatst bezocht: 10-07-2008

[GeneOntolog y, 2008]

GeneOntology, http://www.geneontology.org/, laatst bezocht: 10-07-2008

[Gomez-Perez, 1997]

Gomez-Perez, N.J. (1997) METHONTOLOGY: From Ontological Art Towards Ontological Engineering. Workshop on Ontological Engineering, proceedings

[Hunter, 2008]

Hunter, J. Reconciling MPEG-7 and MPEG-21 Semantics through a Common Event-Aware Metadata Model, http://arxiv.org/abs/cs/0210021, laatst bezocht: 10-07-2008

[IBM, 2008a]

IBM Unicorn, http://www.sirsidynix.com/Solutions/ Products/integratedsystems.php#unicorn, laatst bezocht: 26-06-2008

[IBM, 2008b]

IBM Rational Rose Enterprise, http://www.ibm.com/software/awdtools/ developer/rose/enterprise/, laatst bezocht: 26-06-2008

[IMDb, 2008]

Internet Movie Database (IMDb) Genres, http://www.imdb.com/Sections/Genres/, laatst bezocht: 10-07-2008

[ISO, 2004]

ISO, MPEG-7 Overview (ISO/IEC JTC1/SC29/WG11N6828) http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm, laatst bezocht: 10-07-2008


61 / 63

Integrate

[ITIL, 2008]

ITIL, http://www.itil-officialsite.com/, laatst bezocht: 25-6-2008

[Jena, 2008]

Jena, http://jena.sourceforge.net/, laatst bezocht: 26-06-2008

[Jones et.al., 1998]

Jones, D., Bench-Capon, T. & Visser, P. (1998) Methodologies for Ontology Development. Proceedings of the IT&Knows Conference

[LCC, 2008]

Library of Congress Classification, http://www.loc.gov/aba/cataloging/classification/, laatst bezocht: 30-07-2008

[Lexico, 2008]

Lexico, http://www.pmei.com/lexico.html, laatst bezocht: 26-06-2008

[LinKFactory, 2008]

LinKFactory, http://www.landcglobal.com/pages/linkfactory.php, laatst bezocht: 26-06-2008

[Looijen, 2000]

Looijen, M. (2000), “Beheer van informatiesystemen”, 5e druk, Kluwer Bedrijfsinformatie, Deventer

[Magenta, 2008]

Magenta Technology, Glossary http://www.magentatechnology.com/en/technology/glossary/, laatst bezocht: 10-07-2008

[MagicDraw, 2008]

MagicDraw, http://www.magicdraw.com, laatst bezocht: 25-06-2008

[Meijer & Boer, 2004]

Meijer, M., Boer, H. (2004), “De betekenis van ASL en ITIL AM voor applicatiebeheer” In: IT Service Management, best practices, deel 1.

[Meijer & Meijers, 2002]

Meijer, M., Meijers, J. (2002) “Effectief IT-beheer: samenwerken waar nodig, zelfstandig opereren waar mogelijk” In: IT Beheer Jaarboek 2002.

[MetaCyc, 2008]

MetaCyc, http://metacyc.org/, laatst bezocht: 10-07-2008

[MetaTagger, 2008]

MetaTagger, http://www.interwoven.com/products/content_intelligence/studio/, laatst bezocht: 26-06-2008

[Microsoft, 2008a]

Microsoft, MOF en MS, http://technet.microsoft.com/enus/library/cc506049.aspx, laatst bezocht: 25-06-2008

[Microsoft, 2008b]

Microsoft Visio, http://www.microsoft.com/netherlands/office/visio/, laatst bezocht: 26-06-2008

[MIDOSThesa urus, 2008]

MIDOSThesaurus, http://www.progris.de/midost.htm, laatst bezocht: 26-062008

[Mindjet, 2008]

Mindject Mindmanager, http://www.mindjet.com/products/mindmanager_pro/, laatst bezocht: 26-062008


62 / 63

Integrate

[Multites, 2008]

Multites, http://www.multites.com, laatst bezocht: 26-06-2008

[NC Echo, 2007]

North Carolina ECHO, Exploring Cultural Heritage Online http://www.ncecho.org/guide/glossary.htm, laatst bezocht: 10-07-2008

[NTP, 2008]

Het Nederlandse Taxonomie Project, http://www.xbrl-ntp.nl/, laatst bezocht: 30-07-2008

[Ogden & Richard, 1923]

Ogden, C. K., Richard, S. I. A. 1923.The Meaning of Meaning: A Study of the Influence of Language Upon Thought and of the Science of Symbolism., New York: Harcourt Brace Jovanovich, 1923.

[Ontoprise, 2008]

Ontoprise Ontostudio, http://www.ontoprise.de/index.php?id=179, laatst bezocht: 26-06-2008

[Outvorst et. al., 2005]

van Outvorst, F., Donatz, R., van der Pols, R. (2005), “Introductie BiSL, Een framework voor functioneel beheer en informatiemanagement” In: IT Service Management best practices, deel 2, ITSMF Nederland, Van Haren Publishing

[oXygen, 2008]

oXygen, http://www.oxygenxml.com/, laatst bezocht: 25-06-2008

[Protégé, 2008]

Protégé, http://protege.stanford.edu/, laatst bezocht: 25-06-2008

[Rumbaugh et.al., 2005]

Rumbaugh, J., Jacobson, I., Booch, G. (2005), The Unified Modeling Language Reference Manual, Second Edition, Addison-Wesley, ISBN: 0321-24562-8

[SchemaLogic, 2008]

SchemaLogic, http://www.schemalogic.com, laatst bezocht: 26-06-2008

[Semansys, 2008]

Semansys, http://www.semansys.com/taxonomy_builder.html, laatst bezocht: 25-06-2008

[Semansys, 2008b]

Semansys, Press Release: Microsoft Dynamics features XBRL by Semansys http://www.semansys.com/PDF/Press%20release%20Semansys%20Microsof t%20XBRL%20ENG%20DR.pdf, laatst bezocht: 10-07-2008

[Semaphore, 2008]

Semaphore, http://www.aprsmartlogik.com/download/pdf/ SemaphoreTaxonomyModuleFactSheet.pdf, laatst bezocht: 26-06-2008

[ServiceDesk, 2008]

ServiceDesk, http://manageengine.adventnet.com/products/servicedesk/index.html, laatst bezocht: 26-06-2008

[Sesame, 2008]

Sesame, http://www.openrdf.org/, laatst bezocht: 26-06-2008

[Sieders & Pols, 2002]

Sieders, R., van der Pols, R. (2002), “Application Services Library” In: Informatie, juni 2002


63 / 63

Integrate

[Snoeck et.al., 1999]

Snoeck,M., Dedene, G., Verhelst, M., Depuydt, A. (1999), “The object-event table” In: Object-Oriented Enterprise Modelling with MERODE, p.77-90, Universitaire Pers Leuven, ISBN: 90-6186-977-3

[SomeHelp, 2008]

SomeHelp, http://www.somehelp.net/, laatst bezocht: 26-06-2008

[Sparx Systems, 2008] [SVN, 2008]

Enterprise Architect, Sparx Systems, http://www.sparxsystems.com.au/products/ea/index.html, laatst bezocht: 2409-2008 SVN, http://subversion.tigris.org, laatst bezocht: 26-06-2008

[Sybase, 2008]

Sybase PowerDesigner, http://www.sybase.com/products/ modelingmetadata/powerdesigner, laatst bezocht: 26-06-2008

[Thiadens, 2002]

Thiadens, T. (2002), “Beheer van ICT-voorzieningen”, 4e druk, Academic Service, Schoonhoven

[Toko, 2008]

Toko, http://www.toko-sigmund.org/download.html, laatst bezocht: 26-062008

[Topdesk, 2008]

Topdesk, http://www.topdesk.com/nl/home, laatst bezocht: 26-06-2008

[TopQuadrant, 2008]

TopQuadrant TopBraid suite, http://www.topquadrant.com/topbraid/index.html, laatst bezocht: 26-06-2008

[Triple20, 2008]

Triple20, http://www.swi-prolog.org/packages/Triple20/, laatst bezocht: 2606-2008

[UKAT, 2008a]

UKAT, http://www.ukat.org.uk, laatst bezocht: 10-07-2008

[UKAT, 2008b]

UKAT browser, http://www.ukat.org.uk/thesaurus/hierarchy.php, laatst bezocht: 10-07-2008

[Ullmann, 1972]

Ullmann S., 1972 .Semantics: An Introduction to the Science of Meaning., Basil Blackwell, Oxford,1972

[UMM, 2008]

UN/CEFACT’s Modeling Methodology (UMM), http://www.unece.org/cefact/umm/umm_index.htm, laatst bezocht: 24-92008.

[UMM AddIn, 2008]

UMM Add-In Enterprise Architect, http://umm-dev.org/, laatst bezocht: 24-92008

[Ushold, 1996]

Ushold M. (1996) “Building Ontologies: Towards A Unified Methodology”, Proc. Expert Systems 96, Cambridge, December 16-18th.

[Van Dale, 1997]

Van Dale 1997, Groot Elektronisch Hedendaags Woordenboek, Taxonomie Lemma


[W3C, 2004a]

W3C, RDF Vocabulary Description Language 1.0: RDF Schema http://www.w3.org/TR/rdf-schema/, laatst bezocht: 10-07-2008

[W3C, 2004b]

W3C, OWL Web Ontology Language, Overview http://www.w3.org/TR/owl-features/, laatst bezocht: 10-07-2008

[W3C, 2008]

W3C, Simple Knowledge Organization System (SKOS) - Home Page http://www.w3.org/2004/02/skos/, laatst bezocht: 10-07-2008

[Wikipedia 2008e]

EDucatieve Export – Nederlands Technische Afspraak 2032, Wikipedia, http://nl.wikipedia.org/wiki/Edex, laatst bezocht: 30-07-2008

[Wikipedia, 2008c]

eXtensible Business Reporting Language, Wikipedia, http://nl.wikipedia.org/wiki/XBRL, laatst bezocht: 30-07-2008

[Wikipedia, 2008a]

Wikipedia, Taxomomy artikel http://en.wikipedia.org/w/index.php? title=Taxonomy&oldid=220821337, laatst bezocht: 10-07-2008

[Wikipedia, 2008b]

Wikipedia, Ontology artikel, http://en.wikipedia.org/wiki/ Ontology_%28information_science%29, laatst bezocht: 10-07-2008

[Wikipedia, 2008d]

Library of Congress Classification, Wikipedia, http://en.wikipedia.org/wiki/Library_of_Congress_Classification, laatst bezocht: 30-07-2008

[Wordnet, 2008]

Wordnet, Catalogue lemma, http://wordnet.princeton.edu/perl/ ebwn?s=catalogue, laatst bezocht: 10-07-2008

64 / 63


Bijlage A | 1/3

Integrate

A

Bestaande modellen voor inrichting van de beheergebieden Deze bijlage presenteert een aantal veelgebruikte modellen het inrichten van de onderscheiden beheergebieden voor ict-voorzieningen. Deze modellen zijn niet t 1-op-1 toe te passen voor het beheren van semantische modellen, maar ze geven wel handvatten die gebruikt kunnen worden om gelijksoortige modellen op te zetten voor het beheer van semantische modellen. BiSL (Functioneel beheer) De BiSL-standaard is ontwikkeld als standaard voor functioneel beheer en informatiemanagement. BiSL maakt een onderscheid tussen processen op drie niveaus: uitvoerend, sturend en richtinggevend. De uitvoerende of operationele processen hebben betrekking op het dagelijks gebruik van de informatievoorziening en houden zich bezig met het vormgeven en realiseren van veranderingen in de informatievoorziening. De sturende processen hebben betrekking op de kosten en opbrengsten, planningen, kwaliteit van de informatievoorziening en afspraken met de ICT-leverancier. De richtinggevende processen houden zich bezig met het bepalen hoe de informatievoorziening er op de lange termijn uit moet zien. De richtinggevende processen ook aan hoe de sturing op de informatievoorziening moet worden georganiseerd. Binnen de drie niveaus zijn de verschillende processen geclusterd in zeven procesclusters, hiervan zitten er drie op het uitvoerende niveau (gebruiksbeheer, functionaliteitenbeheer en de verbindende processen op het uitvoerend niveau), één op het sturende niveau (Overkoepelend, brug tussen richtinggevend en uitvoerend niveau) en drie op het richtinggevende niveau (Opstellen informatiestrategie, IVorganisatiestructuur en verbindende processen op richtinggevend niveau) [Outvorst et. al., 2005]. ASL (Applicatie beheer) De Application Services Library (ASL) een framework gericht op het inrichten van applicatie beheer. Het beschrijft het management van het beheer, het onderhoud en de vernieuwing van applicaties (applicatieprogrammatuur en de databasestructuren) op een bedrijfsmatig verantwoorde manier [ASL08]. Binnen de ASL wordt een onderscheid gemaakt in drie niveaus: richtinggevende (governance), sturende (management) en uitvoerende (operations). Het richtinggevende niveau maakt een onderscheid in twee clusters, het services en het applications cluster. Het eerste cluster heeft een services-invalshoek, het tweede cluster een applicatie-invalshoek. Het eerste cluster heeft voornamelijk betrekking op de toekomst visie van de gehele organisatie, bij semantische modellen zou hierbij gekeken kunnen worden naar hoe er in de toekomst omgegaan moet worden met de semantische modellen en hoe dit binnen het beleid vertaald kan worden. Het tweede cluster heeft betrekking op de lange termijn strategie van een organisatie, voor de semantische modellen zou hierbij gekeken kunnen worden naar de plannen en ideeën op de langere


Bijlage A | 2/3

Integrate

termijn en hoe de semantische modellen verbeterd kunnen worden door ontwikkelingen binnen de IT sector. Het sturende niveau bevat de overkoepelende managementprocessen. Deze processen worden gevoed vanuit zowel de richtinggevende als wel de uitvoerende niveaus en zijn daarmee zorgen ze ervoor dat in de managementprocessen toekomstgerichtheid en de dagelijkse realiteit sterk en expliciet verankerd zijn. Het uitvoerende niveau bevat twee clusters van processen, het beheer en onderhoud/ontwikkeling van applicaties, voor de semantische modellen zou hierbij gekeken kunnen worden naar het beheer en onderhoud/ontwikkeling van de semantische modellen [Sieders & Pols, 2002; Boer & Huijzer, 2005; Meijer & Boer, 2004]. ITIL Application management (Applicatie beheer) ITIL Application Management (ITIL AM) bestaat uit een set met best practices om de kwaliteit van de ontwikkeling en beheer van software verbeteren. Deze verbetering is gericht op de hele levenscyclus van software ontwikkeling en beheer projecten. De nadruk ligt bij ITIL AM op het verzamelen en definiëren van eisen aan de software die aansluiten bij wat de business wil. De levenscyclus die binnen ITIL AM wordt onderscheiden bestaat uit de volgende zes stappen: Requirements, Design, Build, Deploy, Operate & Optimize. •

•

•

• •

•

Requirements: In samenwerking met de business unit moeten de functionele en business proces eisen worden vastgelegd voor de nieuwe of te wijzigen applicatie. Tijdens het verzamelen van de eisen worden de eerste service level eisen geïdentificeerd. Design: Een applicatie team vertaalt de eisen die gesteld zijn naar een technische oplossing. Een Total Cost of Ownership (TCO) studie wordt in deze fase uitgevoerd om te bepalen wat de kosten zijn voor de ontwikkeling en de ondersteuning. Build: In deze fase van de levenscyclus wordt de applicatie geprogrammeerd en getest. Alle onderdelen van de software worden onafhankelijk geprogrammeerd en in eerste instantie onafhankelijk getest, in tweede instantie worden de onderdelen ook gezamenlijk getest. Tijdens het testen wordt er gezocht naar zowel naar de functionele als procesmatige fouten in de software. Deploy: In deze fase wordt de applicatie uitgerold. In deze fase wordt niet alleen de software ingezet op productie omgevingen, ook trainingen voor klanten worden in deze fase gegeven. Operate: Dit is de fase waarin de applicatie terecht komt als hij eenmaal volledig in gebruik is genomen. Vragen en problemen worden opgepakt in deze fase, wijzigingen zullen ook in deze fase verwerkt worden in de applicatie. In deze fase worden ook de service niveaus in de gaten gehouden om ervoor te zorgen dat de eisen die gesteld zijn worden gehaald. In alle gevallen is het doel van deze fase om de impact van problemen met de applicatie zo klein mogelijk te houden voor de gebruikers. Optimize: Dit is de laatste stap in de levenscyclus, hierna wordt weer van vooraf aan begonnen. In deze fase worden zowel functionele optimalisatie uitgevoerd, als wel optimalisatie van de performance [Meijer & Boer, 2004; ITIL, 2008].


Bijlage A | 3/3

Integrate

Microsoft MOF/MSF (Applicatie beheer) Het Microsoft Operations Framework (MOF) geeft, in combinatie met het Microsoft Solutions Framework (MSF), een handleiding voor het dagelijkse beheer van ICT activiteiten. [Microsoft, 2008a; Boer & Huijzer, 2005] Het helpt hierbij mee aan het realiseren en implementeren van betrouwbare, kostenefficiënte IT service. Het MOF bestaat uit een aantal fasen die samen de hele IT levenscyclus beschrijven: Plan, Deliver, Operate en Manage. •

•

•

•

Plan: In de planningsfase wordt ondersteuning geboden om continuïteit van de service strategie te plannen en te optimaliseren. Deze fase helpt services te leveren die waardevol zijn voor het bedrijf. Die voorspelbaar en betrouwbaar zijn en voldoen aan het beleid van de onderneming. Deliver: In de deliver fase worden tools geboden aan IT professionals om IT services, infrastructuur projecten en de uitrol van software meer efficiënt te leveren. Deze fase zorgt er tevens voor dat er een planning is voor de uitrol van nieuwe software die voldoen aan de business eisen. Operate: In deze fase valt het gebruik van de applicatie nadat het uitgerold. Het geeft handvaten om de services efficiënt te laten draaien, monitoren en om een efficiënte ondersteuning te bieden, waarbij de Service Level Agreement (SLA) targets gehaald worden. Manage: Deze fase maakt geen onderdeel uit van de levenscyclus, maar ligt om de hele cyclus heen. Deze fase zorgt ervoor dat de andere drie fasen geïntegreerd werken en alle drie op dezelfde lijn zitten bij het ontwikkelen en beheren van de software pakketten.

ITIL (Technisch beheer) ITIL (Information Technology Infrastructure Library), is ontwikkeld om als referentiekader te dienen voor het inrichten van de beheerprocessen binnen een ICT organisatie. ITIL is opgebouwd uit een set van best practices, en biedt om deze reden dus geen methode of model om de beheerprocessen op te zetten. Als er gekeken wordt waar het implementeren van ITIL mee vergeleken kan worden in de niet ICT branche is dit de ISO 9000 regulering. ITIL beschrijft dus alle onderdelen van de ICT organisatie en zorgt ervoor dat deze onderdelen in een hiërarchie van bevoegdheden en verantwoordelijkheden gerangschikt zijn. De Service Life-cycle is de basis van ITIL versie 3 en bestaat uit de volgende fasen: • Service Strategy • Service Design • Service Transition • Service Operation • Continnual Service Improvement [ITIL, 2008]


Bijlage B | 1/2

Integrate

B

EDEX NTA # #sectie EDEX 3.2.1, onderscheid Leerlingen en docenten als personen #voer het begrip persoon in. edex:Persoon a owl:Class. #EDEX 7 Leerling #Leerlingen zijn personen, er moet minstens één naam bekend zijn #Namen volgen de Naamgegevens structuur van de Gemeentelijke #Basis Administratie (GBA), edex:Leerling a owl:Class; rdfs:subClassOf edex:Persoon, [a owl:Restriction; owl:onProperty owl:naamGegeven; owl:minCardinality 1]. edex:naamGegeven a owl:ObjectProperty; rdfs:domain edex:Persoon; rdfs:range edex:NaamGegeven. #Het GBA onderscheid verschillende soorten namen die meer en minder #onderscheidend zijn. In dit voorbeeld hebben we alleen een gewone naam #hiervan moet er minstens een bestaan edex:NaamGegevens a owl:Class, [ a owl:Restriction; owl:onProperty edex:naam; owl:minCardinality 1]. #Zie EDEX 7 Leerling gegevens edex:naam a owl:DataProperty; rdfs:domain edex:NaamGegeven; rdfs:range xsd:string. #EDEX 3.2.9: Leerlingen hebben ook een geslacht te specificeren als in de GBA #zie EDEX 6.3 Geslacht: #Indien geslacht niet gevoerd wordt, niet specificeren #Indien bekend is dat het geslacht niet meer kan worden #achterhaald edex:onbekendGeslacht edex:Geslacht owl:oneOf (edex:jongen edex:meisje edex:onbekendGeslacht). edex:geslacht a owl:FunctionalProperty; rdfs:domain edex:Persoon; rdfs:range edex:Geslacht. #EDEX 3.2.11 : en leerlingen hebben een land van herkomst. #Het is niet praktisch alle landen van de wereld te enumereren en #bovendien komen er zo nu en dan nieuwe bij.ISO zou dat wel kunnen #doen maar gebruikt gewoon een twee of drie letter string. Wij dus ook maar. edex:landVanHerkomstCode a owl:DataProperty; rdfs:domain edex:Persoon; rdfs:comment "CountryCode according to ISO 3136-1"; rdfs:range xsd:string. #EDEX 3.2.12 #range van leerlingkey kan van alles zijn. # Best Practice is om onderwijsnummer te gebruiken. # Zie ook EDEX 6.3 Leerlingkey edex:leerlingKey a owl:DataProperty; rdfs:domain edex:Leerling; rdfs:range xsd:string.


Bijlage B | 2/2

Integrate #Het onderwijsnummer kan helemaal niet van alles zijn, één Burger Service #Nummer, één persoon, geef dit aan met InverseFunctionalProperty. edex:onderwijsNummer a owl:DataProperty, owl:InverseFunctionalProperty; rdfs:comment "In de praktijk is dit getal het zelfde als het burger service nummer"; rdfs:subPropertyOf edex:LeerlingKey; rdfs:domain edex:Leerling; rdfs:range xsd:string. #cardinal ??? #Edex 3.3.1 edex:School a owl:Class. #Niet in de Edex als term, maar dit is waar het om gaat. #Een leertraject is een onafgebroken periode die een leerling #een school heeft doorgebracht. Per leertracject kan er maar een leerling en #een school betrokken zijn, met een in en uitstroom datum. #definities van properties zijn weggelaten edex:LeerTraject a owl:Class; rdfs:subClassOf [a owl:Restriction; owl:onProperty edex:bezochteSchool; owl:maxCardinality 1], [a owl:Restriction; owl:OnProperty edex:isSchoolTrajectVan; owl:maxCardinality 1], [a owl:Restriction; owl:onProperty edex:instroomDatum; owl:maxCardinality 1], [a owl:Restriction; owl:onProperty edex:uitstroomDatum; owl:maxCardinality 1]. #Één Voorbeeld van een Leerling #Natuurlijk hoort die niet in de Norm thuis maar in een aparte database ex:alice a edex:Leerling; edex:naamgegeven [ edex:naam “Alice Bobdotta”;]; edex:geslacht edex:meisje; edex:landVanHerkomst “se”; edex:onderwijsNummer “12345678”. ex:sweded a edex:School. ex:aliceLO a edex:LeerTraject; edex:isLeerTrajectVan ex:alice; edex:bezochteSchool ex:sweded; edex:instroomDatum “01-09-2000”^^xsd:date; edex:uitstroomDatum “31-05-2006”^^xsd:date.


Bijlage C | 1/2

Integrate

C

Uitwerking processen SETU case Binnen de uitzendbranche wordt door de SETU (Stichting Elektronische Transacties Uitzendbranche) gewerkt aan standaarden voor het uitwisselen van informatie. Hierbij wordt het complete uitzendproces van aanvraag tot facturering afgedekt met standaarden. Deze standaarden zijn ontwikkeld aan de hand van semantische modellen, tevens is er door de SETU een beheersorganisatie opgezet om de modellen en standaarden te beheren. In deze appendix wordt de SETU als case gebruikt om te bekijken of het proces van ontwikkelen van de standaarden verloopt zoals het ontwikkelproces geschetst is in paragraaf 5.1. Hiernaast wordt de SETU case ook gebruikt om te kijken of de beheerprocessen die onderscheiden zijn in paragraaf 5.3 volledig afgedekt zijn binnen de SETU, hiervoor maken we gebruik van de checklist uit paragraaf 5.3.4. Als laatste wordt er ook gekeken welke tooling binnen de SETU gebruikt wordt voor de ontwikkeling van de standaarden. Ontwikkelproces: Binnen de SETU wordt het stappenplan zoals beschreven in paragraaf 5.1 bijna volledig gevolgd. Bij de SETU wordt niet voor iedere standaard opnieuw bekeken wat de stakeholders zijn bij de standaard. De scope van de standaard wordt wel voor iedere standaard opnieuw vastgelegd, ook om ervoor te zorgen dat de SETU standaarden onderling niet overlappen. Binnen de conceptualisatie fase werkt de SETU met werkgroepen waarin de participanten van de SETU vertegenwoordigd zijn. Hierbij wordt bepaald hoe de specificaties zoals ze opgesteld zijn in de eerste fase opgenomen dienen te worden binnen de standaarden. Binnen de SETU wordt er voor het vastleggen van de modellen in alle standaarden gebruik gemaakt van object gebeurtenis modellen. Indien nodig worden er extra onderdelen toegevoegd aan de tussenresultaten om te komen tot een volledige standaard. Nadat is vastgelegd hoe de standaard eruit moet zien en wat er opgenomen moet zijn in de standaard wordt dit vastgelegd in object gebeurtenis modellen. In deze fase wordt bij de SETU de modellen ook vertaald/gemapt naar XML-standaarden zodat de gegevens uitgewisseld kunnen worden tussen de uitzendpartijen. Indien een standaard opgeleverd wordt, worden er reviews uitgevoerd om de kwaliteit van de standaard te verhogen en om te beoordelen of de standaard voldoet aan de opgestelde specificaties. De standaard wordt vervolgens in beheer genomen door de SETU, waarna er door middel van een maintenance request proces nieuwe zaken aangevraagd kunnen worden, of fouten gemeld kunnen worden. Indien nodig start hierna het proces opnieuw, om te komen tot een nieuwe versie van de standaarden. De tools die worden gebruikt binnen de ontwikkeling van de SETU standaarden zijn MagicDraw voor het opstellen van de object gebeurtenis modellen en Altova XMLSpy voor het opstellen van de XML schema’s van de berichten.


Bijlage C | 2/2

Integrate

Checklist: Functioneel beheer Inrichten helpdesk Beschrijving: Binnen de SETU is een helpdesk ingericht waar gebruikers van de standaarden terecht kunnen met vragen of het gebruik, maar ook met vragen over nieuwe functionaliteit. Verzamelen aanvragen nieuwe functionaliteit Beschrijving: Voor het verzamelen van vragen om nieuwe functionaliteit en voor het bijhouden van de status van deze verzoeken is er binnen de SETU website en maintenance request gedeelte ingericht waar gebruikers verzoeken om nieuwe functionaliteit en gevonden fouten in de modellen kunnen indienen. Modelbeheer Uitvoeren plannen voor nieuwe versies modellen Beschrijving: Op het moment dat er besloten is welke nieuwe functionaliteit wordt toegevoegd aan de standaard wordt met behulp van werkgroepen uitgewerkt hoe de wijzigingen eruit moeten zien en worden deze wijzigingen verwerkt in de modellen. Beheren van de life-cycle van de modellen Beschrijving: Binnen de SETU is vastgelegd hoe er om wordt gegaan met nieuwe versies van de modellen en, hoe deze gereviewed en gepubliceerd worden. Verder is er vastgelegd dat er per jaar niet meer dan één nieuwe hoofdversie van de modellen uitkomt. Verder worden er waar nodig nieuwe tussenrelease uitgebracht welke in principe backwards compatible zijn. Oplossen fouten in modellen Beschrijving: Fouten in de modellen kunnen gemeld worden via de maintenance request pagina op de website van de SETU, als ze grote problemen opleveren worden ze direct opgepakt, anders worden ze meegenomen in de eerstvolgende release van de standaarden. Technisch beheer Beschikbaarheid modellen Beschrijving: De modellen van de standaarden worden opgenomen in de documentatie welke beschikbaar is op de website (na eenmalige kostenloze registratie)

Catalogus van instrumenten voor semantische interoperabiliteit Deliverable D3

Recommend Documents