Analisten zien we als medewerkers die instaan voor de vertaling van business vereisten naar toepassingen en applicaties. Op die manier staan ze veelal in contact met inhoudelijke domeinexperten en ontwikkelaars. We bekijken twee cases waarbij we de rol en taken van de analist aan bod laten komen. Case 1 beschrijft de situatie waarin een nieuwe applicatie ontwikkeld wordt. Case 2 betreft de opdracht waarbij gegevensuitwisseling mogelijk gemaakt moet worden met een bestaande applicatie. Voor beide cases wordt hergebruik van authentieke bronnen aanbevolen indien mogelijk, gezien je dan onmiddellijk OSLO compliant bent.

Case 1: Nieuwe applicatie

Om een nieuwe applicatie te ontwikkelen waarbij de verwerkte informatie in lijn ligt met OSLO, kunnen volgende stappen gevolgd worden.

Stap 1: Domeinmodel afstemmen met OSLO

Stap 1.1: Ontwikkel een eerste domeinmodel

Identificeer de OSLO objecten waarmee de te ontwikkelen applicatie in aanraking komt. Hiervoor is een eerste domeinmodel voor de applicatie nodig, op basis van functionele behoeften en concrete use cases en met een focus op de top-level objecten en relaties. Van zodra deze geïdentificeerd zijn, kan per object een traject opgestart worden waarbij de OSLO termen en definities vergeleken worden met de informatienoden.

Een overzicht van de OSLO objecten kan hier gevonden worden.


Voorbeeld: OSLO objecten aangeraakt door Mijn Burgerprofiel

Het project “Mijn Burgerprofiel” ontsluit persoonlijke gegevens voor burgers, over de besturen heen. Deze persoonlijke gegevens hebben betrekking op onder meer persoonsgegevens (naam, geboortedatum, adres, eigendom,...) en mijn lopende zaken bij de overheid (bv. aanvraag voor studietoelage). Een analyse van de informatiebehoeften maakte snel duidelijk dat er een groot raakvlak is tussen de informatie objecten waar Mijn Burgerprofiel mee aan de slag gaat en de entiteiten waarvoor OSLO een vocabularium aanreikt, namelijk: persoon, organisatie, dienstverlening, adres en gebouw.


Mijn Burgerprofiel functioneel domein OLSO object
“U en Uw Gezin” Persoon, Adres
“Lopende Zaken” Dienstverlening, Organisatie
“Uw vastgoed” Gebouw, Adres

Stap 1.2: Maak je vertrouwd met de elementen in OSLO

De vocabularia en in het bijzonder de applicatieprofielen geven een overzicht van de verschillende klassen en eigenschappen, hun definities en hoe deze te gebruiken zijn aan de hand van voorbeelden.

> Een overzicht van de vocabularia en applicatieprofielen kan hier gevonden worden.


Stap 1.3: Overlap en verschillen tussen OSLO en domeinmodel bepalen en wegwerken

Bekijk hoe het domeinmodel van de te ontwikkelen applicatie zich verhoudt tot het OSLO semantisch model.

Om hierbij te helpen kan gebruik gemaakt worden van het Simple Knowledge Organisation System (SKOS). SKOS biedt een set van relaties aan om de graad waarin twee termen semantisch equivalent zijn aan te duiden:


  • Close match: twee termen zijn voldoende gelijkwaardig opdat ze uitwisselbaar zijn. Een close match is echter niet transitief.
  • Exact match: twee termijn zijn nog meer gelijkwaardig dan bij close match en er bestaat een transitief verband.
  • Related match: de termen zijn gerelateerd maar er is geen hiërarchisch verband.
  • Broad match: twee termen zijn gerelateerd maar de ene term is meer generiek dan de andere. Bv. zoogdieren skos:broader dieren. “Broader” dient in feite gelezen te worden als “heeft breder concept”.
  • Narrow match: inverse van ‘broad match’, bv. dieren skos:narrower zoogdieren.

    • Onderstaande figuur geeft de relaties grafisch weer:

      Daarnaast is het mogelijk dat er geen overeenkomstige term bestaat in OSLO. In dit geval is het mogelijk om het OSLO semantisch model uit te breiden door middel van een extensie (zie de volgende stap). De resulterende mapping tabel wordt besproken in de werkgroep.


Stap 1.4: Zoek een oplossing voor niet-gemapte termen

