Boek/Stap

< Boek

Ontwerp van consistente domein-ontologie - hergebruik van bestaande sector afspraken

 

Auteur

Roel Stap (Data for Use)

 

Veel organisaties in verschillende bedrijfssectoren en toepassingsgebieden zijn vandaag de dag actief in het opstellen en vastleggen van gemeenschappelijke informatieafspraken. Het doel van deze activiteiten is het vergroten van het gemeenschappelijke begrip binnen de sector of het toepassingsgebied, om daarmee de samenwerking tussen organisaties te bevorderen. Voorbeelden hiervan zijn RosettaNet voor supply chain management-, Inspire & OpenGIS voor geo- en IEC CIM voor energiemanagement. Ook in Nederland kennen we vergelijkbare initiatieven zoals SETU voor informatie-uitwisseling tussen organisaties over flexibele arbeid.

 

Met de opkomst van linked data als middel voor organisaties om informatie op een eenduidige wijze te publiceren neemt ook de ontwikkeling van ontologieën een vlucht. Veel organisaties zijn op dit moment zich aan het oriënteren welk voordeel zij van deze nieuwe aanpak hebben en hoe het aansluit bij de bestaande omgeving. Daarbij lopen veel organisaties aan tegen de vraag wat ontologieën zijn en waarom ze vaak nodig zijn om eenduidigheid binnen de sector te blijven borgen. Om aan dit bezwaar tegemoet te komen en de introductie van linked data te vergemakkelijken, zullen we in dit artikel ingaan op de mogelijkheden die er zijn om specifieke ontologieën te ontwikkelen op basis van bestaande informatiespecificaties in de sector.

 

Door gebruik te maken van bestaande afspraken en standaarden kan de acceptatie van het linked data gedachtegoed worden versneld. Op dit moment ontwikkelen en beheren domeinexperts van verschillende organisaties deze informatieafspraken, veelal georganiseerd in een formeel (gestandaardiseerd) verband. Deze afspraken zijn nu al de basis voor verschillende oplossingen die gerealiseerd worden. Door ook de ontologie ontwikkeling te baseren op deze gemeenschappelijk afspraken sluit deze aan op reeds bestaande werkwijzen en wordt de acceptatie van linked data daarmee vereenvoudigd.

 

Als voorbeeld zullen we in dit artikel een en ander uitleggen aan de hand van het IEC CIM model. Dit is een wereldwijd geaccepteerde informatiestandaard voor de energiesector, uitgedrukt in UML diagrammen. In deze sector is in toenemende mate behoefte om informatie te delen met steeds meer en nieuwe stakeholders. Dit model is ontwikkeld om uitgewisselde informatie consistent te maken en te houden. Zij wordt gebruikt door leveranciers van producten en diensten die informatie met elkaar delen binnen het complexe energiesysteem (de keten van opwekking-, transport-, distributie- en handel van energie). Dit model is behalve voor berichtspecificatie en database schema’s ook geschikt om als basis te dienen voor de ontwikkeling van specifieke RDF gebaseerde energieontologieën. In het introductiehoofdstuk hebben we gezien welke rol een ontologie speelt in de publicatie van linked data, we gaan in dit artikel hier niet verder op in. Indien nodig verwijzen we u graag naar deze introductie over RDF en de ontologie.

 

Waarom eenduidige onlogieën?
[bewerken]

Een ontologie speelt een voorname rol bij het betekenisvol publiceren van informatie. Op dit moment zijn er een aantal veel gebruikte ontologieën in omloop die voor algemene toepassingen geschikt zijn. Als voorbeeld kunnen genoemd worden de FOAF ontology om personen en relaties vast te leggen en Good Relations voor het beschijven van online verkochte product informatie.

 


Ontology is op dit moment een containerbegrip en kent geen eenduidige definitie [4] en wordt gebruikt om verschillende semantische begrippen te duiden: thesauri (waardelijst), vocabulaire (entitieten-relatie lijst) en ontology voor complexe en/of formele vocabuaires. In sommige gevallen wordt FOAF daarom niet als een ontologie beschouwd maar als vocabulair gezien. Nadere uitleg valt buiten de scope van dit artikel.

 

