Koppeling architecturen in semantisch web: verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
k (verduidelijking)
(tekst toegankelijker geschreven)
Regel 16: Regel 16:
* notificatie wanneer NORA-elementen veranderen (NB: ook wanneer er nieuwe elementen bij komen waar nog geen relatie mee gelegd is)
* notificatie wanneer NORA-elementen veranderen (NB: ook wanneer er nieuwe elementen bij komen waar nog geen relatie mee gelegd is)


Voor NORA in het algemeen is het voordeel daarbij ook:
Voor de hele NORA familie is het voordeel ook:
* inzichtelijk maken hoe en òf onderdelen van NORA gebruikt worden door dochters.
* expliciet inzicht òf en hòe elementen van NORA gebruikt worden door dochters.
* voor ketensamenwerking: duidelijk maken wat de bijzonderheden zijn als in verschillende organisatorische werkingsgebieden wordt gewerkt.
* voor ketensamenwerking: duidelijk maken wat de bijzonderheden of zelfs tegenstrijdigheden zijn als in verschillende organisatorische werkingsgebieden wordt gewerkt.


==Informatiekundig aspect==
==Informatiekundig aspect==
Om een goed semantisch web te maken, moeten elkaars begrippen verstaan worden. In afstemming met deze architecturen is het [[Kennismodel NORA|NORA kennismodel]] ontwikkeld, zodat de NORA familie weet welke soorten elementen er overgenomen worden.
Om een goed semantisch web te maken, moeten elkaars begrippen verstaan worden. In afstemming met deze architecturen is het [[Kennismodel NORA|NORA kennismodel]] ontwikkeld, zodat de NORA familie weet welke soorten elementen er overgenomen worden en welke eigenschappen deze hebben. Zo kan een dochter een NORA element overnemen en plaatsen tussen de eigen, vergelijkbare, elementen of voortbouwen op elementen van NORA en daar relaties tussen leggen.


Begonnen wordt met [[:Categorie:Basisprincipes|principes]]. De dochters zullen deze over kunnen nemen en per element (principe) de toepassing voor het eigen functionele [[toepassingsgebied]] en organisatorisch werkingsgebied kunnen beschrijven. Alle eigenschappen zullen dan overgenomen zijn uit NORA, met als extra velden de toepassingsbeschrijvingen met (optioneel) toepassingsgebied, werkingsdomein en soort relatie gespecificeerd. Technisch zijn deze beschrijvingen aparte objecten. Het zal ook mogelijk zijn een NORA-principe nog niet op te nemen in de eigen architectuur. Het zal mogelijk kunnen zijn in één architectuur verschillende toepassingsgebieden en werkingsdomeinen te benoemen; bij voorbeeld in ROSA zowel PO als VO-onderwijs.
===Soorten overerving===
# comply or explain: het element wordt geannoteerd met beschrijving hoe in de eigen sector/het domein hier mee omgegaan wordt.
# 1-op-1: een element, wordt in de dochter overgenomen als het van toepassing is verklaard. Bij voorbeeld: een standaard uit de Pas Toe of Leg Uit-lijst, wordt in de dochter overgenomen omdat die daar ook verplicht is gesteld.
# 1-op-1 om relatie te leggen: het element wordt als referentie overgenomen zodat in de dochter kan worden verduidelijkt hoe de 'eigen' elementen zich verhouden tot de NORA elementen.  Bij voorbeeld: een NORA principe wordt in de eigen omgeving overgenomen zodat bij eigen uitspraken in de dochter, kan worden verduidelijkt dat deze uitspraken implicaties zijn van het NORA principe.
# pure verwijzing: de dochter neemt een NORA-element niet op in de eigen omgeving, maar verwijst er enkel naar.


Wanneer in NORA het element veranderd, zal de eigenaar van de dochter handmatig kunnen aangeven of het veranderde element overgenomen wordt.
===Versiebeheer===
Als een dochter een eigen kopie bewaart van NORA-elementen, kan de dochter zelf beslissen wanneer ze wijzigingen uit NORA overneemt. Als NORAonline.nl verschilt van de overgenomen versie in de dochter, kan de dochter het verschil bekijken. De dochter kan dan evalueren wat de impact is van de wijziging en deze op een gekozen moment overnemen in een nieuwe versie van de eigen architectuur, die samenhangt met de nieuwe NORA-elementen. NORA vermeldt de vaststeldatum bij de meeste elementen.


