Handleiding OTL | IMBOR-LD

Deze Respec pagina bevat een handleiding die beschrijft hoe er op basis van IMBOR-LD een eigen ontologie gemaakt kan worden ten behoeve van uitwisseling tussen opdrachtnemer en opdrachtgever. De originele vraag komt voor uit het BIM Pro programma van de Provincies. Men wil een 'OTL' (ObjectTypeLibrary) kunnen samenstellen die aan de opdrachtgever gegeven kan worden, die deze vervolgens 'invult' en teruglevert. Waarop de Provincie de gegevens kan valideren en inlezen in hun systemen. Het doel (en daarmee de scope) van deze handleiding is dat hiermee een Provincie in staat moet zijn om een 'OTL' op te zetten in een spreadsheet (conventioneel) of LinkedData (duurzaam) formaat. Deze documentatie is onderdeel van IMBOR2020-08. In IMBOR2022 gelden andere regels en vertalingen. Echter, de stappen die gezet worden in deze handleiding zijn zodanig generiek dat ze ook van toepassing zijn op IMBOR-LD 2022

# Stap 1: Kies het juiste gebruik Er zijn een aantal manieren te bedenken om een OTL te gaan gebruiken als organisatie. Een OTL wordt doorgaans voor datzelfde doel ontwikkelt. Vandaar dat het goed is om van te voren na te denken welk doel de OTL gaat dienen. Drie van de meeste belangrijkste en meest gebruikte 'use cases' zijn: 1. Een gezamenlijke taal spreken tussen partij A en B; 1. Een gezamenlijke '[vormenstoof][5]' afspreken tussen opdrachtnemer en opdrachtgever; 1. Een datamodel introduceren voor een bepaalde applicatie of een bepaald applicatielandschap. ## Een 'gezamenlijke taal' Wanneer we spreken over een OTL die als gezamenlijke taal dient tussen twee partijen hebben we het eigenlijk over een vocabulaire. Deze wordt vaak in rudimentaire vorm (bijvoorbeeld begrippenlijst) wel in een projectplan gestopt, maar er wordt vaak niet meer naar gekeken. Door deze vocabulaire een status te geven en bijvoorbeeld centraal beschikbaar te stellen kan hiernaar verwezen worden. Deze is echter alleen geschikt voor menselijke interpretatie. Vaak bevat het ook niet meer dan een term, definitie, toelichting en synoniemen. ## Een 'vormenstoof' De vormenstoof OTL (a.k.a. informatiebehoefte specificatie)is de meeste bekende en daarmee ook meest toegepaste. Het doel is het expliciet specificeren van de informatiebehoefte van een organisatie. Het gaat hier eigenlijk om een beschrijving van de werkelijkheid (model) waarin we betekenis geven aan de concepten die in een specifiek domein worden gebruikt, inclusief hun onderlinge samenhang. We noemen dit ook wel een ontologie of soms informatiemodel. Een opdrachtgever specificeert zijn informatiebehoefte door te beschrijven welke concepten hij erkent (vaak objecttypen), welke informatie hij er bij wilt vastleggen (vaak eigenschappen) en hoe deze concepten zich onderling verhouden (vaak in een taxonomie en/of meronomie). Soms gaat het zelfs om eisen, functies en verificaties. Vervolgens wordt deze OTL overgedragen aan een opdrachtnemer en deze kan vervolgens instanties (werkelijke individuele objecten) aanmaken volgens de opgelegde vormenstoof. De data wordt vervolgens teruggelevert en de opdrachtgever kan controleren (door te kijken of alles gaat door de vormenstoof) of alles past in zijn systemen. ## Een 'datamodel' Een laatste toepassing van een OTL is het gebruiken als datamodel. Hierbij wordt er vanuit gegaan dat de applicatie waarin de daadwerkelijke objectdata wordt opgeslagen de data opslaat conform de OTL. Dit betreft dan vaak een custom-made applicatie die met name geschikt is voor de OTL van één organisatie. ## IMBOR-LD gebruik Bij de ontwikkeling van IMBOR-LD is met name rekening gehouden met het gebruik als vormenstoof. Dit is waarom de SHACL shapes keuze gemaakt is. Het gebruik als gezamenlijke taal is ook goed mogelijk hiervoor is de 'objecttypen' graph binnen IMBOR-LD voldoende. Op termijn zal vanuit de algemene IMBOR ontwikkelingen een vocabulaire gereleased worden in SKOS, specifiek voor dit doeleinde. De laatste (datamodel) manier is mogelijk, maar wordt afgeraden. De wens van de meeste Provincies was met name het vormenstoof model. Hiermee is de gezamenlijke taal ook makkelijk mogelijk. De rest van de handleiding gaat dan ook uit van het gebruik van een OTL als vormenstoof (informatie specificatie).