Het voordeel van deze gemeenschappelijk te gebruiken ontologieën is dat datasets die deze ontologieën gebruiken eenvoudig met elkaar kunnen worden gelinked, en data uit verschillende bronnen een gelijke en eenduidige betekenis krijgen.

 

Naast de gemeenschappelijk te gebruiken ontologieën is er een ontwikkeling te zien waar voor specifieke toepassingen een ontologie wordt ontwikkeld. Deze ontwikkeling is gericht op bijvoorbeeld het maken van afspraken over betekenis van terminologie en onderlinge relaties op een specifiek terrein. Dit heeft tot gevolg dat er een (wild)groei is aan ontologieën met ‘eigen’ terminologie en relaties. De consequentie hiervan is dat gepubliceerde data wel betekenisvol is, maar dat de gebruikte ‘taal’ weinig wordt gesproken, het is als het ware een beperkt gesproken dialect. Het gevolg hiervan is dat deze datasets niet direct kunnen worden gelinked met andere datasets door het ontbreken van standaard mappingen. Tussen veel gebruikte ontologieën zijn standaard mappingen beschikbaar die dit linken vergemakkelijken. Om te voorkomen dat er binnen een sector verschillende ‘talen’ wordt gesproken en er vele mappingen gemaakt en onderhouden moeten worden, is enige stroomlijning hier wenselijk. Het is echter goed hier op te merken dat deze wenselijk stroomlijning vanuit het linked data perspectief noodzakelijk is. De open gedachten van het Internet is ook op de ontologie van toepassing; iedereen mag van alles op het internet beweren, ook in zijn eigen ontologie. Het effect van de beweringen in een veel gebruikte ontologie zal door de brede acceptatie zeker groter zijn.

 

Om te zorgen voor een georganiseerde ontologieontwikkeling binnen een sector of toepassingsgebied kunnen we gebruik maken van bestaande informatieafspraken en specificaties. In veel sectoren spelen deze afspraken al een belangrijke rol als het gaat om opslag en uitwisseling van data. Mits de specificaties voldoen aan bepaalde voorwaarden, kunnen zij ook dienen als basis voor de ontwikkeling van ontologieën. Het voordeel van deze benadering is dat de acceptatie van ontologieën wordt vergroot door gebruik te maken van afspraken die binnen de sector zijn gemaakt.

 

In de energiesector zijn deze informatieafspraken vastgelegd in een IEC informatiestandaard (IEC CIM). Dit is één groot informatiemodel waar verschillende subdomeinen zijn onderscheiden. Het model definieert per subdomein classes, eigenschappen en relaties die het subdomein nader specificeren. Op deze wijze is binnen de energiesector overeenstemming vastgelegd hoe ‘dingen’ worden benoemd en welke eigenschappen en relaties relevant zijn. Op basis van deze afspraken kunnen schema’s voor databases, berichten en ontologieën voor linked data worden gedefinieerd die allen gebruik maken van dezelfde terminologie en definities. Ook wanneer er verschillende ontologieën worden ontwikkeld vanuit deze gemeenschappelijke specificatie, wordt onderlinge interoperabiliteit tussen ontologieën gewaarborgd. Binnen sectoren zoals de energiesector is dit van groot belang, de sector is zo groot en complex dat vele toepassingsontologieen zullen worden ontwikkeld. Het gebruik van een gemeenschappelijke informatieafspraak die als basis voor de ontologieën dient, versnelt deze ontwikkeling en vergroot de acceptatie van de linked data.

 

Relatie UML en RDF[bewerken]

Informatieafspraken en standaarden zijn vaak vastgelegd met behulp van UML. Dit is een veelgebruikt modelleringstaal waarmee onder andere klassendiagrammen (Entity-Relation diagram) worden vastgelegd. Dit diagram is een veelgebruikt middel om (statische) metadata en metarelaties vast te leggen. De UML diagrammen zijn grafische diagrammen die door een modelleur worden gemaakt. Ze zijn daarom niet direct geschikt om te worden toegepast in tekstgebaseerde ontologieën. Het grafisch georiënteerde model zal allereerst vertaald moeten worden naar een taal die de betekenis van het UML-diagram tekstueel representeert. Hiervoor is XMI (XML metadata interchange) ontwikkeld en wordt onder andere gebruikt om het UML model te transformeren naar een RDF representatie. Op dit moment zijn veel UML modelleringtools in staat om XMI te exporteren die vervolgens (eventueel met een tussenstap) in ontologie ontwikkel tools kunnen worden geïmporteerd. Door de conceptuele verschillen die er tussen UML en RDF zijn (object-orientatie vs verzamelingen-orientatie), worden er door de tools bij het interpreteren van de UML_XMI informatie keuzes gemaakt hoe te transformeren naar RDF. Het voert hier te ver om er dieper op in te gaan. In voorkomende gevallen is het goed om de transformatie goed te onderzoeken en na te gaan welke tools en XMI-versies geschikt zijn om in het betreffende domein te gebruiken.

 