Het is mogelijk dat niet voor elke term uit het eigen domeinmodel een equivalente term gevonden wordt in OSLO. In dit geval dient eerst een afweging gemaakt te worden of de term zal gebruikt worden bij gegevensuitwisseling of dat deze een louter applicatiespecifieke rol vervult, zoals bijvoorbeeld een interne, technische statuscode die niet thuishoort in het domeinmodel. Indien de term relevant is voor gegevensuitwisseling en er geen overeenkomstige term in OSLO gevonden is, kan gekeken worden naar:


  • De mogelijkheid om het eigen domeinmodel aan te passen in lijn met bestaande OSLO termen en definities;
  • Internationale standaarden en vocabularia. Voorbeelden hiervan zijn W3C Recommendations in het domein van Semantic Web en de inventaris van vocabularia Linked Open Vocabularies;
  • Wetgeving en andere officiële documenten op Vlaams, Belgisch en Europees niveau;
  • Modellen die reeds door andere publieke administraties in gebruik zijn in Vlaanderen, België of Europa. Een voorbeeld zijn de INSPIRE datamodellen.

    • Wanneer is een term geschikt voor hergebruik en kan dit op een semantisch correcte manier gebeuren? Om dit te controleren kan je volgende checklist afgaan:


      • Komt de definitie overeen met mijn eigen definitie voor deze term?
      • Heeft de term een bepaalde ‘domain’ (domein) restrictie? Deze geeft aan in welk domein een bepaald attribuut mag gebruikt worden. Zo ja, komt dit overeen met mijn domeinmodel?
      • Heeft de term een bepaalde ‘range’ (bereik) restrictie? Deze geeft aan welke aard de waarden van dit attribuut verwacht worden te hebben. Zo ja, komt dit overeen met de waarden die ik verwacht voor mijn term? Bv. een datum, een string, een waarde uit een bepaalde codelijst.

        • Indien uit deze vragen blijkt dat met deze term in definitie en gebruik overeenkomt met die uit het eigen domeinmodel zijn deze semantisch equivalent. Het label en de definitie kunnen vertaald worden naar het Nederlands voor hergebruik. In het geval geen herbruikbare term gevonden werd is het belangrijk zelf een label en definitie te documenteren voor uitwisseling met derden.


          Voorbeeld: zoeken naar een term via de Linked Open Vocabularies website

          In je domeinmodel voor een nieuwe, nog te ontwikkelen applicatie heb je een attribuut ‘medium’ voorzien om informatie bij te houden over de manier waarop informatie tot bij de burger raakt. Bovendien is dit attribuut relevant om uit te wisselen met andere agentschappen of bouwstenen van Informatie Vlaanderen, maar is er geen overeenkomstige term te vinden binnen OSLO. In dit geval kun je op zoek gaan naar te hergebruiken termen uit andere standaarden en vocabularia:


          • Zoek op de Linked Open Vocabularies website naar de term ‘medium’.
          • Het eerste resultaat is een attribuut ‘medium’ uit het Dublin Core Terms (dcterms) vocabularium. Klik op de URI om meer informatie over deze term te vinden.
          • Evalueer de definitie van deze term: “The material or physical carrier of the resource.”
          • Evalueer het domein van de term: ‘http://purl.org/dc/terms/PhysicalResource’, met als definitie “A material thing”. Is de klasse of entiteit waarop ik dit attribuut ga toepassen equivalent met ‘PhysicalResource’?
          • Evalueer het bereik van de term: ‘http://purl.org/dc/terms/PhysicalMedium’, met als definitie: “A physical material or carrier. Examples include paper, canvas, or DVD.” Komen de waarden die ik verwacht voor dit attribuut overeen met de definitie en voorbeelden van ‘PhysicalMedium’?
          • Is voorgaande informatie consistent met het begrip ‘medium’ dat je wil bijhouden? Zo ja, vertaal de labels en definitie naar het Nederlands en bewaar de bron in je documentatie aan de hand van de URI voor de hergebruikte term (zie stap 2). Zo niet, herhaal de zoektocht of documenteer een eigen label en definitie voor de term binnen jouw domeinmodel.

Stap 2: Hoe ga ik van een domeinmodel naar een informatiemodel?

Het aanmaken van een informatiemodel laat ons toe bijkomende restricties te introduceren in het model. Een informatiemodel vormt een dataspecificatie voor de toepassing op een conceptueel niveau, maar blijft implementatie onafhankelijk door geen specifieke protocollen op te leggen. Een informatiemodel kan dienen als vertrekpunt voor ontwikkelaars en is de basis voor het datamodel.


Suggestie: OSLO en informatiemodellen

Ook OSLO biedt enkele informatiemodellen aan in de vorm van applicatieprofielen. Een applicatieprofiel is een generiek informatiemodel dat toepasbaar is op één of meerdere use cases in een bepaald domein. Het is niet ontwikkeld voor een specifieke toepassing, maar om breed inzetbaar te zijn overheen toepassingen die binnen de gespecificeerde use cases vallen.


Een voorbeeld van een OSLO applicatieprofiel is dit voor het creëren van een dienstencatalogus. In dit geval dient het applicatieprofiel als documentatie en vertrekpunt voor analisten en ontwikkelaars die een dienstencatalogus willen ontwikkelen. Zij kunnen er tevens voor kiezen deze applicatieprofielen uit te breiden met domein-specifieke elementen zoals het toevoegen van (sub)klassen en attributen of het verstrengen van de multipliciteit van een eigenschap. Een voorbeeld van een domein-specifieke uitbreiding is de implementatie van een dienstencatalogus specifiek voor toeristische dienstverlening, waarbij extra attributen kunnen gespecificeerd worden bovenop het bestaande applicatieprofiel voor publieke dienstverlening. Indien jouw informatiemodel of uitbreiding toepasbaar is in een bredere context, kan deze worden voorgelegd aan het OSLO team en opgenomen worden als onderdeel van de OSLO standaard.