# Stap 3: Begin een OTL Op dit moment is het nog onduidelijk hoe een OTL gebruikt gaat worden binnen een Provincie, er zijn wel scenario’s te onderscheiden: a. Een provincie (of aantal provincies) gebruikt IMBOR-LD als (één van de onderdelen van) hun OTL; a. Een provincie maakt een geheel eigen OTL. We gaan in deze handleiding uit van scenario 1. Maar de handleiding is ook grotendeels te gebruiken in scenario 2. ## Scenario We gaan er hier vanuit dat de provincie in de rol van opdrachtgever (OG) een OTL wil opstellen voor gebruik in een project. Binnen dit project moeten areaalgegevens geleverd worden aan de opdrachtnemer (ON). Vervolgens gaat de ON aanpassingen doen aan de assets en moeten gegevens weer teruggeleverd worden aan de OG. Deze gaat de gegevens valideren zodat deze later weer in het areaalbeheerpakket gelezen kunnen worden. Binnen dit scenario onderscheiden we dus de volgende stappen: 1. Ik wil als OG een OTL opstellen om mijn informatiebehoefte per asset duidelijk te maken aan de ON; 1. Ik wil als OG een de bestaande situatie in areaaldata leveren, volgens de OTL, zodat de ON over de juiste gegevens beschikt; 1. Ik wil als OG de gereviseerde situatie terug krijgen op dezelfde manier als ik mijn data aanleverde, zodat ik deze tegen de OTL kan valideren. De focus van deze handleiding is stap 1, maar aan de andere twee stappen wordt ook aandacht besteed. In [stap 2](#stap-2-kies-de-juiste-techniek) is de gewenste techniek gekozen. Ga daarom verder naar de juist sectie: * [OTL in LinkedData](#otl-in-linkeddata) * [OTL in Spreadsheet](#otl-in-spreadsheet) ## OTL in Spreadsheet Er bestaan drie spreadsheets binnen IMBOR-LD. * **IMBOR_Spreadsheet_A_ObjectTypen-Eigenschappen**: De spreadsheet met alle objecttypen en bijbehorende eigenschappen; * **IMBOR_Spreadsheet_B_Eigenschappen**: De spreadsheat met alle eigenschappen en bijhorende eenheden, grootheden of verwijzingen naar waardelijsten; * **IMBOR_Spreadsheet_C_Vastewaardelijsten**: De spreadsheet met de vastewaardenlijsten en uiteraard de waardes.

Gebruik van CSV bestanden in Excel

IMBOR-LD is in het openstandaard CSV spreadsheet formaat beschikbaar. Omdat dit in essentie een tekst bestand is, is er een extra stap nodig om dit in bijvoorbeeld Microsoft Excel netjes te krijgen. De minimale stappen hiervoor worden door de VNG goed omschreven op deze website: CSV in Excel