Model matching[bewerken]

Hoe groot en omvattend een model ook is, op de randen zal aansluiting en overlap plaats vinden met andere modellen uit andere sectoren en/of toepassingsgebieden. We hebben gezien dat de UML modellen specificaties bevatten waarvan ontologieën kunnen worden afgeleidt. In gemeenschappelijke ontologieën zoals OWL worden statements (predicate) gedefinieerd waarmee semantische overeenkomsten en verschillen tussen klassen en relaties kunnen worden vastgelegd. Wanneer we model interoperabiliteit willen vastleggen is de vraag waar we dit doen. Op specificatie niveau zal een en ander vastgelegd moeten worden door domeinexperts, waarna de transformatie naar semantische RDF-ontologieen de linked data oplossingen realiseren.

 

Opmerking: in dit artikel beschouwen we OWL als een ontologie. OWL is een zgn fomele of foundational ontology en wordt in het algemeen niet als een ‘normale’ ontologie beschouwd.

 

Algemene aanpak zal gebaseerd zijn om op de koppelvlakken in de betreffende modellen de semantische overeenkomsten en verschillen vast te leggen (werk voor domeinexperts). Door de overeenkomsten en verschillen in een nieuw ‘verzoend’ model vast te leggen wordt de verbinding gemaakt met de betreffende domeinen, en wordt de basis gelegd voor een gemeenschappelijke specificatie tussen de sectoren. Dit hoeft niet noodzakelijk te leiden tot gelijke termen en definities, maar kan resulteren in het vinden en specificeren van synonieme entiteiten die onderdeel zijn van de gemeenschappelijke ontologie.

 

Aan de hand van twee voorbeelden zal de aanpak op hoofdlijnen worden getoond. Het eerste voorbeeld gaat uit van twee synonieme entiteiten in beide modellen maar waarvoor verschillende termen gehanteerd worden. De tweede benadering gaat uit van twee entiteiten die een gedeeltelijke semantische overlap hebben. Hier zullen we op model niveau eerst de overeenkomsten en verschillen specificeren alvorens over te gaan tot de ontologie transformatie. Het zijn twee voorbeelden hoe de transformatie aangepakt kan worden, in de praktijk zullen ook andere methoden voor kunnen komen.

 

Semantische overlap, verschillende terminologie[bewerken]

 

D6-LOD-figuur1.jpg

Figuur 1 UML model naar ontologietransformatie - gelijke semantiek, verschillende terminologie

 

In de figuur hierboven is een voorbeeld gegeven van een transformatie waarbij op UML model niveau sprake is van semantische overeenkomst tussen de entiteiten, maar waarin de gebruikte terminologie verschilt. Het voorbeeld laat zien hoe het X-model en IEC CIM model verzoend kunnen worden op het X:Adres en CIM:Locatie entiteit. Deze benadering gaat uit van de veronderstelling dat beide termen semantisch gelijk zijn. De vertaling van het UML model naar RDF representatie is redelijk eenduidig. De transformatie maakt gebruikt van aanpasbare transformatie regels. De naam van het UML entiteit wordt gebruikt als RDF klassenaam en de UML attribuutnaam is de basis voor de RDF property naam (hier met prefix ‘has’). Op deze wijze krijgen we uit beide modellen een RDF ontologie die we met een verzoeningsontologie aan elkaar kunnen linked. De relaties worden eenmalig vastgelegd in een verzoeningsontologie waarin we met de OWL predicates equivalentClass en equivalenetProperty de verschillende klassen semantisch kunnen linked (ontologie-verzoening). We drukken hiermee in de ontologie de overeenkomst tussen de klassen en de properties uit en hiermee worden termen uitwisselbaar tussen de verschillende ontologieën. Om de interoperabiliteit tussen de voorbeeldontologieen te vergroten, is het raadzaam om bij het publiceren van data die gebruik maakt van een van de ontologieën de verzoeningsontologie ook mee te nemen.

 