Bijkomende restricties die in een informatiemodel kunnen worden vastgelegd:
  • Verfijning van de terminologie (definitie van klassen en eigenschappen) consistent met de semantiek uit de betreffende vocabularia maar met een welbepaald gebruik als doel;
    Voorbeeld: verfijnen van terminologie voor het domein Melding.

    Definitie ‘rol’ in de context van de klasse ‘Participatie’:

    • OSLO Dienst Vocabularium: “De rol die de deelnemer ad Publieke Organisatie speelt”.
    • Applicatieprofiel ‘Profiel’: “De rol die een participerend Agent heeft met betrekking tot de Melding.”
  • Het bepalen van de multipliciteit van eigenschappen;
    Voorbeeld: vastleggen van de multipliciteit voor eigenschappen van een persoon.

    In het applicatieprofiel ‘Persoon Basis’ komen volgende multipliciteiten voor:

    • Eigenschap ‘voornaam’: 1..*, deze eigenschap komt minimaal één keer voor maar kan ook meerdere keren voorkomen met verschillende waarden (een persoon kan meerdere voornamen hebben).
    • Eigenschap ‘achternaam’: 1..1, deze eigenschap komt minimaal en maximaal één keer voor (een persoon bezit telkens exact één achternaam).
    • Eigenschap ‘patroniem’: 0..1, deze eigenschap komt niet of maximaal één keer voor.
    • Eigenschap ‘heeftVerblijfplaats’: 0..*, een persoon kan geen of meerdere verblijfplaatsen hebben.
  • Externe terminologie (klassen en eigenschappen) gebruikt voor nieuwe/extra termen die niet in de bestaande vocabularia voorkomen;
    Voorbeeld: OSLO Persoon uitbreiden met externe terminologie voor het domein Profiel.

    Als basis voor het informatiemodel (en bijgevolg ook applicatieprofiel) van het domein Profiel werd het OSLO Persoon vocabularium genomen, aangezien Profiel het beschrijven van personen als doel heeft. Echter, om de specificiteit van een Profiel te capteren werd het OSLO Persoon vocabularium uitgebreid met termen van het wijdverspreide Friend Of A Friend (FOAF) vocabularium. Daarnaast kunnen ook zelf-gedefinieerde termen worden toegevoegd voor domeinspecifieke informatie.

  • Het gebruik van codelijsten en taxonomieën.
    Voorbeeld: vastleggen van codelijsten in de dienstencatalogus.

    Een codelijst is een lijst van gepredefinieerde termen voor het organiseren van informatie. Een taxonomie laat toe informatie verder te classificeren door hiërarchische verbanden tussen termen toe te voegen. In het applicatieprofiel ‘Dienstencataloog’ werd voor de eigenschap ‘taal’ de Langauge Named Authority List van het Publications Office van de Europese Commissie als te gebruiken codelijst vastgelegd. Dit betekent dat voor de invulling van het attribuut ‘taal’, enkel waarden mogen gebruikt worden die voorkomen in de Language Named Authority List, bijvoorbeeld ‘nl’ voor Nederlands.


Suggestie: informatiemodellen en applicatieprofielen genereren en delen.

  • Gebruik de OSLO tools EA-to-RDF en SpecificationGenerator om een HTML versie van het applicatieprofiel te genereren, vertrekkende van een Enterprise Architect bestand met het informatiemodel in UML notatie. Gebruik de tags zoals gedocumenteerd in EA-to-RDF.
  • Voeg voorbeelden toe aan de applicatieprofielen in JSON-LD om te illustreren hoe het informatiemodel in praktijk gebruikt wordt.
  • Maak een pull-request op de OSLO GitHub repository met de html versie van het applicatieprofiel.

Ook al is het niet de bedoeling om een nieuw applicatieprofiel aan te maken, maar een informatiemodel te maken voor jouw toepassing of een bestaand applicatieprofiel uit te breiden met domeinspecifieke informatie kan het nuttig zijn om bovenstaande tools te gebruiken om het informatiemodel te documenteren.

Case 2: Bestaande applicatie

Deze case beschrijft de te ondernemen stappen in een situatie waarbij een reeds bestaande applicatie gebruik moet maken van de OSLO standaard. Dit betekent dat een mapping gemaakt moet worden met OSLO vanuit een bestaande applicatie. De mapping is dan een laag boven de applicatie en de werkwijze is verder heel gelijkaardig als Case 1. We verduidelijken in volgende stappen:


  • Stap 1: Maak je vertrouwd met de elementen in OSLO.
  • Stap 2: Bepaal de overlap en verschillen tussen de informatiemodellen en werk ze weg.
  • Stap 3: Zoek een oplossing voor niet-gemapte termen.
  • Stap 4: Afkloppen van een finale mapping. Indien gewenst kan afstemming gezocht worden met een werkgroep binnen het Vlaams Stuurorgaan.