### Inhoud spreadsheet In de spreadsheets staan verschillende kolommen. Hieronder een uitleg per kolom. De schuin gedrukte representeren de koppelvlakken tussen respectievelijk A & B en B & C. | Spreadsheet | Kolom | Uitleg | |------------- |-------------------------- |--------------------------------------------------------------------- | | A | FysiekObjectURI | Unieke identifier van het ObjectType | | | FysiekObjectLabel | Naam van het ObjectType | | | _EigenschapURI_ | Unieke identifier van de eigenschap | | | EigenschapLabel | Naam van de eigenschap | | | EigenschapVanObjectLabel | Naam het ObjectType waar de eigenschap van overgeërfd is | | | Versie | Versie van IMBOR waar de regel komt | | B | _EigenschapURI_ | Unieke identifier van de eigenschap | | | EigenschapLabel | Naam van de eigenschap | | | _VastewaardeLijstURI_ | Unieke identifier van de corresponderende vastewaardelijst (i.v.t.) | | | VastewaardelijstLabel | Naam van corresponderende vastewaardelijst (i.v.t.) | | | Datatype | Hoe de eigenschap waardemoet worden genoteerd (i.v.t.) | | | Eenheid | In welke maat de eigenschap waarde moet worden genoteerd (i.v.t.) | | | Grootheid | Welke betekenis de waarde van de eenheid heeft (i.v.t.) | | | MaximaalAantalVoorkomen | Hoe vaak de eigenschap mag voorkomen per ObjectType | | | Versie | Versie van IMBOR waar de regel uit komt | | C | _VastewaardeLijstURI_ | Unieke identifier van de corresponderende vastewaardelijst | | | VastewaardelijstLabel | Naam van corresponderende vastewaardelijst | | | VastewaardeURI | Unieke identifier van de waarde in de waardelijst | | | VastewaardeLabel | Naam van de waarde in de waardelijst | | | Versie | Versie van IMBOR waar de regel uit komt | ### Objecten in scope Er wordt begonnen met het selecteren van de juiste ObjectTypen in spreadsheet A. Niet allen zullen van belang zijn in een organisatie of binnen een project. Degene die niet van belang zijn, kunnen middels het verwijderen van de juiste rijen (op basis van de 2e kolom) er uit gehaald worden. Wanneer er een ObjectType niet in IMBOR staat kan er uiteraard een toevoeging worden gemaakt met dezelfde opzet met een 'nieuw' objecttype. In dit geval is het aan te raden om de regels van ongeveer een zelfde ding te pakken, deze onderaan te plakken en deze te modificeren waar nodig. De kolommen met 'URI' er in moeten vervolgens uniek gemaakt worden. Best practice zou zijn: ```="organisatie afkorting"&"-"&"type"&"volgnummer"```. Bijvoorbeeld: pnh-ot-001. IMBOR is ontworpen om volledig dekkend te zijn, wanneer er afgeweken wordt kan dit uiteraard een goede reden hebben. Maar realiseer wel dat het hiermee minder 'standaard' wordt en daarmee meer maatwerk voor de opdrachtnemer. ### Informatiebehoefte als eigenschappen Als de spreadsheet met alle relevante objecttypen klaar is, is het zaak om te bekijken of de informatiebehoefte van de organisatie gedekt wordt binnen de eigenschappen die in de spreadsheet B staan. Het wordt aangeraden om in deze spreadsheet een extra kolom aan te maken: ```"VERPLICHT"``` per rij kan dan ingevoerd worden of deze attribuut bij het objecttype persé aangeleverd moet worden (met "JA") of niet (met "NEE"). Mochten er organisatiespecifieke eigenschappen zijn, dan kunnen deze toegevoegd worden. De kolommen met 'URI' er in moeten vervolgens uniek gemaakt worden. Best practice zou zijn: ```="organisatie afkorting"&"-"&"type"&"volgnummer"```. Bijvoorbeeld: pnh-es-001. Ook hier geldt dezelfde opmerking over 'minder standaard' als hiervoor. Verder, geldt bij het toevoegen van eigenschappen dat er ook rekening gehouden moet worden met het feit dat de andere kolommen en wellicht ook vastewaardenlijst spreadheet moeten worden aangepast. In de eigenschappen spreadsheet moeten de nieuwe eigenschappen beschreven worden met de juiste metadata (eenheden, grootheden, etc.) en wanneer de nieuwe eigenschappen vastewaardenlijsten hebben, zullen deze opgegeven moeten worden in de spreadsheet C. _Uiteraard is het belangrijke om middels de URI kolommen een koppelvlak te realiseren tussen de spreadsheets._ ## OTL in LinkedData Zoals in [stap 2](#stap-2-kies-de-juiste-techniek) aangegeven worden er meerdere manieren van LinkedData gebruik ondersteund. In deze handleiding beschrijven we de 'document gebaseerde' vorm op basis van een TTL file. Exact dezelfde graaf is beschikbaar via het CROW LinkedData platform. Het voordeel van het direct bevragen van een endpoint is dat de data altijd up-to-date is en dat er optimaal gebruik gemaakt wordt van de _Linked_Data technieken. Middels de webapplicatie zijn dezelfde tabellen te generen als in de spreadsheets staan en kunnen links gegenereerd worden die door software als Relatics of Postman gebruikt kunnen worden. De TTL file bevat dezelfde informatie maar is 'disconnected' op het moment dat deze lokaal gebruikt wordt. Deze keuze wordt gemaakt omdat het werken met de 'live' versies qua stappen hetzelfde is, maar omdat daar andere/geavanceerdere software voor nodig is. Daarnaast is de uitwerkingen in een tekstueel bestand makkelijker te volgen voor de beginner. De TTL file van IMBOR-LD is een tekstbestand, maar met een bepaalde structurering. Voor gedetailleerde informatie hierover raadpleeg [[turtle]] documentatie. Het bevat de totale IMBOR-LD ontologie. Hierdoor is er uiteraard veel meer mogelijk dan bij de spreadsheet versie. Dit zorgt ook voor een wat uitgebreidere opgave om hiermee aan de slag te gaan. ### Inhoud LinkedData file De IMBOR-LD ontologie in begint met copyright en versie informatie. Daarna is de ontologie opgesplitst in 5 'grafen'. - ```imbor```: ObjectTypen en dus ook alle onderdelen van de taxonomie - ```imborp```: Eigenschappen (IMBOR:attributen) en hun informatie - ```imborvwl```: Vastewaardelijsten en hun mogelijk waarden - ```shape```: SHACL shapes om ObjectTypen te matchen met de eigenschappen - ```groep```: SKOS collecties voor de IMBOR hiërarchie en Vakdisciplines en versie Voor meer uitleg hierover en een visualisatie wordt verwezen naar de generieke IMBOR-LD Respec