Het zal niet altijd mogelijk zijn om terminologie één-op-één op elkaar af te beelden. Het zal voorkomen dat termen een deels overlappende betekenis hebben, en de kunst is dan om die overlap expliciet te maken. Het zal dan afhangen van de gedetailleerdheid (granulariteit) van de modellen hoe makkelijk het is om die overlap in betekenis expliciet te maken. In onderstaande figuur is een overzicht gegeven hoe we in die gevallen tot verzoening kunnen komen. De eerste stap is hier om beide UML modellen eerst te verzoenen. In het getoonde voorbeeld is het gemeenschappelijke attribute (postcode) expliciet gemaakt in een nieuwe klas CIMX. De twee oorspronkelijke klassen uit het model zijn aangepast waarbij postcode geen onderdeel meer is van de oorspronkelijke klassen. Vervolgens is de stap gemaakt naar de ontologietransformatie en is een voorbeeld gegeven hoe resources die behoren tot de CIM:Location of X:Adres klasse synoniem aan elkaar kunnen worden gemaakt. In dit voorbeeld zit de semantische overlap in het property Postcode. Een RDF restrictie definieert wanneer resources van de CIM:Location of X:Adres klasse ook tot de CIMX:Postcode klasse behoren. Resources die via deze restrictie tot de CIMX klasse horen hebben een deels overlappende semantiek.

 

D6-LOD-figuur2.jpg

Figuur 2 UML model naar ontologietransformatie - semantische model verzoening via OWL restriction method.

 

De voorbeelden tonen aan dat er mogelijkheden zijn om te transformeren van UML naar RDF ontologieën. Hierbij kan worden omgegaan met semantische verschillen en per situatie zal moeten worden bekeken hoe die het beste kan worden ingericht. Afhankelijk van de situatie wordt dit nu door tools ondersteund, maar in specifieke gevallen zal nader onderzoek nodig zijn hoe dan de transformatie in te richten.

 

IEC CIM transformatie naar RDF ontologie[bewerken]

Het IEC CIM is een UML gebaseerd Class-specificatie (class-diagram). De verschillende diagrammen die samen de specificaties vormen, kunnen beschouwd worden als een uitgebreid entity-relation diagram (ERD) waarmee metadata is gespecificeerd. Dit model van IEC CIM [1] is groot en uitgebreid en bevat meer dan duizend verschillende classes met bijbehorende eigenschappen en relaties. De complexiteit die hierdoor ontstaat wordt gestructureerd door de classes in packages en diagrammen te verdelen. Deze packages en diagrammen specificeren relevante sub-domeinen binnen het energiesysteem (bv. Metering, Distributie en Transport van energie). Dit is een generiek UML-mechanisme om grote, complexe modellen voor de mens toegankelijk, begrijpbaar en onderhoudbaar te houden.

 

De UML specificaties die op deze manier zijn vastgelegd bevatten informatie om specifieke ontologieën te ontwikkelen. Bestaande CASE tools (bv Enterprise Architect) bieden mogelijkheden aan gebruikers om zogenaamde profielen te definiëren. Dit is een selectiemethode om een relevant deel uit het grote model te selecteren en die te gebruiken als basis voor een specifieke toepassing. Op basis van deze doorsnede kan een transformatie worden gemaakt naar een RDF gebaseerde ontologie die gebruikt kan worden als metadata voor de te ontsluiten dataset. Hoewel deze transformatie triviaal lijkt moet deze stap met zorgvuldigheid worden genomen, het luistert nauw hoe de notatiewijze van het object georiënteerde UML wordt geïnterpreteerd om de juiste statements te genereren voor de RDF/OWL ontologie. Binnen de energiesector is een aparte tool ontwikkeld (CIMTool [2]) die zorg draagt voor deze interpretatie en vertaling naar verschillende schema’s voor berichten, databases en ontologieën.

 

D6-LOD-figuur3.jpg

 