==Overzicht in NORA==
In de toekomstvisie van NORA zal [[Versiebeheer NORA]] uitgebreid worden zodat elementen een versienummer mee krijgen; er kan dan direct gelinkt worden naar de meest recente versie, òf een bepaalde concept- of goedgekeurde versie. Conceptversies kunnen in een dochter dan al aanleiding zijn om doorwerking voor te bereiden.
In NORA zal zichtbaar worden:
* per element (principe etc) wat de verbijzonderingen in de dochters zijn
* per elementtype: een overzicht per element of er een verbijzondering is in de afgeleide architecturen/toepassingsgebieden


===Overzichten van principes in dochters===
==Voorbeeld van implementatie: ROSA ==
Om te laten zien dat koppeling van wiki's mogelijk is, zijn er enkele overzichten van principes die direct worden geladen uit de respectievelijke referentiearchitectuurwiki's. Deze laten nog niet zien wat de relatie is tussen de verschillende principes.
Het makkelijkst is te beginnen met [[Principes]]. De dochters zullen deze over kunnen nemen en per element (principe) de toepassing voor het eigen functionele [[toepassingsgebied]] en organisatorisch werkingsgebied kunnen beschrijven. Alle eigenschappen zullen dan overgenomen zijn uit NORA, met als extra velden de toepassingsbeschrijvingen met (optioneel) toepassingsgebied, werkingsdomein en soort relatie gespecificeerd. In ROSA zijn deze nadere beschrijvingen, subobjecten in de ROSA wiki. Het is in ROSA zelfs mogelijk verschillende toepassingsgebieden en werkingsdomeinen te benoemen; zodat bij PO-onderwijs een andere uitleg staat dan bij VO-onderwijs. Het is in ROSA ook mogelijk een NORA-principe nog niet op te nemen in de eigen architectuur.
 
==Overzichten van principes in dochters==
Om te laten zien dat koppeling van wiki's mogelijk is, zijn er enkele overzichten van principes die direct worden geladen uit de respectievelijke referentiearchitectuurwiki's. Deze laten nog niet zien wat de relatie is tussen de verschillende principes. Met uitzondering van ROSA: zie  [[overzicht principes ROSA uit NORA]]
* [[Overzicht principes GEMMA]]
* [[Overzicht principes GEMMA]]
* [[Overzicht principes MARIJ]]
* [[Overzicht principes MARIJ]]
* [[Overzicht principes PETRA]]
* [[Overzicht principes PETRA]]
* [[Overzicht principes ROSA]] (deze is wèl gekoppeld, en te vinden via: [[overzicht principes ROSA uit NORA]])
* [[Overzicht principes WILMA]]
* [[Overzicht principes WILMA]]
* [[Overzicht principes ROSA]]*