. ### Techniek van het linken Er zijn meerdere manieren om een organisatie specifieke OTL op basis van IMBOR te maken. Wanneer IMBOR alle behoeften dekt is het alleen zaak om in IMBOR-LD te schrappen (ofwel: out-of-scope te verklaren). Wanneer er echter zaken toegevoegd moeten worden zijn de stappen niet verschillend als bij een spreadsheet, maar de uitvoering wel. Dit heeft te maken met de manier waarop twee ontologiën aan elkaar gelinkt kunnen worden. Er zijn in deze drie tactieken, met elk hun voor- en nadelen: - __Importeren__ - Importeert alle content van de IMBOR-LD ontologie in de organisatie OTL - Dit betekent dat alles wat in IMBOR-LD zit, ook in de organisatie OTL zit - _Voordelen_ - Sterkte connectie. Organisatie OTL is compleet up-to-date met IMBOR-LD - _Nadelen_ - Geen flexibiliteit. Alles wordt geïmporteerd; - Geen controle. Als iets wijzigt in IMBOR-LD dan wijzigt dit ook in de organisatie OTL - Ongewenste gevolgtrekkingen. Wanneer we meer aan elkaar linken, is de kans op 'geinfereerde kennis' groter. Dit is misschien onwenselijk - __Refereren__ - Concepten uit IMBOR-LD worden gerefereerd. Dit betekent dat wanneer kennis uit IMBOR-LD nodig is, deze op dat moment 'opgehaald' wordt - Dit betekent dat het twee aparte ontologiën zijn die op zichzelf kunnen bestaan. Maar dat erbij het gebruik van de totale set een live bevraging nodig is van de gehele kennis graaf - _Voordelen_ - Simpele, maar sterkte connectie met IMBOR-LD, middels SPARQL - Overzichtelijke OTL - _Nadelen_ - Er kan lastig naar diepere delen van IMBOR-LD gerefereerd worden - __Kopiëren__ - Handmatig kopieren van IMBOR-LD concepten in de organisatie OTL - Dit betekent dat alleen de gewenste delen overgehaald worden - _Voordelen_ - Volledige flexibiliteit en controle - Alleen de benodigde zaken van IMBOR-LD worden gebruikt - _Nadelen_ - Inferenties vanuit IMBOR-LD werken misschien niet - Handmatige menselijke fouten - Disconnected van IMBOR-LD Deze opsomming is geïnspireerd door een stuk dat geschreven is door Miltos Gatzios van BIM-Connected. Er wordt naar hem verwezen voor meer informatie en een up-to-date versie, inclusief gedetailleerde pro en cons tabel. ### Betekenis van de links Wanneer er gekozen is voor de optimale techniek van het linken is er nog een belangrijke keuze te maken. Het gaat hier om de semantiek van de link. Hier kan worden aangegeven hoe sterk de verschillende ontologieën aan elkaar gerelateerd zijn en op welke manier. Er zijn heel erg veel manieren om dit te doen. Er worden er hier drie beschreven en vervolgens wordt de meest logische voor het gekozen scenario uitgewerkt. 1. Het linken van ontologieën door in de Organisatie OTL 'verder te specificeren' middels ```rdfs:subClassOf```. 2. Het linken van ontologieën door in de Organisatie OTL eigen objecttypen te maken en deze dezelfde te verklaren tussen de verschillende ontologieën, d.m.v. ```owl:equivalentClass```. 3. Het linken van ontologieën door een Organisatie OTL te maken met die objecttypen en eigenschappen die niet in de andere ontologie voorkomen en dan een SHACL graph maken die precies ‘definieert’ hoe de objecttypen er uit zien door te verwijzen naar de standaard objecttypen en eigenschappen in combinatie met de Organisatie OTL objecttypen en eigenschappen. De opsomming is zo opgebouwd dat 1 makkelijker (maar met minder mogelijkheden) is dan 3. Met optie 3 kan heel precies worden aangegeven hoe een machine de link moet interpreteren en is er volledige vrijheid. Bij optie 1 wordt er vanuit gegaan dat IMBOR-LD goed is, en de Organisatie OTL er alleen maar op uitbreidt. Optie 2 zit er logischerwijs tussen in. Voor het scenario van de meeste organisatie OTL's zal optie 1 voldoende zijn. Dit gecombineerd met het importeren uit [Techniek van het linken](#techniek-van-het-linken). ### Eigen OTL configureren In [Inspiratie en referenties](#inspiratie-en-referenties) wordt in het filmpje van de eerste NTA8035 Workshop exact uitgelegd hoe men een eigen OTL zou kunnen samenstellen op basis van de NTA8035. Een OTL op basis van IMBOR-LD (met dus 'Importeren' en 'subClassOf') is nauwelijks verschillend. Het enige grote verschil is dat de IMBOR-LD ontologie (ook) geïmporteerd moet worden. Het wordt dan ook aangeraden om dat filmpje en/of de bijbehorende sheets te raadplegen. Wanneer we dit in dezelfde software willen doen (in dit geval Topquadrant's Topbraid Composer Free Edition) geeft de NEN uitstekend uitleg over hoe dit te installeren en op te zetten. Een voorbeeld casus voor een OTL op basis van IMBOR is reeds uitgewerkt op IMBOR-LD: Een eigen OTL: M1-laag aanpassen. Deze casus gebruiken we ook in dit geval. Onderstaande figuur is een uitwerking van het voorbeeld. Onder het figuur staat de uitleg.