Figuur 3 UML–profile: CIM extensie model

 

In dit voorbeeld is een klein model gemaakt om energieverbruikdata te specificeren. Voor het ontsluiten van de data is een selectie gemaakt van classes uit het IEC CIM en is er een regionaal specifieke class gedefinieerd (DutchSDPArea == Verbruiksgebied). In bovenstaande figuur is een voorbeeld gegeven van dit diagram. Het model toont een class-specificatie met eigenschappen voor een energieverbruikgebied (DutchSDPArea), energieproduct categorie (ServiceCategory) en een service delivery point locatie (SDPLocation). Bedenk wel, het gaat hier om een klein deel van het totale model en bedoeld als basis voor de verbruiksontologie. In het voorbeeld wordt gebruik gemaakt van twee IEC CIM gedefinieerde classes (ServiceCategory en SDPLocation), en een regionaal specifieke extensie (DutchSDPArea). De dataset, die met de gegenereerde ontologie is ontsloten, zal voor een deel bruikbaar zijn voor generieke CIM gebruikers en bruikbaar voor die toepassingen (of gebruikers) die de extensies op het model ook hebben geïmplementeerd.

 

Ter illustratie is hieronder een deel van de gegenereerde ontologie gepresenteerd die uit het IEC CIM is getransformeerd. De volledige ontologie is groter en bevat alle RDF specificaties die uit het UML model worden gehaald. Dit zijn naast de entiteiten en de relaties ook de cardinaliteiten van de associaties en de attributen. Deze worden omgezet naar complexe RDF notaties met onder andere ‘blank nodes’. Het voert in dit artikel te ver om hier dieper op in te gaan, maar geïnteresseerden kunnen meer informatie vinden in het W3C RDF-primer document [3].

 

<code><rdf:Description rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fed"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Class http://www.w3.org/2002/07/owl#Class]"/></code>

<code>  <rdfs:subClassOf rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceCategory http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceCategory]"/></code>

<code>  <rdfs:label>delivers</rdfs:label></code>

<code>  <owl:unionOf rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fe7"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ffd"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.activeSDPPerc http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.activeSDPPerc]"/></code>

<code>  <owl:minCardinality rdf:datatype="[http://www.w3.org/2001/XMLSchema#int http://www.w3.org/2001/XMLSchema#int]">1</owl:minCardinality></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ff2"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.serviceReceptionPerc http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.serviceReceptionPerc]"/></code>

<code>  <owl:allValuesFrom rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ff3"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fe9"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.serviceArea http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.serviceArea]"/></code>

<code>  <owl:allValuesFrom rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fea"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fa4"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Common#TownDetail.name http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Common#TownDetail.name]"/></code>

<code>  <owl:minCardinality rdf:datatype="[http://www.w3.org/2001/XMLSchema#int http://www.w3.org/2001/XMLSchema#int]">1</owl:minCardinality></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fa8"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Common#TownDetail.country http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Common#TownDetail.country]"/></code>

<code>  <owl:allValuesFrom rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fa9"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fdb"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Class http://www.w3.org/2002/07/owl#Class]"/></code>

<code>  <rdfs:subClassOf rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceKind http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceKind]"/></code>

<code>  <rdfs:label>kind</rdfs:label></code>

<code>  <owl:unionOf rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fd2"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fcc"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceDeliveryPoint.ServiceCategory http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceDeliveryPoint.ServiceCategory]"/></code>

<code>  <owl:minCardinality rdf:datatype="[http://www.w3.org/2001/XMLSchema#int http://www.w3.org/2001/XMLSchema#int]">1</owl:minCardinality></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fd0"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Metering#ServiceDeliveryPoint.SDPLocations http://iec.ch/TC57/2009/CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/Metering#ServiceDeliveryPoint.SDPLocations]"/></code>

<code>  <owl:allValuesFrom rdf:nodeID="Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fd1"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ff8"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.housingSDPPerc http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.housingSDPPerc]"/></code>

<code>  <owl:allValuesFrom rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ff9"/></code>

<code> </rdf:Description></code>

<code> <rdf:Description rdf:nodeID="Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fe8"></code>

<code>  <rdf:type rdf:resource="[http://www.w3.org/2002/07/owl#Restriction http://www.w3.org/2002/07/owl#Restriction]"/></code>