==Zie ook==
==Zie ook==
* [http://prezi.com/sfrwqcxat55c/workshop-semantic-web/ presentatie over het semantisch web en semantiek in het bijzonder, op Prezi]
* [http://prezi.com/sfrwqcxat55c/workshop-semantic-web/ presentatie over het semantisch web en semantiek in het bijzonder, op Prezi]
[[Categorie:Over NORA-wiki]]
[[Categorie:Over NORA-wiki]]

Versie van 21 okt 2015 02:01

Om de samenhang in de NORA familie duidelijk te maken, wordt NORA op steeds meer plekken gekoppeld met NORA dochters. Door technische koppelingen ontstaat een 'semantisch web' van architecturen die beter op elkaar afgestemd zijn. Dit betekent dat de eindgebruiker zowel in NORA als in de dochter terecht kan om een beeld te krijgen van referentiearchitectuur op alle lagen van de overheid.

In een dochter worden elementen uit NORA overgenomen, zoals principes, bouwstenen, standaarden en begrippen. Bij elk element kan de dochter verduidelijken wat deze betekent voor eigen sector/domein/keten.

Vanuit NORA wordt bij voorbeeld duidelijk wat de implicaties zijn voor specifieke doelgroepen en kan gezien worden of een bepaalde bestuurslaag specifieke standaarden gebruikt. Bij een domeinarchitectuur is straks terug te leiden welke landelijke principes ten grondslag liggen aan domeinuitspraken. Door automatische koppeling gebeurt dit transparant, twee kanten op, en is de architectuur gemakkelijk actueel en volledig te houden.

Er is reeds één koppeling, met ROSA. Zie de presentatie met demonstratie van het koppelen en de motivatie (PDF, 755 kB), of bekijk het overzicht principes ROSA uit NORA.


Op [[Overleg:PAGENAME|de overlegpagina]] wordt uitgewerkt hoe deze koppelingen vorm kunnen krijgen.

Waarom technisch koppelen?[bewerken]

Voor NORA dochters is de directe winst:

  • expliciteren hoe met NORA omgegaan wordt
  • makkelijk NORA-elementen overnemen
  • notificatie wanneer NORA-elementen veranderen (NB: ook wanneer er nieuwe elementen bij komen waar nog geen relatie mee gelegd is)

Voor de hele NORA familie is het voordeel ook:

  • expliciet inzicht òf en hòe elementen van NORA gebruikt worden door dochters.
  • voor ketensamenwerking: duidelijk maken wat de bijzonderheden of zelfs tegenstrijdigheden zijn als in verschillende organisatorische werkingsgebieden wordt gewerkt.

Informatiekundig aspect[bewerken]

Om een goed semantisch web te maken, moeten elkaars begrippen verstaan worden. In afstemming met deze architecturen is het NORA kennismodel ontwikkeld, zodat de NORA familie weet welke soorten elementen er overgenomen worden en welke eigenschappen deze hebben. Zo kan een dochter een NORA element overnemen en plaatsen tussen de eigen, vergelijkbare, elementen of voortbouwen op elementen van NORA en daar relaties tussen leggen.

Soorten overerving[bewerken]

  1. comply or explain: het element wordt geannoteerd met beschrijving hoe in de eigen sector/het domein hier mee omgegaan wordt.
  2. 1-op-1: een element, wordt in de dochter overgenomen als het van toepassing is verklaard. Bij voorbeeld: een standaard uit de Pas Toe of Leg Uit-lijst, wordt in de dochter overgenomen omdat die daar ook verplicht is gesteld.
  3. 1-op-1 om relatie te leggen: het element wordt als referentie overgenomen zodat in de dochter kan worden verduidelijkt hoe de 'eigen' elementen zich verhouden tot de NORA elementen. Bij voorbeeld: een NORA principe wordt in de eigen omgeving overgenomen zodat bij eigen uitspraken in de dochter, kan worden verduidelijkt dat deze uitspraken implicaties zijn van het NORA principe.
  4. pure verwijzing: de dochter neemt een NORA-element niet op in de eigen omgeving, maar verwijst er enkel naar.

Versiebeheer[bewerken]

Als een dochter een eigen kopie bewaart van NORA-elementen, kan de dochter zelf beslissen wanneer ze wijzigingen uit NORA overneemt. Als NORAonline.nl verschilt van de overgenomen versie in de dochter, kan de dochter het verschil bekijken. De dochter kan dan evalueren wat de impact is van de wijziging en deze op een gekozen moment overnemen in een nieuwe versie van de eigen architectuur, die samenhangt met de nieuwe NORA-elementen. NORA vermeldt de vaststeldatum bij de meeste elementen.

In de toekomstvisie van NORA zal Versiebeheer NORA uitgebreid worden zodat elementen een versienummer mee krijgen; er kan dan direct gelinkt worden naar de meest recente versie, òf een bepaalde concept- of goedgekeurde versie. Conceptversies kunnen in een dochter dan al aanleiding zijn om doorwerking voor te bereiden.

Voorbeeld van implementatie: ROSA[bewerken]

Het makkelijkst is te beginnen met Principes. De dochters zullen deze over kunnen nemen en per element (principe) de toepassing voor het eigen functionele toepassingsgebied en organisatorisch werkingsgebied kunnen beschrijven. Alle eigenschappen zullen dan overgenomen zijn uit NORA, met als extra velden de toepassingsbeschrijvingen met (optioneel) toepassingsgebied, werkingsdomein en soort relatie gespecificeerd. In ROSA zijn deze nadere beschrijvingen, subobjecten in de ROSA wiki. Het is in ROSA zelfs mogelijk verschillende toepassingsgebieden en werkingsdomeinen te benoemen; zodat bij PO-onderwijs een andere uitleg staat dan bij VO-onderwijs. Het is in ROSA ook mogelijk een NORA-principe nog niet op te nemen in de eigen architectuur.

Overzichten van principes in dochters[bewerken]

Om te laten zien dat koppeling van wiki's mogelijk is, zijn er enkele overzichten van principes die direct worden geladen uit de respectievelijke referentiearchitectuurwiki's. Deze laten nog niet zien wat de relatie is tussen de verschillende principes. Met uitzondering van ROSA: zie overzicht principes ROSA uit NORA

Zie ook[bewerken]