Organisatie specifieke OTL op basis van IMBOR-LD (Groot)

Op de plaat hierboven zijn twee figuren te zien: * Een venster met Topbraid waarin de gehele configuratie van de usecase te zien is; * Een venster met Notepad++ waarin de TTL file van de Organisatie specifieke OTL te zien is. De lijnen verwijzen hoe de informatie die in Topbraid is gecreëerd is, zich vertaald naar een LinkedData file. * De rode lijnen gaan over de verschillende betrokken ontologieën * De OrganisatieOTL is de ```organisatieOTL.ttl``` file en vooralsnog beschikbaar als namespace: ```http://example.org/organisatieOTL#``` * De IMBOR-LD ontologie wordt geïmporteerd vanuit de ```imbor-ld.ttl``` en is beschikbaar als namespace: ```http://linkeddata.crow.nl/publication-v2/ns/crow/imbor/``` * De NTA8035 ontologie wordt geïmporteerd vanuit de ```NTA 8035 basicsemantics-owl.ttl``` en is beschikbaar als namespace: ```https://w3id.org/def/basicsemantics-owl``` * De groene lijnen gaan over de ```rdfs:subClassOf``` die is aangemaakt. * Er is te zien dat er een nieuwe klasse 'Carnavalskombord' is aangemaakt * En dat deze een ```rdfs:subClassOf``` is van het IMBOR object 'Bebouwde kombord' * De gele lijnen gaan over de SHACL shape die is aangemaakt om een extra eigenschap toe te voegen aan een Carnavalskombord. * Er is een nieuwe klasse aangemaakt, te weten: 'CarnavalskombordShape' * Deze is van het ```rdf:type``` SHACL NodeShape * Vervolgens is aangeven welke 'conditie' er dan op die shape wordt gezet. Hierin is o.a. te zien dat er middels ```sh:path``` verwezen wordt naar de daadwerkelijke eigenschap en dat de in te vullen waarde ```xsd:boolean``` is (te weten: true of false). * En als laatste is aangegeven op welke class/ObjectType) deze van toepassing is: 'Carnavalskombord'. Hiermee is een koppelelement gecreëerd tussen het objecttype en de eigenschap. * De blauwe lijn geeft de eigenschap aan als ```rdf:property``` * Deze eigenschap kan eventueel bij meer shapes horen, daarom is deze apart gedefinieerd Middels Topbraid is nu een TTL file gecreëerd die de aanvullende zaken beschrijft van de Organisatie specifieke OTL, t.o.v. IMBOR-LD, respectievelijk NTA8035 Basic semantics. Hiermee is een OTL gecreëerd op basis van IMBOR-LD, welke weer op basis is van de NTA8035. Met deze drie ontologieën weet een opdrachtnemer precies wat de informatiebehoefte is van de opdrachtnemer die de OTL heeft gemaakt. En dit is inclusief een woordenboek. Voor het uitwisselen van gegevens conform deze OTL wordt verwezen naar [Stap 4: Wissel informatie uit](#stap-4-wissel-informatie-uit).

# Stap 4: Wissel informatie uit Het uitwisselen van gegevens (de dataset) op basis van de gecreëerde OTL is verschillend voor de spreadsheet en de LinkedData versie. Bij de spreadsheet versie bestaat het uit het invullen van de juiste waarde (in een nieuwe kolom) in de rijen van spreadsheet A is. Dit moet handmatig worden gecontroleerd m.b.h. sheet B en C, tenzij er uiteraard iemand iets slims op bedenkt. Bij de LinkedData versie wordt een nieuwe bestand (de dataset) aangemaakt welke verwijst en conformeerd aan de ontologie die gecreëerd is door de opdrachtgever. De werkwijze in LinkedData ligt helemaal aan de software die hiervoor gebruikt wordt. In de sectie [Inspiratie en referenties](#inspiratie-en-referenties) wordt in het tweede filmpje van de NTA8035 workshop exact uitgelegd hoe dit (wederom) met Topbraid kan. ## LinkedData dataset maken Een voorbeeld casus voor een OTL op basis van IMBOR is reeds uitgewerkt op IMBOR-LD: Gebruikmaken van de eigen OTL: M0-laag. Deze casus gebruiken we ook in dit geval. Onderstaande figuur is een uitwerking van het voorbeeld. Onder het figuur staat de uitleg.

Dataset o.b.v. Organisatie specifieke OTL (Groot)

Op de plaat hierboven zijn twee figuren te zien: * Een venster met Topbraid waarin de gehele configuratie van de usecase te zien is; * Een venster met Notepad++ waarin de TTL file van de Dataset o.b.v. de Organisatie OTL te zien is. De lijnen verwijzen hoe de informatie die in Topbraid is gecreëerd is, zich vertaald naar een LinkedData file. * De rode lijnen gaan over de verschillende betrokken ontologieën * De set die de daadwerkelijke data instantie bevat is de ```dataset_organisatieOTL.ttl``` file en vooralsnog beschikbaar als namespace: ```http://example.org/dataset_organisatieOTL#``` * De OrganisatieOTL is de ```organisatieOTL.ttl``` file en vooralsnog beschikbaar als namespace: ```http://example.org/organisatieOTL#``` * De IMBOR-LD ontologie wordt geïmporteerd vanuit de ```imbor-ld.ttl``` en is beschikbaar als namespace: ```http://linkeddata.crow.nl/publication-v2/ns/crow/imbor/``` * De NTA8035 ontologie wordt geïmporteerd vanuit de ```NTA 8035 basicsemantics-owl.ttl``` en is beschikbaar als namespace: ```https://w3id.org/def/basicsemantics-owl``` * De groene lijnen gaan over de ```rdf:type``` (instantie) die is aangemaakt. * Er is te zien dat er een nieuw object 'Bord1' is * En dat deze een ```rdf:type``` is van het ObjectType 'Carnavalskombord' * De gele lijnen gaan over de verschillende eigenschappen die ingevuld zijn voor deze instantie * De eigenschap 'inclusiefVersiering' heeft de waarde 'true' * De eigenschap 'Kleur' heeft de waarde 'Oranje' uit een waardelijst * De eigenschap 'Geometrie' heeft een wktLiteral waarde die een punt op de kaart aanwijst * De blauwe lijn geeft aan dat er nog een tweede instantie van een `Carnavalskombord` is Middels Topbraid is nu een TTL file gecreëerd die instanties beschrijft o.b.v. de Organisatie specifieke OTL. Een opdrachtnemer zou deze file kunnen maken en doet dat dan precies volgens hetgeen dat de opdrachtgever aangegeven heeft. Er is nog de mogelijkheid om de files automatische te controleren. ## Dataset controleren met SHACL Wanneer een OG een dataset ontvangt van een ON is het handig om deze toch even te checken. Doordat de LinkedData file is opgezet in d.m.v. SHACL shapes is dit mogelijk. Het vereist enig technisch inzicht om dit te doen. In dit document wordt dan ook niet uitgelegd hoe dit exact te doen is. Wel is hiervoor een eerste opzet gemaakt in IMBOR-LD: Gebruikmaken van de eigen OTL: M0-laag. In het specifieke geval wanneer we de dataset controleren tegen de OrganisatieOTL is onderstaande een voorbeeld.

In onderstaande geval is bij de eigenschap 'inclusiefVersiering' niet 'true' ingevuld maar "JA". Hierop geeft de SHACL validator dus een foutmelding: "Value must be a valid literal of type boolean". ```turtle $ shaclvalidate -datafile dataset_organisatieOTL.ttl -shapesfile organisatieOTL.ttl @prefix : . @prefix imborp: . @prefix sh: . @prefix rdf: . @prefix owl: . @prefix xsd: . @prefix skos: . @prefix rdfs: . @prefix organisatieOTL: . [ a sh:ValidationReport ; sh:conforms false ; sh:result [ a sh:ValidationResult ; sh:focusNode :Bord1 ; sh:resultMessage "Value must be a valid literal of type boolean" ; sh:resultPath organisatieOTL:inclusiefVersiering ; sh:resultSeverity sh:Violation ; sh:sourceConstraintComponent sh:DatatypeConstraintComponent ; sh:sourceShape [] ; sh:value "JA" ] ] . ```

Op deze manier is te valideren of de aangeleverde set voldoet aan de opgezette OTL.

GitHub Contributors