<code>  <owl:onProperty rdf:resource="[http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.serviceArea http://iec.ch/TC57/2009/CIM-schema-cim14/DutchCIM/DcimMetering#DutchSDPArea.serviceArea]"/></code>

<code><owl:minCardinality rdf:datatype="[http://www.w3.org/2001/XMLSchema#int http://www.w3.org/2001/XMLSchema#int]">1</owl:minCardinality></code>

<code> </rdf:Description></code>

 

Een aspect dat we bij het ontsluiten van data als RDF-based data nog niet hebben benoemd is het URI mechanisme. In de bijdrage ‘Designing A URI Strategy For The Dutch Public Sector’ is een introductie gegeven wat URIs zijn en hoe die worden gebruikt bij het identificeren van ontologieën, resources en data. Bij de vastlegging van classes, attributen en relaties in het UML model bestaat in sommige CASE tools de mogelijkheid per model, package, class en relatie een URI te specificeren. Hiermee worden termen in het model uniek geïdentificeerd en wordt die identificaties gebruikt bij het generen van de ontologie. Hiermee wordt gezorgd dat gelijke terminologie uit verschillende ontologieën (maar gebaseerd op hetzelfde informatie model) dezelfde identificatie krijgen waardoor onderlinge consistentie tussen de ontologieën wordt gekregen. Wanneer CASE tools deze URI identificatie (nog) niet ondersteunen zijn aparte tools beschikbaar om tijdens het maken van profielen uit een UML model deze identificatie alsnog toe te voegen.

 

Samenvatting en conclusie[bewerken]

In dit artikel is aandacht gegeven aan het gestructureerd en eenduidig ontwikkelen van sector ontologieën. In veel sectoren en toepassingsgebieden is veel kennis en kunde vastgelegd in informatiemodellen, die geschikt zijn om als basis te dienen voor ontologieontwikkeling. Met het hergebruik van deze modellen wordt gebruik gemaakt van bestaande en vertrouwde afspraken die binnen de sector al bekend zijn. Door de afspraken te gebruiken in de ontologieontwikkeling wordt de acceptatie van linked data methode en technieken vergemakkelijkt en wordt gezorgd voor onderlinge consistentie tussen ontologieën. De onderlinge interoperabiliteit wordt hiermee gewaarborgd. Door het hergebruik van de informatiemodellen voor de ontwikkeling van ontologieën wordt ook het belang van deze modellen verder vergroot als eenduidig informatiespecificatie document.

 

Deze informatiemodellen worden vaak al op een consistente wijze onderhouden en zijn actueel en up-to-date. Dit mechanisme kan ook gebruikt worden om de ontologieën die op deze modellen zijn gebaseerd op een goede manier te onderhouden. Bij het verschijnen van nieuwe versies van het model kunnen ook nieuwe versies van ontologieën worden gepubliceerd. Daarbij kunnen ook bijbehorende mappingontologieën op een gecontroleerde manier worden gepubliceerd, en wordt de interoperabiliteit met andere modellen gewaarborgd.

 

Door de technologie- en leverancieronafhankelijke wijze van vastlegging van een informatiemodel, wordt alle ruimte gelaten voor een vrije keuze hoe de afspraken te implementeren in systemen. Veel bestaande CASE-tools maken gebruik van modelleringtalen zoals UML en bieden ruime mogelijkheden om die te transformeren naar specifieke componenten voor bijvoorbeeld Java, XML of RDF specifieke toepassingen. Die componenten leveren de gewenste functionaliteit in een specifieke technologie, de specificaties zijn technologie neutraal. Dit bevordert de eenduidigheid binnen de sector en de interoperabiliteit tussen organisaties en applicaties, terwijl er vrijheid bestaat in de technologie keuze om oplossingen te realiseren.

 

References[bewerken]

[1] Dr Alan W. McMorran (2007), An Introduction to IEC 61970-301 & 61968-11-The Common Information Model. Institute for Energy and Environment Department of Electronic and Electrical Engineering. University of Strathclyde Glasgow, UK

[2] CIMTool: http://www.cimtool.org/

[3] RDF Primer: http://www.w3.org/TR/rdf-primer/

[4] W3C: http://www.w3.org/standards/semanticweb/ontology