-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathindex.html
4458 lines (3989 loc) · 271 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="nl">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link rel='shortcut icon' type='image/x-icon' href='https://tools.geostandaarden.nl/respec/style/logos/Geonovum.ico' />
<link rel="stylesheet" type="text/css" href="media/localstyle.css" />
<title>NEN 3610 - Linked Data</title>
<script class="remove" src="config.js"></script>
<script class='remove' src='https://tools.geostandaarden.nl/respec/builds/respec-geonovum.js'></script>
</head>
<body>
<!-- In MS Edge geen navigatievenster en hoofdstuknummers op het scherm
<ul>
<li><a href = '#inleiding'>Inleiding</a></li>
<li><a href = '#geolodcloudnl'>LOD Cloud</a></li>
<li><a href = '#usecases'>Use cases</a></li>
<li><a href = '#inventarisatie'>Inventarisatie</a></li>
<li><a href = '#basisprincipes'>Basisprincipes</a></li>
<li><a href = '#nen3610ld'>NEN3610 LD Profiel</a></li>
<li><a href = '#transformatie'>Transformatie UML-RDF</a></li>
<li><a href = '#handmatige transformatie-encoding'>Transformatie handmatig</a></li>
<li><a href = '#transformation-design'>Transformatie ontwerp</a></li>
<li><a href = '#Voorbeeld: UML-Golfbaan naar ontologie en vocabulaire'>Voorbeeld IMGolf</a></li>
<li><a href = '#dataset2model'>Voorbeeld Dataset</a></li>
</ul>
-->
<section id='sotd'>
</section>
<section id="abstract" data-include="samenvatting.html"></section>
<!-- Hoofdstuk 1 -->
<section id='inleiding' class="informative">
<h1>Inleiding</h1>
<p>Dit document is een combinatie van een technisch rapport, een handboek en een standaard. Vanwege het onderzoekskarakter van het onderwerp is er voor gekozen om deze drie typen documenten in één rapport, de standaard NEN 3610 - Linked Data, bij elkaar te houden. Het technische rapport beschrijft de samenhang en verschillen tussen de UML - Object-oriëntatie en Linked Data. In het handboek gedeelte worden de UML - RDF transformatieregels beschreven en in het normatieve gedeelte is de NEN 3610 - Ontologie opgenomen. Bij elk hoofdstuk is aangegeven of het normatief dan wel niet normatief is.</p>
<p>Steeds meer wordt Linked Data gebruikt als uitwissel- en publicatiemechanisme voor geo-informatie. NEN 3610 is de standaard voor het uitwisselen van geo-informatie, gebruikt <a>Unified Modeling Language</a> (UML) als formele taal voor het vastleggen van semantiek en beveelt <a>Geography Markup Language</a> (GML) aan als technisch uitwisselingsformat. NEN 3610 is hiermee nog niet geschikt om semantiek, gegevensdeling en uitwisseling middels Linked Data te realiseren.</p>
<p>NEN 3610 geeft ook aan dat indien een sector kiest voor een ander formaat dan GML en er nog geen codering van NEN 3610 naar dat technisch formaat bestaat, de sector gevraagd wordt deze codering te beschrijven.<br>
In dit document wordt hier een begin mee gemaakt. Geonovum heeft het initiatief genomen om partijen die actief bij de toepassing van geo-informatie als Linked Data betrokken zijn samen te brengen rond het onderwerp NEN 3610 toegepast in Linked Data. Het doel daarvan is te komen tot een gezamenlijke werkwijze die zorgt voor interoperabiliteit tussen Linked geo-Data en een een gecontroleerde relatie met het stelsel van NEN 3610 - informatiemodellen.</p>
<p>Het onderwerp is beperkt tot het ontwikkelen van de methode om een NEN 3610 model te transformeren, te implementeren in Linked Data. De relatie tussen het bronmodel, het NEN 3610 informatiemodel, en het doel, het <a>begrippenkader</a> en de <a>ontologie</a>, staat daarbij voorop. Het gaat dus niet zozeer om een algemene geo-Linked Data codering maar specifiek die van uit een NEN 3610 bronmodel.</p>
<P>Als resultaat zijn de volgende producten ontwikkeld:</p>
<ol>
<li>
<p>De basisbeginselen van Linked Data en de relatie met UML - Object-oriëntatie (zie hfst. 5 <a href="#basisprincipes">Basisbeginseln van Linked Data</a>)</p>
</li>
<li>
<p>De NEN 3610 ontologie. De standaard NEN 3610 vertaald naar een LD implementatie. Het is hiemee de standaard manier om NEN 3610 in Linked Data toe te passen. (zie hfst. 6 <a href="#nen3610ld">NEN 3610 representatie in Linked Data</a>)</p>
<p>Hiermee wordt de ontologie gerealiseerd die als standaard gebruikt wordt om een NEN 3610 informatiemodel in Linked Data uit te drukken. </p>
</li>
<li>
<p>Transformatieregels of coderingsregels voor een vertaling van een NEN 3610-UML informatiemodel naar een Linked Data omgeving. (zie hfst. 7 <a href="#transformatie">NEN 3610 representatie in Linked Data</a>)</p>
<p>De transformatieregels zijn een handreiking voor het omzetten van een NEN 3610-UML bronmodel naar een Linked Data doelmodel. De vertaling is naar de verschillende Linked Data vocabulaires die hiervoor van toepassing zijn: <a>RDF</a>, <a>RDFS</a>, <a>SKOS</a>, <a>OWL</a> en <a>SHACL</a>. </p> </p>
</li>
</ol>
<p>Bij het maken van een informatiemodel staat de use case altijd centraal als kader waaraan een model moet voldoen. Dit geldt ook voor de transformatie van een NEN 3610 model naar Linked Data. De Linked Data toepassing kan een ander doel hebben dan met het NEN 3610 model beoogd is. Er zijn wat dat betreft ook verschillende alternatieve oplossingen voor de transformatie mogelijk. Waar dat zo is geven we dat in dit document aan.</p>
<p>Het project is een open samenwerking tussen de geïnteresseerde partijen. Door middel van kennisdeling en aansluiting bij internationale ontwikkelingen wordt er toe gewerkt naar een nationaal en internationaal afgestemd resultaat.</p>
<p>Dit document beschrijft het NEN 3610 Linked Data profiel. Het betreft een standaard, als aanvulling op de bestaande NEN 3610 standaard. Het normatieve deel van deze standaard is beschreven in hoofdstuk zes. De overige hoofdstukken zijn informatief en bieden best practices in het gebruik van de standaard.</p>
<p><b>Leeswijzer:</b> Het document begint met een beeld van hoe operationeel Linked Data ingezet wordt door middel van een inventarisatie van linked geo-datasets die er in Nederland beschikbaar zijn. Hoofdstuk drie schetst de gebruikstoepassing die met de toepassing van NEN 3610 en NEN 3610 modellen in een Linked Data omgeving bediend wordt en beschrijft de reden waarom een NEN 3610-LD profiel relevant is. Er zijn ook internationale initiatieven en standaarden die op het onderwerp codering van geo-informatie in RDF in gaan. Een kort overzicht daarvan en hoe die relateren aan dit onderwerp wordt in hoofdstuk vier gegeven.</p>
<p>De <a>object-oriëntatie</a> van NEN 3610 en de ontologische kennismodellen van Linked Data kennen verschillende paradigma's. De basisbeginselen van Linked Data en een referentie naar verdere documentatie geeft in hoofdstuk 5 een inleiding en overzicht over de impact van deze verschillen. Hoofdstuk 6 is normatief en bevat het NEN 3610-LD profiel en beschrijft het NEN 3610 vocabulaire in de relevante Linked Data vocabulaires. Dit profiel wordt vervolgens in hoofdstuk 7 toegepast en aangevuld met transformatieregels om een NEN 3610-UML informatiemodel te tranformeren naar Linked Data. Hoofdstuk 7 is daarmee het inhoudelijke hoofdstuk dat de transformatieregels besschrijft. In dat hoofdstuk wordt ook geconstateerd dat er in Nederland drie verschillende Linked Data stijlen voor locatie informatie van toepassing zijn.
Hoofdstuk 8 bevat een toepassing hiervan op het niveau van een NEN 3610 voorbeeldmodel IMGolf dat naar drie verschillende Linked Data modellen wordt getransformeerd. In het laatste hoofdstuk wordt aan de hand van het NEN 3610 voorbeeldmodel een dataset gecreeerd en na de transformatie toegepast en gepubliceerd als ontologie en begrippenkader conform de drie stijlen. Deze drie Linked Data stijlen kunnen hiermee worden vergeleken</p>
</section>
<!-- Hoofdstuk 2 -->
<section id='geolodcloudnl' class="informative">
<h1>Nederlandse LOD Cloud voor geo-datasets</h1>
<p>Klik op onderstaand plaatje om een interactieve versie van de Nederlandse LOD Cloud te openen.</p>
<p><a href="media/dataset/lod-nen3610.svg"><img src="media/dataset/lod-nen3610.png" alt="Click for interactive SVG"/></a></p>
<p>De intentie is om -als spin-off van de ontwikkeling van deze standaard- een Nederlandse LOD Cloud voor geodata te maken die ook gepubliceerd kan worden in de internationale <a href="http://lod-cloud.net/">LOD Cloud</a>.</p>
<p>De meest actuele versie van de Nederlandse LOD Cloud is <a href="media/dataset/lod-nen3610.html">hier</a> te vinden. De bron voor deze LOD cloud is ook als Linked Data opvraagbaar: <a href="media/dataset/lod-nen3610.ttl">lod-nen3610.ttl</a></p>
<p>Voor het beschrijven van een dataset wordt gebruik gemaakt van [[geodcat-ap]], de Linked Data invulling van de ISO-19115 standaard voor het beschrijven van metadata over geometrische datasets.</a>
</section>
<!-- Hoofdstuk 3 -->
<section id="usecases" class="informative">
<h1>Use case voor een NEN 3610 Linked Data profiel</h1>
<p>De use case die we willen beantwoorden is:</p>
<blockquote>Creëren van interoperabiliteit tussen NEN 3610 informatiemodellen opgesteld in UML enerzijds en de toepassing van diezelfde modellen in Linked Data.</blockquote>
<p>Meer praktisch geformuleerd is dit te realiseren door:</p>
<blockquote>Informatiemodellen en data publicatie conform NEN 3610 vertalen naar kennismodellen en data publicatie conform Linked Data.</blockquote>
<p>Hiervoor biedt NEN3610LD twee producten:</p>
<ol>
<li>Specificatie van het metamodel NEN 3610 als Linked Data ontologie: NEN3610-LD Ontologie.</li>
<li>Een handreiking voor het transformeren van een UML-NEN 3610 informatiemodel naar Linked Data: NEN 3610-LD Transformatieregels.</li>
</ol>
<p><b>Achtergrond:</b></p>
<p>Tot nu toe worden veel informatie standaarden in <a>UML</a> uitgedrukt. Het <a>Object Oriëntatie</a> paradigma heeft zich over de afgelopen decennia ontwikkeld als raamwerk voor het ontwikkelen van modellen van de <a>werkelijkheid</a>. Het model gericht werken, of model driven approach (MDA) zorgt ervoor dat vanuit het UML afgeleide producten waaronder implementatieschema’s en software code gegenereerd kan worden. Voor het geo-informatiedomein heeft dit geleid tot standaardisatie in methodiek middels NEN 3610 en voor specifieke geo-informatie domeinen tot standaardisatie van semantiek. De use case is hierbij vooral gericht op informatie uitwisseling: data transport. In de implementatie daarvan staan applicaties centraal die data kunnen genereren, importeren, beheren en exporteren. In veel toepassingsdomeinen is deze standaardisatie gerealiseerd. De afgelopen jaren zijn steeds meer use-cases ontstaan waarbij informatie uit verschillende domeinen aan elkaar moet worden gekoppeld. Informatiemodellen worden daarmee integraler van opzet. Hier ligt een uitdaging: tijdens de ontwikkeling van modellen voor specifieke informatie domeinen worden impliciete aannames gemaakt die wel werken binnen een domein maar data integratie tussen domeinen kan compliceren. Deze aannames hebben invloed op de specifieke betekenis van de data: wat het wél vertegenwoordigd, maar vooral ook wat de data níet vertegenwoordigd. Deze aannames maken de datadefinities niet zozeer fout, maar het feit dat deze aannames impliciet zijn zorgt vaak voor problemen.</p>
<p>Met (onder andere) deze uitdaging in gedachten, heeft het <a>W3C</a> een aantal 'recommendations' (standaarden) opgesteld omtrent Linked Data. Deze standaarden specificeren methoden om de aannames rond data definities meer expliciet te maken en daardoor op een machine leesbare manier meer betekenis aan de data te geven, specifiek met het oog op integratie van data uit verschillende bronnen. De implementatie context is daarbij het web. Hiermee wordt dus een beweging van applicatie gericht werken naar web gericht werken ondersteund.</p>
<p>NEN 3610 is als standaard in het leven geroepen om geo-informatie eenduidig uit te kunnen wisselen tussen Nederlandse organisaties. Met het oog op bovenstaande ontwikkelingen wordt het relevant om te kijken hoe de NEN 3610 standaard in de context van Linked Data is uit te drukken om uiteindelijk het data integratie proces binnen en ook buiten het geo-domein te bevorderen. Van belang hierbij is ook te beseffen dat beide methoden elkaar niet uitsluiten maar juist complementair zijn in hun toepassing. UML-OO met informatiemodellen voor definitie van data uitwisseling in een gecontroleerde omgeving en Linked Data met kennismodellen als mechanisme voor data-integratie en publicatie in de open web-omgeving.</p>
<figure>
<img src="media/UML-OO-en-LD.png" height="350">
<figcaption>Openen van de data silo's. 'UML-OO NEN 3610' en 'Linked Data methode' naast elkaar.</figcaption>
</figure>
</section>
<!-- Hoofdstuk 4 -->
<section id='inventarisatie' class="informative">
<h1>Review beschikbare standaarden, handleidingen</h1>
<p>Er zijn een aantal standaarden en handleidingen die relevant zijn voor de implementatie van geo in Linked Data. Het gaat hierbij specifiek om standaarden die gericht zijn op de relatie tussen modellering van geo-informatie en implementatie daarvan in Linked Data. Van elke standaard wordt kort het toepassingsgebied, een samenvatting en de relevantie voor het NEN 3610 - LD profiel beschreven.</p>
<p>De volgende standaarden en handreikingen worden behandeld:</p>
<ul>
<li>ISO 19150-2: 2015 - Geographic information -- Ontology -- Part 2: Rules for developing ontologies in the Web Ontology Language (OWL)</li>
<li>INSPIRE - Guidelines for the RDF encoding of spatial data</li>
<li>W3C - Spatial Data on the Web Best Practices</li>
<li>Betekenisvol verbinden van informatie met BP4mc2-praktijkervaringen</li>
<li>Linked Data Proxy (LDProxy)</li>
</ul>
<!-- Sectie 4.1 -->
<section id='iso19150-2'>
<h2>ISO 19150-2</h2>
<p><b>naam:</b> ISO 19150-2: 2015 - Geographic information -- Ontology -- Part 2: Rules for developing ontologies in the Web Ontology Language (OWL)</p>
<p><b>url:</b> <a href=https://www.nen.nl/NEN-Shop/Norm/ISO-1915022015-en.htm>https://www.nen.nl/NEN-Shop/Norm/ISO-1915022015-en.htm</a> </p>
<p><b>type document:</b> internationale standaard</p>
<p><b>organisatie:</b> ISO TC/211</p>
<p><b>scope:</b> Beschrijving van conversieregels van <a>UML</a> klassediagrammen (application schema's) naar <a>OWL</a>. Het betreft specifiek regels voor het vertalen van de UML klassediagrammen (in de meeste gevallen application schema's) die in de ISO 191xx set van geo-standaarden opgenomen zijn. Daarnaast zijn conversieregels beschreven voor conversie van informatiemodellen (application schema) gebaseerd op het General Feature Model van 19109.</p>
<p><b>omschrijving:</b> Deel 2 in een set van ISO TC/211 Geo-informatie standaarden over gebruik van <a>ontologieën</a> als model en implementatie omgeving.
De 19150-2 gaat specifiek over conversieregels van <A>UML</A> klassediagrammen naar <a>OWL</a>. Van alle UML constructies zijn conversieregels naar OWL opgenomen. De conversie wordt ondersteund door conversie-scripts, zie <a href=https://github.com/ISO-TC211/GOM>https://github.com/ISO-TC211/GOM</a>. Alle in de 191xx standaarden opgenomen UML modellen zijn naar ontologieën vertaald en gepubliceerd op <a href=https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology>https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology</a> .<br>
</p>
<p><b>relevantie:</b> Lijkt heel relevant omdat het onderwerp overeenkomt met dit NEN 3610-LD project: vertaalregels voor een NEN 3610 model naar Linked Data beschrijven. De 19150-2 neemt ook het zelfde UML <a>metamodel</a> (GFM 19109) als NEN 3610 als bronmodel.<Br>
Er zijn echter weinig bekende practische toepassingen van de 19150-2. Ook de ontwikkelde <a>ontologieën</a> worden niet echt gebruikt.</p>
<p><b>inhoudelijke opmerkingen:</b> De 19150-2 geeft de conversieregels van <a>UML</a> naar <a>OWL</a> maar adresseert niet de use case, het gebruik van de gegenereerde <a>ontologieën</a>. Het blijft in de conversie heel dicht bij het oorspronkelijk UML en de <a>ontologieën</a> missen daardoor de aansluiting met de praktijk van Linked Data. Het levert als het ware correcte <a>ontologieën</a> op maar ze missen de Linked Data view daarop. Dit maakt het resultaat van de conversie weinig bruikbaar. Men zou verwachten dat bijvoorbeeld het spatial schema, 19107, het model van geometrietypen een bruikbaar <a>RDF</a> vocabulaire zou opleveren. Hier wordt echter aan getwijfeld en men adviseert het gebruik van al bestaand <a>RDF</a>-vocabulaire op dit terrein, bijvoorbeeld GeoSPARQL.<br></p>
<p>Ondanks dit is het een goed startpunt voor het begrijpen van de conversie tussen <a>UML</a> en <A>OWL</A>. Het document Are3NA-RDF_vocabulary (<a href=https://ies-svn.jrc.ec.europa.eu/attachments/download/1188/ARE3NA-RDF_vocabulary_guidelines_Final.pdf>https://ies-svn.jrc.ec.europa.eu/attachments/download/1188/ARE3NA-RDF_vocabulary_guidelines_Final.pdf</a>) gaat verder in op de specifieke bruikbaarheid van de ISO 19150-2 maar neemt deze standaard ook als startpunt voor aanpassingen voor een beter toepasbare conversie.</p>
</section>
<!-- Sectie 4.2 -->
<section id='inspire-rdfguidelines'>
<h2>INSPIRE RDF guidelines</h2>
<p><b>naam:</b> INSPIRE - Guidelines for the RDF encoding of spatial data</p>
<p><b>url:</b> <a href=http://inspire-eu-rdf.github.io/inspire-rdf-guidelines/>http://inspire-eu-rdf.github.io/inspire-rdf-guidelines</a> </p>
<p><b>type document:</b> richtlijn, best practice</p>
<p><b>organisatie:</b> ARE3NA project "INSPIRE Re3ference Platform Phase 2"</p>
<p><b>scope:</b> Beschrijving van UML-RDF coderingsregels voor representatie van INSPIRE datasets in RDF. Voor INSPIRE is RDF een mogelijk optionele implementatie omgeving die naast het aanbevolen <a>GML</a> een rol kan spelen. Dit onderzoek naar optionele RDF codering komt voort uit de ondersteuning van het algemene e-government programma en de open data community.</p>
<p><b>omschrijving:</b> Het document beschrijft UML-RDF coderingsregels. De coderingsregels conformeren aan ISO 19118:2011 Geographic information - Encoding. Coderingsregels voor <a>feature types</a>, attributen en associaties zijn opgenomen. Over <a>UML</a> als input in de coderingsregels wordt gezegd dat het door INSPIRE gebruikte UML profiel (in principe ISO 19109) geen extensie nodig is om zinvol te kunnen coderen naar RDF. De output is een combinatie van RDF Schema en OWL. Voor de RDF serialisatie wordt <a>Turtle</a> aanbevolen. <a>RDF/XML</a> serialisatie is ook opgenomen. Van alle UML constructies, van package, feature type, attributen, associaties, complexe <a>datatypen</a> etc. worden de RDF/Turtle en RDF/XML serialisatie gegeven. Men gaat daarbij niet altijd uit van een standaard mapping maar merkt op dat het voor komt dat men naar de bedoeling van specifieke UML constructies moet kijken hoe die in RDF moeten komen. Bijvoorbeeld een datatype dat een versimpelde vorm van een feature type voorstelt moet in RDF een feature type worden. Men noemt dit de Permission REC/OWL/type/mapping/dataTypeAsSpatialObjectTypeRepresentation. Interessant is ook dat er een transformatietabel is van ISO 19107 geometrietypen naar GML ontologieklassen van GeoSPARQL (<a href=http://www.opengis.net/ont/gml>http://www.opengis.net/ont/gml</a>). Bijvoorbeeld GM_Surface naar gmlowl:Surface.</p>
<p>Het onderzoeksrapport waarop deze guidelines zijn gebaseerd is <a href=https://ies-svn.jrc.ec.europa.eu/attachments/download/1188/ARE3NA-RDF_vocabulary_guidelines_Final.pdf>ARE3NA-RDF vocabulary guidelines.</a></P>
<p><b>relevantie:</b> Zeer relevant voor dit onderzoek. Er worden expliciete uitgangspunten gedefinieerd die als basis gelden voor de UML - RDF coderingsregels. Er wordt een format gebruikt om de regels in te specificeren dat mogelijk hergebruikt kan worden. Het document is geschikt voor de automatische conversie maar heeft ook afwegingen om daar van af te wijken. Voor het beschrijven van de automatische transformatie van de NEN 3610 UML naar RDF wordt dit document als referentie gebruikt.</p>
<p><b>inhoudelijke opmerkingen:</b> Alleen <a>RDFS</a> en <a>OWL</a> worden als <a>vocabulaire</a> gebruikt. Mogelijk is de codering vooral van uit het UML-GML perspectief ingestoken en mist het de RDF optimalisatie. Voor de NEN 3610 - UML RDF transformatie wordt dat toegevoegd.
</p>
</section>
<!-- Sectie 4.3 -->
<section id='sdwbp'>
<h2>Spatial Data on the Web Best Practices</h2>
<p><b>naam: </b>Spatial Data on the Web Best Practices [[sdw-bp]]</p>
<p><b>url: </b><a href=https://www.w3.org/TR/sdw-bp/>https://www.w3.org/TR/sdw-bp/</a> </p>
<p><b>type document:</b> best practice</p>
<p><b>organisatie:</b> <a>W3C</a> en <a>OGC</a></p>
<p><b>scope:</b> geo-data / geo-informatie en web standaarden voor data. De scope is breder dan alleen Linked Data; het streven is in eerste instantie om geodata volgens de algemene webarchitectuur te publiceren. Dit kan RDF zijn, maar ook bijvoorbeeld (verrijkte) HTML.</p>
<p><b>omschrijving:</b> Deze best practice geeft richtlijnen voor het publiceren van geodata op het web. De in totaal 14 best practices vertellen hoe je de algemene principes en architectuur van het Web moet toepassen op geodata; hoe je om gaat met specifieke geo-zaken zoals geometrie en coordinaatsystemen op het web; hoe je zorgt voor optimale toegang tot je data, en hoe je metadata voor geodata het beste kan publiceren. Alle best practices zijn gestoeld op de huidige praktijk. </p>
<p><b>relevantie:</b> De relevantie voor geo-informatiemodellen is beperkt. De best practice gaat vooral in op het publiceren van data op het web en niet zozeer op informatiemodellen of hoe je <a>UML</a> modellen in OWL kunt uitdrukken. Er staan wel een aantal relevante aanbevelingen in het document: </p>
<ul>
<li>In <a href="https://www.w3.org/TR/sdw-bp/#bp-expressing-spatial">12.2.1</a> wordt verteld dat het belangrijk is om je geodata te publiceren met duidelijke semantiek; en in een Linked Data setting is de aanbeveling om eerst te zoeken naar bestaande <a>vocabulaires</a>. Als het ontwikkelen van een eigen vocabulaire nodig is, link deze dan aan bestaande vocabulaires. Verder wordt verwezen naar de (algemene) <a href="https://www.w3.org/TR/dwbp/">Data on the Web Best Practices</a>. </li>
<li><a href="https://www.w3.org/TR/sdw-bp/#applicability-formatVbp">Appendix A</a> geeft een overzicht van bestaande vocabulaires.</li>
</ul>
</section>
<!-- Sectie 4.4 -->
<section id='bp4mc2'>
<h2>Betekenisvol verbinden van informatie met BP4mc2-praktijkervaringen</h2>
<p><b>naam: </b>Betekenisvol verbinden van informatie met BP4mc2-praktijkervaringen</p>
<p><b>url:</b> <a href=http://bp4mc2.org/>http://bp4mc2.org/</a> </p>
<p><b>type document:</b> publicatie</p>
<p><b>organisatie:</b> Platform implementatie Linked Open Data (PiLOD)</p>
<p><b>scope:</b> best practices voor het toepassen van standaard Linked Data vocabulaires voor het beschrijven van een gegevenscatalogus. De scope is breder in de zin dat BP4mc2 ook betrekking heeft op datasets, datakwaliteit en gegevenscatalogi, waarbij NEN 3610 vooral focust op gegevensmodellen. BP4mc2 gaat niet specifiek in op geometrische vraagstukken.</p>
<p><b>omschrijving:</b> Publicatie over het proces om data op het web te presenteren. Linked Data is daarbij de methode. Inzicht wordt gegeven in de relatie tussen betekenis van gebeurtenissen in de werkelijkheid en hoe die vertaald worden in begrippen en semantiek middels de grammatica van <a>SKOS</a> en <a>OWL</a>. De uri als sleutel voor objecten in een informatiesysteem en de rol van registers worden benadrukt. De publicatie geeft een uiteenzetting van theorie en praktijk over Linked Data, de methode, begrippen en manier van denken en werkwijze. Er is een verschil en een relatie tussen een datamodel (gegevens) en een model (begrippen) van de werkelijkheid. UML wordt daarbij gepositioneerd als methode voor het datamodel en SKOS-OWL voor het begrippenmodel. De architectuur van een Linked Data implementatie wordt toegelicht.<br>
</p>
<p><b>relevantie:</b> De achtergrond en filosofie van Linked Data wordt beschreven in de context van een informatievoorziening middels web-standaarden. Begrippen worden uitgelegd en de relatie tussen data, begrippen en de werkelijkheid wordt beschouwd. Een model van data is iets anders dan een model van begrippen. UML en SKOS-OWL worden daarbij aan elkaar gerelateerd.</p>
</section>
<!-- Sectie 4.5 -->
<section id='LDProxy'>
<h2>Linked Data Proxy (LDProxy)</h2>
<p><b>naam: </b>Linked Data Proxy (LDProxy)</p>
<p><b>url:</b> <a href=https://hub.docker.com/r/iide/ldproxy/>https://hub.docker.com/r/iide/ldproxy/ </a></p>
<p><b>type document:</b> software</p>
<p><b>organisatie: </b>Is ontwikkeld binnen het programma European Location Interoperability Solutions for e-Government (ELISE)</p>
<p><b>scope:</b> datauitwisseling met adapter voor WFS</p>
<p><b>omschrijving: </b>LDProxy is een adapter op een <a>WFS</a> service die zorgt voor een <a>RESTful</a> <a>API</a> die naast de WFS-GML additionele output formats als GeoJson, HTML and JSON-LD realiseert. Deze dataformats worden on the fly gecreëerd op basis van de WFS data. De LDProxy is ontwikkeld om de bestaande WFS services te verbeteren op basis van Spatial Data on the Web Best Practices. Parallel daaraan is ook de draft WFS 3.0 specificatie ontwikkeld die voor een deel ook in de LDProxy is verwerkt.<br>
</p>
<p><b>relevantie:</b> Deze adapter laat het resultaat zien van de LD publicatie van geodata die middels on the fly mapping uit <a>GML</a> gegenereerd worden. Het resultaat kan met het GML origineel en de formele UML modellen in de dataspecificaties vergeleken worden. Dit helpt om een notie te krijgen van de verschillende formats en hun relatie. In de 'on the fly mapping' wordt er waarschijnlijk gebruik gemaakt van de transformatieregels uit het document INSPIRE - Guidelines for the RDF encoding of spatial data. Het zal dan alleen gaan om de automatische transformatieregels en niet afwijkende regels die van uit specifieke domein UML/XSD nodig zijn. Het is interessant om het resultaat van de LDProxy mappping te vergelijken met de mappping die in dit document is uitgewerkt.</p>
</section>
<!-- Sectie 4.6 -->
<section id='NTA8035'>
<h2>NTA8035</h2>
<p><b>naam: </b>NTA8035 - Semantische Gegevensmodellering en Integratie in de Gebouwde Omgeving</p>
<p><b>url:</b> </p>
<p><b>type document:</b> Nederlandse Technische Afspraak</p>
<p><b>organisatie: </b>NEN NC 381184 werkgroep</p>
<p><b>scope:</b> Afsprakenstelsel (Conceptueel Meta Model en Conceptueel Top Model) vanuit het perspectief van partijen uit de Gebouwde Omgeving in Nederland.</p>
<p><b>omschrijving: </b>Het doel van deze Nederlandse Technische Afspraak (NTA) is om afspraken vast te leggen voor de toekomstvaste semantische modellering en integratie
(uitwisseling of deling) van digitale gegevens (Engels: “data”) op basis van W3C “Linked Data/Semantic Web (LD/SW)” standaarden. </p>
<p>Het gaat hierbij niet alleen om standaard gegevensformaten en benaderingsmethoden maar vooral ook om gegevensstructuren (Engels: “data models”) die betekenis (“semantiek”)
geven aan de gegevens.</p>
<p>Het zijn afspraken opgesteld vanuit het perspectief van partijen uit de “gebouwde omgeving” (gebouwen en infrastructuren) in Nederland en waar partijen op voort kunnen borduren
m.b.t. hun eigen ontwikkelingen met waarborging op interoperabiliteit tussen deze partijen bij toepassing.</p>
</p>
<p><b>relevantie:</b> De modellen die conform NTA8035 gemodelleerd worden raken ook de modellen die in onder het NEN3610 stelsel vallen, zoals IMGeo en IMBor. Het is dus van belang dat het
NEN3610-LD profiel interoperabel is met de NTA8035.</p>
</section>
</section>
<!-- Hoofdstuk 5 -->
<section id='basisprincipes' class="informative">
<h1>Basisbeginselen van Linked Data</h1>
<!-- Sectie 5.1 -->
<section id="basisprincipes-introductie">
<h2>Introductie</h2>
<p>We veronderstellen enige kennis van wat Linked Data nu eigenlijk is en wat we bijvoorbeeld bedoelen met de term <a>triples</a>. Als eerste introductie van Linked Data zijn dit goede bronnen: </p>
<ul>
<li><a href="https://www.noraonline.nl/wiki/Linked_Data">Beknopte uitleg op Nora Online</a></li>
<li><a href="https://youtu.be/4x_xzT5eF5Q">Uitleg in video</a> (Door Manu Sporny, Engels)</li>
<li><a href="http://www.pilod.nl/wiki/Boek/Verhelst">Uitleg om te lezen</a> (Door Lieke Verhelst, Nederlands)</li>
</ul>
<aside class="note">In dit document gebruiken we de term <a>vocabulaire</a> wanneer we het in algemene zin hebben over een verzameling van termen waarmee je je uitdrukt. De term <a>begrippenkader</a> gebruiken we voor een model van begrippen die (tekstueel) gedefinieerd zijn en onderlinge relaties hebben, zoals bijvoorbeeld in een thesaurus. Met de term <a>ontologie</a> bedoelen we een machine-leesbaar kennismodel met een set regels, die gebruikt kunnen worden om extra kennis af te leiden uit gelinkte data. Zowel vocabulaires als ontologieën zijn in ons taalgebruik dus 'vocabulaires'.</aside>
<p>Voor het begrijpen van de rest van dit document is het belangrijk om te weten dat het gedachtegoed van Linked Data fundamenteel verschilt van het gedachtegoed van de administratieve systemen die we kennen zoals in relationele databases en <a>object-oriëntatie</a>. In Linked Data doen we beweringen over specifieke dingen uit de werkelijkheid of, om precies te zijn, uit het <a>beschouwingsgebied</a> ofwel 'universe of discourse'. De dingen waar we beweringen over doen hebben een identificerende URI (meer hierover in <a href="#basisprincipes-identificatie"></a>). Elke 'triple' is een bewering die invulling geeft aan één specifieke eigenschap van een onderwerp, het <a>subject</a>. </p>
<p>Naast een subject bestaat elke bewering of triple uit een eigenschap en een waarde. De waarde kan ook weer een onderwerp op zich zijn met een eigen unieke sleutel (URI) en eigenschappen. Het bijzondere van Linked Data is dat dat andere onderwerp heel ergens anders opgeslagen kan zijn: het hoeft niet in dezelfde database te zitten. Dit betekent ook dat iedereen beweringen kan doen over elkaars onderwerpen: <a href="https://www.w3.org/TR/rdf-concepts/#section-anyone">Anyone can say anything about anything (AAA)</a>. Hieruit volgt weer dat je niet 'alles' kunt weten</a> over een onderwerp (er kunnen immers beweringen bestaan die je niet gevonden hebt): dit heet het <a href="http://wiki.opensemanticframework.org/index.php/Overview_of_the_Open_World_Assumption">open wereld principe</a>. </p>
<p>Data modelleren in <a>OWL</a> lijkt op het eerste gezicht best veel op <a>UML</a>. Je hebt klassen, eigenschappen, en relaties. Er is echter een fundamenteel verschil. Met OWL beschrijf je de regels van hoe de wereld in elkaar zit en ga je vervolgens met die regels data achteraf classificeren. Je bent dus eigenlijk geen data aan het modelleren, maar kennis aan het beschrijven die kan worden toegepast op data. In de object-georienteerde / relationele wereld kan data niet bestaan zonder expliciet een instantie te zijn van een klasse en is je data van tevoren gecategoriseerd. Als je in een UML model bijvoorbeeld de klasse fiets modelleert als een object met precies twee wielen, heeft dit als resultaat dat een instantie van een fiets met één of drie wielen wordt afgekeurd: deze voldoet niet aan de definitie van fiets. Over andere objecten met wielen zegt dit niets, tenzij het UML model daar ook klassen voor definieert. In Linked Data zou het resultaat echter zijn dat elk ding dat twee wielen heeft, behoort tot de klasse fiets. Dus ook een motorfiets, een step, of een tweewielige kruiwagen. Een ding met één of drie wielen is geen 'incorrecte instantie' maar blijkbaar een ding dat tot een andere, onbekende klasse behoort.</p>
<p>Een informatiemodel in de Linked Data wereld kan bestaan uit verschillende onderdelen:</p>
<ul>
<li>Een model van <em>begrippen</em>, dat beschrijft welke concepten er in het domein dat je wilt modelleren een rol spelen, en wat ze betekenen. Dit kun je uitdrukken met <a>SKOS</a> [[skos-primer]].</li>
<li>Een <em>ontologie</em>, die een kennisdomein beschrijft in termen van klassen en eigenschappen die relevant zijn binnen dit kennisdomein, aangevuld met <em>regels</em>, die gebruikt kunnen worden om extra kennis af te leiden uit gelinkte data. Met behulp van een ontologie kunnen computers begrijpen wat de data betekent en redeneren over data. Een ontologie kun je uitdrukken met <a>RDFS</a> [[rdf-schema]] en <a>OWL</a> [[owl2-primer]].</li>
<li>Een specificatie van de <em>structuur</em> die de gegevens in een Linked Data dataset hebben, bijvoorbeeld eigenschappen die altijd aanwezig zijn voor een specifieke klasse, <a>datatypen</a>, cardinaliteiten, enzovoort. Dit kun je uitdrukken met <a>SHACL</a> [[shacl]].</li>
</ul>
<p>Het bijzonder aan Linked Data is dat het niet nodig is om een uitwisselingsmodel te beschrijven. Alle Linked Data, ongeacht het model, kan uitgewisseld worden met een aantal gestandaardiseerde uitwisselingsformaten. De bekenste formaten zijn Turtle, RDF/XML en JSON-LD</p>
<p>De hierboven beschreven uitgangspunten van Linked Data hebben verregaande consequenties die informatiemodelleren voor Linked Data fundamenteel anders maken dan informatiemodelleren voor een gesloten administratief ecosysteem. Wil je dat jouw Linked Data bruikbaar is voor anderen, dan zijn er verschillende aspecten waar je rekening mee moet houden. </p>
</section>
<!--De tekst hieronder moet kunnen leunen op de Linked Data 101 uitleg. -->
<!-- Sectie 5.2 -->
<section id='basisprincipes-identificatie'>
<h2>Identificatie</h2>
<p>In Linked Data gebruiken we <a>IRIs</a> om dingen te identificeren. IRIs zijn een goed mechanisme om wereldwijd unieke sleutels aan <a>subjecten</a> toe te kennen en maken het mogelijk om links te leggen. Het is belangrijk om goed na te denken over de opbouw van IRIs als je deze aan je data gaat toekennen. Ze moeten in ieder geval uniek en persistent zijn; bovendien is het gewenst dat ze <em>dereferenceable</em> zijn, zodat je op het desbetreffende web adres bruikbare informatie over het onderwerp kunt vinden. Meer lezen hierover kun je in onderstaande bronnen: </p>
<ul>
<li><a href="https://www.geonovum.nl/uploads/documents/D1-2013-09-19_Towards_a_NL_URI_Strategy.pdf">URI strategie NL</a>(Nederlands)</li>
<li><a href="https://www.w3.org/TR/sdw-bp/#bp-identifiers">Best practices over Spatial Data Identifiers</a> (Engels)</li>
<li><a href="https://www.w3.org/TR/ld-bp/#HTTP-URIS">Good URIs for Linked Data</a> (Engels)</li>
<li><a href="https://www.w3.org/TR/cooluris/">Cool URIs for the Semantic Web</a> (Engels)</li>
</ul>
<aside class="note">Een IRI is gewoon een URI, maar beter internationaal bruikbaar omdat je in een IRI ook tekens uit niet-latijns schrift kan gebruiken. En een URI is soms ook gewoon een URL, dwz: als de identificatie ook een locatie op het web is (meestal begint zo'n URI dan met <code>http</code>, zoals in de adresbalk van je browser).</aside>
<p>Het is daarnaast ook belangrijk om precies te zijn over het <a>subject</a> dat een IRI identificeert. Een verschil met administratieve systemen is dat het subject van een Linked Data bewering verwijst naar een ding uit het <a>beschouwingsgebied</a>. Het is in Linked Data belangrijk om heel precies te zijn over wat het onderwerp, het 'subject' van een <a>triple</a>, precies is. Een triple over een persoon heeft een ander onderwerp dan een triple over een document dat gaat over die persoon. In administratieve systemen zijn we niet gewend om zo precies te zijn: we impliceren dat een bestand met persoonsgegevens over een specifieke persoon gaat, zonder dat we direct de persoon identificeren.Vaak wordt in Linked Data onderscheid gemaakt tussen <a>information resources</a> en <a>non-information resources</a>. Een document of een database record over een persoon (de information resource) is iets anders dan de persoon zelf (de non-information resource). Als het bijvoorbeeld belangrijk is om onderscheid te maken tussen formele en materiële historie, zou je dit in Linked Data doen door deze twee vormen van historie aan twee verschillende subjecten te hangen: de geboortedatum aan de persoon, en de ontstaansdatum van de informatie aan het record of document.</p>
<p>Er is nog een ander belangrijk verschil tussen UML en OWL. Dit heeft te maken met de Unique Naming Assumption (<a>UNA</a>) in UML. Daarmee wordt namelijk gesteld dat een unieke ID naar een unieke entiteit verwijst en dat een unieke entiteit door één unieke ID wordt aangeduid. Dit betekent dat 2 objecten met 2 verschillende ID's nooit naar hetzelfde kunnen, dan wel mogen, verwijzen. In Linked Data is dit laatste wél mogelijk. Het idee is namelijk dat meerdere mensen iets over het zelfde ding kunnen zeggen, en dan kun je er vanuit gaan dat ze daar ook een andere ID voor hebben gebruikt. Door de <a href="http://www.w3.org/2002/07/owl#sameAs">owl:sameAs</a> relatie kan in Linked Data aangegeven worden dat twee verschillende ID's naar het zelfde ding verwijzen.</p>
<aside class="note">
<h3>Consequenties voor NEN 3610</h3>
<p>In NEN 3610:2011 zijn regels opgenomen voor identificatie. Deze regels moeten worden aangepast voor het toepassen van IRIs als identificatie, aangevuld met een regel en/of aanbevelingen voor het toepassen van meerdere unieke IDs voor hetzelfde ding in de werkelijkheid. Ook is het gewenst om het belang uit te leggen van het precies modelleren van het subject, zonder daarbij bijvoorbeeld het ding in de werkelijkheid en het object in de registratie samen te voegen in één klasse. </p>
</aside>
</section>
<!-- Sectie 5.3 -->
<section id="basisprincipes-classificatie">
<h2>Classificatie</h2>
<p>Het opstellen van een ontologie wordt ook wel "ontology engineering" genoemd. Bij het opstellen van een ontologie maak je expliciet welke kennis uit een domein relevant is. Een basisbeginsel daarbij is dat daadwerkelijk het domein wordt beschreven, en niet zozeer de gegevens die daarover opgeslagen worden. Een belangrijk instrument is daarbij de <i>classificatie</i>. Classificatie gaat over het benoemen van groepen (de "klassen") van dingen die een aantal eigenschappen gemeen hebben. Zo hebben "dingen" uit de groep van "golfbanen" gemeen dat deze uit "holes" bestaat. Dus blijkbaar is de relatie van belang tussen een “golfbaan” en een “hole”. Daarnaast geldt voor de groep van "bosbanen" dat er veel bomen op het golfbaanterrein staan. Dus blijkbaar is een eigenschap als "bomen op de golfbaan" van belang. Tenslotte weten we dat elke bosbaan ook een golfbaan is, en daarmee kunnen we stellen dat de klasse van bosbanen een subklasse is van de klasse van golfbanen. Voor elke klasse moet gelden dat er een eigenschap is waarmee we elk exemplaar van deze klasse uniek kunnen onderscheiden van de exemplaren uit een andere klasse. In het geval van de klasse van "bosbanen" kunnen we dat op basis van de eigenschap "bomen op de golfbaan". Het opstellen van een ontologie omvat dus het beschrijven van de groepen die we relevant vinden om te onderscheiden, de eigenschappen en relaties die daarbij een rol spelen, en regels waarmee je bepaalt hoe je op basis van de eigenschappen en relaties kunt bepalen tot welke groep iets behoort.</p>
<p>Klassen, eigenschappen en relaties uit een ontologie lijken verdacht veel op klassen, attributen en associaties uit UML. Bij UML 'construeer', maak, je echter klassen als een blauwdruk voor
de instanties die je gaat uitwisselen. Het verschil zit er in dat je in een ontologie over het algemeen verder gaat met het opdelen in klassen,
en ook eigenschappen benoemd die wel nodig zijn om je domein te "begrijpen", maar niet per se nodig zijn om informatie over het domein te delen.
Zo is het voor ons golfbanen voorbeeld voldoende om vast te leggen tot welk "type" een golfbaan behoort (zoals: bosbaan, polderbaan, etc), maar niet waarom dit nu zo is.
Andersom maak je in UML soms modelleerkeuzes die specifiek betrekking hebben op de manier waarop je de gegevens wilt vastleggen.</p>
</section>
<!-- Sectie 5.4 -->
<section id='basisprincipes-normalisatie'>
<h2>Normalisatie</h2>
<p>Zoals uitgelegd in de vorige paragraaf, is het in Linked Data belangrijk om in onze modellering van de klassen waartoe de subjecten uit triples kunnen behoren, heel precies te zijn en zo dicht mogelijk bij de werkelijkheid te blijven. Voordat je begint met het transformeren van een informatiemodel naar een Linked Data model is het daarom belangrijk om stil te staan bij het oorspronkelijke doel en de uitgedrukte betekenis van het informatiemodel. Is het een conceptueel of logisch datamodel? Een technisch objectmodel? Een technisch berichtmodel? De meeste informatiemodellen zijn in meer of mindere mate <a>gedenormaliseerd</a>. Dit is omdat de informatiemodellen vanuit een bepaald oogpunt zijn opgesteld en vaak een technisch insteek hebben. Bijvoorbeeld een berichtmodel voor geoptimaliseerde communicatie, waarbij selectief aangebrachte redundantie voordelig kan zijn.</p>
<p>Een goed Linked Data model is juist een model dat een representatie biedt die zo dicht mogelijk bij de te beschrijven werkelijkheid ligt. Hoewel de term "normalisatie" vooral gebruikt wordt in relatie tot relationale databases, kun je het mechanisme van normalisatie wel goed gebruiken om te zien of een informatiemodel goed bruikbaar is om te vertalen naar een ontologie: een goed genormaliseerd informatiemodel zal tot minder uitdagingen leiden bij transformatie naar een ontologie, dan een gedenormaliseerd model. Zie de afbeeldingen hieronder om een idee te krijgen van hoe normaalvormen de structuur en bereikbaarheid van informatie beïnvloeden.</p>
<figure>
<img src="media/Normalisatie1.png" width="600">
<figcaption> Een model van object persoon in de eerste normaalvorm. Persoon en adres, in werkelijkheid twee verschillende dingen, staan hier in één klasse.</figcaption>
</figure>
<figure>
<img src="media/normalisatie2.png" width="600">
<figcaption> Een model van objecten persoon en adres in de tweede normaalvorm. Persoon en adres zijn in deze vorm gescheiden.</figcaption>
</figure>
<p>Normalisatie is dus uiterst belangrijk voor een goed Linked Data model. Maar het normaliseren van een informatiemodel is alleen mogelijk wanneer je de betekenis van de data - de semantiek - begrijpt. Hieruit volgt dat het meestal niet mogelijk is om een automatische vertaling te doen van een informatiemodel naar een goed Linked Data model!</p>
<p>Merk op dat het wel mogelijk is om een gedenormaliseerd model over te zetten in een correct (gedenormaliseerd) Linked Data model. Echter gaat dit in tegen de principes van Linked Data. De gedenormaliseerde entiteitsrepresentatie is namelijk per definitie niet meer herkenbaar in de open wereld en heeft enkel waarde binnen een zeer specifieke (systeem) context, daarmee de herbruikbaarheid en de linkbaarheid van de data verminderend.</p>
<p>Een praktische richtlijn die hieruit volgt, is dat je wanneer je een klasse modelleert, je alleen die eigenschappen aan een klasse toevoegt die direct tot deze dingen behoren, ofwel essentiele eigenschappen zijn. </p>
<p>Nauw verwant is het punt dat gegevens over gegevens van een entiteit vaak op hetzelfde niveau als de gegevens over de entiteit worden geplaatst. Een veel voorkomend voorbeeld daarvan is geldigheid van gegevens. Echter, eigenschappen die bijvoorbeeld gaan over het registreren van informatie over de instantie in het systeem (door wie? wanneer? etc.) horen in een goed Linked Data model niet bij de entiteit zelf (de <a>non-information resource</a>), maar bij de <a>information resource</a>. </p>
<aside class="note">
<h3>Consequenties voor NEN 3610</h3>
<p>In NEN 3610:2011 staan regels voor het opnemen van materiele en formele historie en materiele en formele levensduur. Deze regels moeten worden heroverwogen in het kader van de in Linked Data gewenste scheiding tussen information resource en non-information resource. </p>
</aside>
</section>
<!-- Sectie 5.5 -->
<section id='modeltypen'>
<h2>Verschillende type informatiemodellen</h2>
<p>Een informatiemodel beschrijft de werkelijkheid. In de praktijk blijken hier niveaus in te bestaan, variërend van een zo getrouw mogelijke beschrijving van die werkelijkheid tot een specificatie van de wijze van vastlegging van die werkelijkheid in een database of uitwisselformaat. Veelal worden vier niveaus onderscheiden:</p>
<ul>
<li>Niveau 1: een <b>model van begrippen</b> waarin de werkelijkheid wordt beschreven door middel van de daarin gehanteerde begrippen en de relaties tot elkaar</li>
<li>Niveau 2: een <b>conceptueel informatiemodel</b> waarin de werkelijkheid wordt beschreven door middel van de informatie die voor dit domein relevant is, onafhankelijk van de het ontwerp en de implementatie in systemen</li>
<li>Niveau 3: een <b>logisch informatie- of gegevensmodel</b> waarin de werkelijkheid wordt beschreven door middel van de representatie van de informatie in de systemen en de uitwisseling tussen systemen en gebruikers</li>
<li>Niveau 4: een <b>fysiek of technisch gegevens- of datamodel</b> waarin de werkelijkheid wordt beschreven door middel van de structuur en eigenschappen van de technologie die wordt gebruikt bij de opslag of uitwisseling</li>
</ul>
<p>Een UML model wordt over het algemeen gebruikt voor het opstellen van modellen op niveau 2 en 3. Vaak is daarbij niveau 1 impliciet, bijvoorbeeld door geven van een definitie aan een modelelement op niveau 2, waarmee feitelijk een definitie wordt gegeven aan een begrip op niveau 1. UML wordt zelden toegepast op niveau 4, tenzij sprake is van een specifiek profiel (bijvoorbeeld een DDL-profiel voor een relationele database), of het toepassen van MDA (Model Driven Architecture) voor het automatisch genereren van een model op niveau 4 vanuit een model op niveau 3.</p>
<p>Linked Data kan worden toegepast op elk van de niveaus. Bovendien geldt daarbij dat voor elk van de niveaus gebruik wordt gemaakt van dezelfde expressievorm: triples. Hierdoor is het mogelijk om direct vanuit het ene niveau te verwijzen naar het andere niveau</p>
<p>Bovendien geldt dat Linked Data een geuniformeerd fysiek datamodel kent. Hierdoor is het niet nodig om voor elk afzonderlijk model op niveau 3 een eigen fysiek datamodel te ontwikkelen of te genereren. Elk Linked Data model is een model dat bestaat uit triples, en uitgewisseld of opgeslagen kan worden op basis van standaarden. De meest bekende standaarden zijn Turtle, RDF/XML en JSON-LD.</p>
<p>Modellen op niveau 1 worden over het algemeen in Linked Data uitgedrukt op basis van SKOS. Ook geldt dat een goede ontologie in Linked Data zowel bruikbaar is als conceptueel informatiemodel EN als logisch informatiemodel. Dit is mogelijk, omdat een ontologie in Linked Data niet zozeer een structuur beschrijft die opgeslagen dan wel uitgewisseld wordt, maar vooral beschrijft wat de betekenis is van de termen die worden gebruikt bij deze uitwisseling of opslag.</p>
<p>Om in Linked Data vervolgens te specificeren op welke manier een ontologie wordt gebruikt in een uitwisseling, kan specifiek voor één uitwisseling een SHACL structuurspecificatie worden opgesteld.</p>
<p>Ten aanzien van de vier hierboven genoemde niveaus kan dan ook worden geconstateerd:</p>
<ul>
<li>Deze vier niveau's zijn ook in Linked Data aanwezig, maar wel op een iets andere wijze ingevuld.</li>
<li>Het model van begrippen wordt expliciet onderscheiden van de overige modellen.</li>
<li>Het fysieke of technische datamodel is geuniformeerd: deze is wereldwijd gestandaardiseerd.</li>
<li>De ontologie is zowel bruikbaar op niveau 2 en 3. Bovendien wordt in de uitwisseling van concrete data expliciet gerefereerd aan deze ontologie, en verwijst de ontologie terug naar het model van begrippen.</li>
<li>Om expliciet een opslagstructuur of uitwisselingsstructuur te beschrijven, wordt gebruik gemaakt van SHACL structuurspecificaties, waarbij ook weer wordt verwezen naar de ontologie.</li>
</ul>
<p>In dit document wordt voor de transformatie uitgegaan van een UML model op niveau 2/3. Dit sluit aan op het uitgangspunt dat nu veel van dergelijke modellen aanwezig zijn, en het relevant is om daarvan ook een variant te hebben, uitgedrukt in Linked Data. Vanuit een modelleringsaanpak zou het echter beter zijn om te beginnen met een model op niveau 1, en vervolgens dit model verder uit te werken op de lagere niveaus, waarbij zowel een UML informatiemodel als een Linked Data ontologie onstaat vanuit een gedeeld begrippenkader op niveau 1.</p>
</section>
<!-- Sectie 5.6 -->
<section id='basisprincipes-setorientatie'>
<h2>Setoriëntatie in Linked Data en de relatie met de UML Class</h2>
<p>
Linked Data maakt gebruik van <a>RDF</a> als gegevensmodel. RDF is setgeoriënteerd, dat wil zeggen, gebaseerd op de verzamelingenleer. Een klasse in RDF (<a href="http://www.w3.org/2000/01/rdf-schema#Class">rdfs:Class</a>, <a href="http://www.w3.org/2002/07/owl#Class">owl:Class</a>) is een set van dingen met gedeelde eigenschappen. Klassen kunnen, vergelijkbaar met objectgeoriënteerde klassen, hierarchisch gerelateerd worden. Echter, een belangrijk verschil tussen RDF en het objectgeoriënteerde paradigma is dat alle klassen (sets) kunnen overlappen. Een ding kan tegelijkertijd tot meerdere klassen behoren. Dat wil zeggen dat het ding de eigenschappen van beide klassen draagt. Hierbij is het goed om onderscheid te maken tussen meervoudige typering en <a>multiple inheritance</a>(meervoudige overerving).<br>
Bij meervoudige typering wordt een ding geklassificeerd tot meerdere klassen. Dit wordt in RDF vaak toegepast om een en hetzelfde ding te beschrijven vanuit meerdere perspectieven. Een ding kan bijvoorbeeld getypeerd worden tot de klasse van datasets (<code>void:Dataset</code>) en de klasse van entiteiten die een herkomst hebben (<code>prov:Entity</code>), omdat we deze aspecten op hetzelfde ding beschrijven.
Met <a>multiple inheritance</a> kan ook meervoudige typering bereikt worden. Het verschil is dat de typering niet direct aangebracht wordt, maar wordt afgeleid. Zo zou je een klasse <code>Renpaard</code> een subklasse kunnen laten zijn van de klassen <code>Paard</code> en <code>Wedrenner</code>. Hiermee kan worden afgeleid dat een instantie van de klasse <code>Renpaard</code> ook een instantie is van <code>Paard</code> en <code>Wedrenner</code> en eventuele superklassen van deze klassen.<br>
In principe is het altijd wel mogelijk om een intersectie van klassen te definiëren waarmee een meervoudig getypeerd ding enkelvoudig geklassificeerd kan worden, echter leidt dit veelal tot onnodige complexiteit.
</p>
<p>
Omdat RDF uit gaat van een open wereld, is het onmogelijk om alle instanties van een klasse van te voren te kennen. Er bestaat altijd de mogelijkheid dat er een nieuwe bewering over een ding gedaan wordt, waarmee een nieuwe klassificatie gemaakt kan worden. Deze openheid biedt extreme flexibiliteit, die nodig is om een internet van Linked Data te kunnen realiseren.
</p>
<p>
Hoewel sommige objectgeoriënteerde talen het concept van <a>multiple inheritance</a> ondersteunen, doet het merendeel dat niet. Meervoudige typering (zonder <a>multiple inheritance</a>) wordt helemaal niet ondersteund. Een verschijnsel dat daardoor veel voorkomt in informatiemodellen zijn typerende / classificerende lijsten. Een objectklasse heeft dan vaak een attribuut waarvan de naam begint met 'type' of 'soort', waarmee een extra typering van instanties kan worden gegeven. Omdat RDF setgeoriënteerd is, zijn dit soort attributen in Linked Data niet nodig; in plaats daarvan kan de instantie lid gemaakt worden van meerdere klassen.</p>
<section id='UML-OWL-Classes'>
<h3>UML classes en OWL classes</h3>
<p> Er bestaat een subtiel verschil tussen wat een <a>UML</a> class vertegenwoordigt en wat een <a>OWL</a> class vertegenwoordigt. Wat de de oorzaak van dit verschil precies is, vereist een theoretische verhandeling die we hier achterwege laten. Echter aan de hand van een voorbeeld moet het lukken om hier toch enig inzicht in te verschaffen, waardoor we tijdens het transformeren tussen UML en OWL, de juiste keuzes kunnen maken. </p>
<p> Zowel in UML als in OWL bestaat het principe van overerving. In OWL door de <a href="http://www.w3.org/2002/07/owl#subClassOf">rdfs:subClassOf</a> relatie. In UML wordt overerving aangeduid met de superClass relatie. OWL gaat uitsluitend uit van semantische relaties ofwel types. Bijvoorbeeld: een mens is een type zoogdier. We kunnen dus stellen dat de owl:Class mens een <a href="http://www.w3.org/2002/07/owl#subClassOf">rdfs:subClassOf</a> is van de owl:Class zoogdier. Het zelfde is correct in UML: een UML class persoon heeft een superClass relatie met de UML class zoogdier. Dit is voor de meeste mensen intuïtief correct.</p>
<p>Echter, in UML mag de superclass ook voor andere doeleinden gebruikt worden. Dit wordt in de volgende paragrafen beschreven.</p>
</section>
<section id='PandWoonplaats'>
<h3>Wat is een Pand en wat is een Woonplaats</h3>
<figure>
<img src="media/Overerving.png" width="600">
<figcaption>Pand en Woonplaats zoals ze in IMBAG gemodelleerd zijn</figcaption>
</figure>
<p> Als voorbeeld nemen we een uitsnede uit IMBAG (Informatie Model Basisregistratie Adressen en Gebouwen). Als we intuïtief denken aan het concept ‘Pand’, dan denken we aan een gebouw, aan iets waar je naar binnen kunt lopen en dat je aan kunt raken. De formele definitie die IMBAG geeft (op het moment van schrijven) is:</p>
<p> <i>Een Pand is de kleinste, bij de totstandkoming functioneel en bouwkundig-constructief zelfstandige eenheid die direct en duurzaam met de aarde is verbonden en betreedbaar en afsluitbaar is.</i> [[IMBAG]]</p>
<p> Echter, 'Pand' overerft eigenschappen als 'documentdatum' en 'documentnummer'. Deze eigenschappen blijken overerft van de UML class BAG-object. Een andere class die van BAG-object overerft is de Woonplaats. Intuïtief denken we hier aan een regio, met relatief veel bebouwing. De definitie volgens IMBAG:</p>
<p><i> Een Woonplaats is een door het bevoegde gemeentelijke orgaan als zodanig aangewezen en van een naam voorzien gedeelte van het grondgebied van de gemeente. </i> [[IMBAG]]</p>
</section>
<section id='BagObject'>
<h3>Wat is een BAG-object?</h3>
<p> Als we puur vanuit een semantisch perspectief (dat OWL hanteert) naar deze classes en hun overerving kijken, dan komen we tot een definitie die is samengesteld gebaseerd op het feit dat een BAG-object 'een verzameling vertegenwoordigd die zowel een woonplaatsen als een panden bevat en eigenschappen heeft als documentnummer, en documentdatum' . Dit doet vermoeden dat BAG-object dus een soort document is. Bij document denken de meeste mensen aan een stapeltje papier of misschien een pdf-je, meer generiek 'iets dat een beschrijving bevat van iets'. </p>
</section>
<section id='OWLPand'>
<h3>Als je met een OWL bril naar UML kijkt: wat is een Pand?</h3>
<p> Als we vanuit een OWL perspectief naar het <a>UML</a> model kijken, dan zien we onmiddellijk dat een Pand een soort document is. Als we dit samen voegen met de definitie van Pand zoals die in IMBAG wordt gegeven, dan komen we tot het volgende:</p>
<p><i> Een Pand is een soort document en is [iets dat] direct en duurzaam met de aarde is verbonden en betreedbaar en afsluitbaar is.</i> </p>
<p> Dit is duidelijk een onterechte interpretatie: een document is niet duurzaam met de aarde verbonden en niet betreedbaar.</p>
</section>
<section id='WatGaatFout'>
<h3>Waar ontstaat het misverstand?</h3>
<p> Wat in dit specifieke geval fout gaat is dat in IMBAG geen onderscheid wordt gemaakt tussen het Pand (het ding dat buiten staat en waar regen op kan vallen) en de documentatie dan wel registratie van dat ding. Dit onderscheid is in <a>UML</a>, en traditionele <a>object-oriëntatie</a> vaak niet nodig of niet relevant. Namelijk: alles wat in een systeem staat is al een representatie (documentatie) van iets in de werkelijkheid.</p>
<p> In het algemeen kunnen we zeggen dat een UML klasse een blauwdruk geeft voor de verzameling van eigenschappen en gedragingen van een instantie. Vaak betekent dit dat overerving in UML ook een semantische overerving betreft, maar niet per definitie. De UML specificatie lijkt dit te erkennen. Onder het kopje generalisatie (sectie 9.2.3.2) staat 'Type conformance' als speciaal geval genoemd: </p>
<p><i>Type conformance means that if one Type conforms to another, then any instance of the first Type may be used as the value of a TypedElement whose type is declared to be the second Type. A Classifier is a Type, and conforms to itself and to all of its generalizations.</i>[[uml]]</p>
<p> Dus enkel in het geval dat een UML superClass voldoet aan type conformance, is de superClass relatie naar de rdfs:subClassOf relatie te vertalen. Helaas is in de meeste UML modellen niet aangeduid of het daar waar de superClass relatie is toegepast, het daadwerkelijk ook om type conformance gaat. Het is dus aan degene die de transformatie uitvoert om dit te interpreteren.</p>
<p> Dit verschijnsel hint op hoe OO en Linked Data verschillend naar informatie kijken. In OO declareer je een ding door te stellen 'deze auto heeft 4 deuren': Het vaststellen van het bestaan van een entiteit is onlosmakelijk verbonden van de class die geïnstantieerd wordt. In de Linked Data wereld wordt een ding gedeclareerd door te stellen 'er is een ding , dat ding van het type auto en dat ding heeft 4 deuren': de (mogelijk meervoudige, of juist volledig afwezige) classificering van een entiteit volgt pas nadat het bestaan van de entiteit is vastgesteld. Linked Data stelt ons in staat om op een later tijdstip vast te stellen dat 'dit ding is van het type speelgoed. </p>
</section>
<aside class="note">
<h3>Consequenties voor NEN 3610</h3>
<p>Er moet opnieuw gekeken worden naar de regels en aanbevelingen in NEN 3610:2011 over het hanteren van superklassen. In de basis hanteert NEN 3610 de superClass relatie voor type conformance. Echter wordt in NEN 3610 sectormodellen regelmatig het modelleerpatroon gevolgd dat we in IMBAG tegenkwamen: het hanteren van een abstracte superklasse die de kenmerken van alle objecten in een registratie bevat, die overerft worden door alle subklassen. Hier moet wellicht een regel of aanbeveling over worden opgenomen in NEN3610, die dit bijvoorbeeld ontraadt voor conceptuele informatiemodellen. </p>
<p>NEN 3610:2011 zegt niets over meervoudige overerving (waarbij een klasse meerdere superClass relaties heeft). Het zou nuttig zijn om hier wel iets over op te nemen, waarbij kan worden aangegeven dat dit in Linked Data geen probleem is. </p>
</aside>
</section>
<!-- Sectie 5.7 -->
<section id='basisprincipes-referentiedata'>
<h2>Referentiedata</h2>
<!-- 1 zin uitleg wat we met referentiedata bedoelen toevoegen -->
<p>Referentiedata komt in informatiemodellen doorgaans voor als een enumeratie of codelijst, maar soms ook in de vorm van attributen of complexe <a>datatypen</a>. Referentiedata is een goede indicator van data die met elkaar kan worden verbonden, want het is een manier om verschillende datasets aan elkaar te koppelen of een bepaalde categorisering aan te brengen over verschillende datasets. Belangrijk om je te realiseren is dat wat voor de één referentiedata is die best in een codelijstje kan, voor de ander de data zelf is. Ofwel, referentiedata = link naar andere data.</p>
<p>In een Linked Data wordt referentiedata dan ook nooit gemodelleerd als een tekstueel veld (literal). In Linked Data is elke afzonderlijke referentiewaarde een verwijzing naar een resource, uitgedrukt met een IRI. Vaak betreft dit referentiedata die in een ander systeem wordt bijgehouden. Indien daarbij al gebruik wordt gemaakt van Linked Data, kan direct gebruik worden gemaakt van de IRI die in dit systeem wordt gebruikt. Indien dit niet het geval is, dan kan in het eigen systeem een IRI worden gmunt voor de betreffende referentiedata. Elementen als code en weergavenaam worden dan als eigenschappen bij de referentiedata gemodelleerd. Vaak wordt daarbij gebruik gemaakt van de SKOS vocabulaire.</p>
<aside class="example">
<p>In het informatiemodel Golfbaan (IMGolf) bestaat een enumeratie die het type hindernis omschrijft, met twee waarden: </p>
<ul>
<li>waterpartij</li>
<li>bunker</li>
</ul>
<p>Voor de use case van IMGolf was het blijkbaar niet nodig om hier zelfstandige klassen van te maken: van beide categorieën worden dezelfde eigenschappen vastgelegd en meer detailniveau was niet nodig. In een ander informatiemodel, dat bijvoorbeeld de informatie modelleert voor beheerders van golfbanen, kunnen Waterpartij en Bunker heel goed zelfstandige klassen zijn, gemodelleerd als subklasse van Hindernis, met eigenschappen die nodig zijn voor het beheer van waterpartijen en bunkers. Denk bijvoorbeeld aan het soort zand dat gebruikt is in de bunker. Het kan ook goed zijn dat de beheerder de volumes van deze objecten nodig heeft en dus een 3D geometrie beheert in plaats van de vlakgeometrie uit IMGolf. Soorten zand kunnen bovendien weer zelfstandige objecten zijn in een derde context...</p>
</aside>
<aside class="note">
<h3>Consequenties voor NEN 3610</h3>
<p>Ter overweging voor NEN 3610 is het opnemen van een aanbeveling over referentiedata. Referentiedata zijn links naar andere datasets. Als referentiedata refereert naar entiteiten, modelleer dan die entiteiten. Rationale: Wanneer deze entiteiten ook als Linked Data beschikbaar komen, is integratie van de gegevens eenvoudig.</p>
<p>Gebruik bijvoorbeeld <a>blank nodes</a> of interne URI's (URN's of UUID), om de data voorlopig te representeren als het externe data betreft. Als het interne data betreft, munt dan http <a>IRIs</a>. Als referentiedata refereert naar concepten die enkel nodig zijn voor categorisering, gebruik dan SKOS. </p>
</aside>
</section>
<!-- Sectie 5.8 -->
<section id='basisprincipes-vocabulaires'>
<h2>Hergebruik van bestaande vocabulaires</h2>
<p>Linked Data maakt gebruik van bestaande, al dan niet gestandaardiseerde <a>vocabulaires</a> (zoals bv SKOS, FOAF, DCAT, etc.), omwille van de interoperabiliteit. Je kunt klassen en eigenschappen, die al in bestaande vocabulaires gedefinieerd zijn, vrijelijk met elkaar en met je eigen vocabulaire combineren, en je data wordt meer interoperabel hoe meer je dit doet: iedereen kan immers begrijpen wat je bedoelt als je bekende vocabulaires gebruikt.</p>
<aside class="note">
<h3>Consequenties voor NEN 3610</h3>
<p>In NEN 3610 kan een aanbeveling en praktische methode worden toegevoegd over het relateren van UML klassen en eigenschappen aan corresponderende klassen en eigenschappen in bestaande Linked Data vocabulaires.</p>
</aside>
</section>
</section>
<!-- Hoofdstuk 6 -->
<section id='nen3610ld'>
<h1>De NEN 3610 representatie in Linked Data</h1> (normatief)
<p>NEN 3610 beschrijft algemene regels voor het opstellen van een <a>UML</a> informatiemodel, standaard modelleerconstructies en een semantisch model. In dit hoofdstuk worden deze regels, constructies en het semantisch model uitgedrukt in <a>RDF</a>.</p>
<p>Deze RDF representatie wordt expliciet <b>niet</b> gepositioneerd als nieuwe standaard. Het betreft de RDF representatie van de bestaande NEN 3610 standaard [[NEN3610]], waarbij zoveel mogelijk gebruik wordt gemaakt van standaard RDF vocabulaires. Dit hoofdstuk is normatief: de genoemde URI's zijn de normatief te gebruiken URI's voor NEN 3610 elementen. De inhoud van de ontologie zelf is geen onderdeel van dit hoofdstuk en ook niet normatief: de inhoud is een één-op-één kopie van de tekst uit de NEN 3610 standaard zelf. Mochten daarbij kopieerfouten zijn gemaakt, dan is de NEN 3610 tekst leidend.</p>
<p>De NEN 3610 representatie in RDF bestaat uit de volgende onderdelen:</p>
<ul>
<li><i>Verwijzingen</i>: beschrijving van de normatieve en bibliografische verwijzingen die in de NEN 3610 standaard worden gebruikt. Als vocabulaire wordt met name Dublin Core gebruikt.</li>
<li><i>Begrippen</i>: termen en definities zoals beschreven in de NEN 3610 standaard, met name uit hoofdstuk 3 en 7. Als vocabulaire wordt met name <a>SKOS</a> gebruikt.</li>
<li><i>Klassen en eigenschappen</i>: de klassen en eigenschappen zoals beschreven in de NEN 3610 standaard, hoofdstuk 7. Als vocabulaire wordt met name <a>RDFS</a> en <a>OWL</a> gebruikt.</li>
<li><i>Gegevensregels</i>: regels met betrekking tot het gebruik van bovenstaande klassen en eigenschappen in een geo-Linked Data dataset, afgeleid uit de gegevensregels zoals beschreven in de NEN 3610 standaard, hoofdstuk 7. Als vocabulaire wordt <a>SHACL</a> gebruikt.</li>
</ul>
<!-- Sectie 6.1 -->
<section id='nen3610ld-verwijzingen'>
<h2>Verwijzingen</h2>
<p>Hoofdstuk twee van de NEN 3610 standaard geeft de normatieve verwijzingen naar andere standaarden. Daarnaast kent de standaard nog bibliografische verwijzingen en verwijzen we vanuit het Linked Data model terug naar de NEN 3610 standaard zelf.</p>
<p>Elk van deze verwijzingen zijn opgenomen in het NEN 3610 Linked Data model, zodat je ook kan verwijzen naar documenten die niet op het web staan. Bij het terugverwijzen naar de standaard, verwijzen we precies naar de sectie in de standaard. Alleen die onderdelen die we ook daadwerkelijk gebruiken als bron zijn opgenomen.</p>
<p>Alle URI's voor verwijzingen beginnen met <code>http://definities.geostandaarden.nl/nen3610/id/document/</code></p>
<p>Een volledig overzicht is te vinden op: <a href="https://definities.geostandaarden.nl/doc/referenties/nen3610">https://definities.geostandaarden.nl/doc/referenties/nen3610</a>. Een volledige <a>turtle</a> download is <a href="https://geonovum.github.io/NEN3610-Linkeddata/NEN3610-LD/referenties.ttl">hier</a> te vinden.</p>
<!--
<p>Een volledige <a>turtle</a> download is te vinden op: <a href="http://definities.geostandaarden.nl/nen3610/id/documenten.ttl">http://definities.geostandaarden.nl/nen3610/id/documenten.ttl</a></p>
-->
<p>De volgende vocabulaires zijn gebruikt:</p>
<table>
<tbody>
<tr>
<th>Prefix</th>
<th>Namespace</th>
<th>Vocabulaire</th>
</tr>
<tr>
<td>rdf</td>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
<td><a href="https://www.w3.org/TR/rdf11-primer">Resource Description Framework 1.1</a></td>
</tr>
<tr>
<td>rdfs</td>
<td>http://www.w3.org/2000/01/rdf-schema#</td>
<td><a href="https://www.w3.org/TR/rdf-schema">RDF Schema 1.1</a></td>
</tr>
<tr>
<td>dc</td>
<td>http://purl.org/dc/elements/1.1/</td>
<td><a href="http://www.dublincore.org/documents/dcmi-terms">Dublin Core (elements)</a></td>
</tr>
<tr>
<td>dcterms</td>
<td>http://purl.org/dc/terms/</td>
<td><a href="http://www.dublincore.org/documents/dcmi-terms">Dublin Core (terms)</a></td>
</tr>
</tbody>
</table>
<p>We maken gebruik van de volgende eigenschappen en klassen uit deze vocabulaires:</p>
<table>
<tbody>
<tr>
<th>Term</th>
<th>Gebruik</th>
</tr>
<tr>
<td>dcterms:BibliographicResource</td>
<td>Elke verwijzing is een voorkomen van de klasse dcterms:BibliographicResource, een boek, een artikel of een andere brondocument.</td>
</tr>
<tr>
<td>rdf:type</td>
<td>Geeft het type aan van de verwijzing, in ons geval altijd dctypes:Text</td>
</tr>
<tr>
<td>rdfs:label</td>
<td>Elke Linked Data resource heeft een voor mensen leesbaar label. Dit is de naam van de verwijzing zelf, zoals gebruikt in de standaard</td>
</tr>
<tr>
<td>dc:title</td>
<td>De titel van de verwijzing, de volledig uitgeschreven titel van de verwijzing zoals opgenomen in de standaard</td>
</tr>
<tr>
<td>dcterms:isPartOf</td>
<td>Voor verwijzingen naar secties, nemen we ook een relatie op tussen de sectie en zijn bovenliggende sectie (zo is sectie 7.1 onderdeel van hoofdstuk 7, en hoofdstuk 7 weer onderdeel van de standaard NEN 3610:2011 als geheel)</td>
</tr>
</tbody>
</table>
</section>
<!-- Sectie 6.2 -->
<section id='nen3610ld-begrippen'>
<h2>Begrippen</h2>
<p>Hoofdstuk drie van de NEN 3610 standaard geeft de termen en definities die gelden voor toepassen van de NEN 3610 standaard. Elke term en definitie is in het NEN 3610 Linked Data model opgenomen als skos:Concept.</p>
<p>Hoofdstuk zeven van de NEN 3610 standaard beschrijft de basismodellen, in het bijzonder wordt in sectie 7.3 het semantisch model beschreven. Dit model geeft aanvullende terminologie en definities. Ook deze zijn in het NEN 3610 Linked Data model opgenomen als skos:Concept.</p>
<p>De URI voor het begrippenkader zelf begint met <code>http://definities.geostandaarden.nl/id/begrippenkader/</code>.</p>
<p>Alle URI's voor begrippen beginnen met <code>http://definities.geostandaarden.nl/nen3610/id/begrip/</code>.</p>
<p>Een volledige beschrijving is te vinden op: <a href="https://definities.geostandaarden.nl/doc/begrippenkader/nen3610?term=">https://definities.geostandaarden.nl/doc/begrippenkader/nen3610</a>. Een volledige <a>turtle</a> download is <a href="https://geonovum.github.io/NEN3610-Linkeddata/NEN3610-LD/begrippen.ttl">hier</a> te vinden.</p>
<p>De volgende <a>vocabulaires</a> zijn gebruikt:</p>
<table>
<tbody>
<tr>
<th>Prefix</th>
<th>Namespace</th>
<th>Vocabulaire</th>
</tr>
<tr>
<td>rdf</td>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
<td><a href="https://www.w3.org/TR/rdf11-primer">Resource Description Framework 1.1</a></td>
</tr>
<tr>
<td>rdfs</td>
<td>http://www.w3.org/2000/01/rdf-schema#</td>
<td><a href="https://www.w3.org/TR/rdf-schema">RDF Schema 1.1</a></td>
</tr>
<tr>
<td>dcterms</td>
<td>http://purl.org/dc/terms/</td>
<td><a href="http://www.dublincore.org/documents/dcmi-terms">Dublin Core (terms)</a></td>
</tr>
<tr>
<td>skos</td>
<td>http://www.w3.org/2004/02/skos/core#</td>
<td><a href="https://www.w3.org/TR/skos-primer">Simple Knowledge Organization System</a></td>
</tr>
</tbody>
</table>
<p>We maken gebruik van de volgende eigenschappen en klassen uit deze vocabulaires:</p>
<table>
<tbody>
<tr>
<th>Term</th>
<th>Gebruik</th>
</tr>
<tr>
<td>skos:ConceptScheme</td>
<td>Elke begrip is onderdeel van het NEN 3610 begrippenkader. Dit begrippenkader is van het type skos:ConceptScheme.</td>
</tr>
<tr>
<td>skos:Concept</td>
<td>Elke begrip is van het type skos:Concept. Een begrip bestaat uit een term en zijn definitie.</td>
</tr>
<tr>
<td>rdf:type</td>
<td>Geeft het type aan van het begrip (skos:Concept) of begrippenkader (skos:ConceptScheme).</td>
</tr>
<tr>
<td>rdfs:label</td>
<td>Elke Linked Data resource heeft een voor mensen leesbaar label. Dit is de term waarmee naar het begrip wordt verwezen, of de naam van het begrippenkader</td>
</tr>
<tr>
<td>skos:prefLabel</td>
<td>De voorkeursterm om naar het begrip te verwijzen. Meestal is zowel een term in het Nederlands als in het Engels opgegeven.</td>
</tr>
<tr>
<td>skos:altLabel</td>
<td>Een alternatieve term, synoniem voor het begrip.</td>
</tr>
<tr>
<td>skos:inScheme</td>
<td>Geeft aan tot welk begrippenkader het begrip behoort. In ons geval altijd het NEN 3610 begrippenkader.</td>
</tr>
<tr>
<td>skos:definition</td>
<td>De definitie van het begrip, zoals beschreven in de standaard.</td>
</tr>
<tr>
<td>skos:scopeNote</td>
<td>Een toelichting, voor zover aanwezig in de standaard.</td>
</tr>
<tr>
<td>skos:editorialNote</td>
<td>Een redactionele opmerking, waarin de rationale is opgenomen wat de reden is voor het op deze wijze beschrijven van het betreffende begrip</td>
<tr>
<td>dcterms:source</td>
<td>De verwijzing naar een brondocument waaruit de definitie is gehaald. In ieder geval wordt altijd een verwijzing opgegeven naar de sectie in de originele standaard. In enkele gevallen wordt in de standaard zelf ook nog verwezen naar een andere bron. In dit geval is deze verwijzing ook opgenomen.</td>
</tr>
<tr>
<td>skos:broader</td>
<td>Een bovenliggend, algemener begrip. Met behulp van deze eigenschap wordt de hierarchie in het semantisch model uitgewerkt (zo is een Geo-object een breder, algemener begrip dan een Gebouw)</td>
</tr>
<tr>
<td>skos:related</td>
<td>Een expliciete verwijzing naar een ander begrip, voor zover dit uit de definitie blijkt</td>
</tr>
</tbody>
</table>
</section>
<!-- Sectie 6.3 -->
<section id='nen3610ld-ontologie'>
<h2>Klassen en eigenschappen</h2>
<p>Hoofdstuk zeven van de NEN 3610 standaard beschrijft de basismodellen. Het geeft de klassen en eigenschappen die gebruikt kunnen worden in informatiemodellen die gebaseerd zijn op de NEN 3610 standaard.</p>
<p>Voor het realiseren van Linked Data modellen die op de NEN 3610 standaard zijn gebaseerd, is dit het meest belangrijke onderdeel. Voor Linked Data geldt dat zoveel mogelijk gebruik wordt gemaakt van algemeen gebruikte <a>vocabulaires</a> en <a>ontologieën</a>. Met dit onderdeel van het NEN 3610 Linked Data model, wordt een dergelijke ontologie gepubliceerd.</p>
<p>Modelleurs van Linked Data modellen die gebaseerd zijn op NEN 3610 MOETEN gebruik maken van deze klassen en eigenschappen, door rechtstreeks deze klassen en eigenschappen te gebruiken, of door aan te geven dat een eigen klasse of eigenschap een subklasse c.q. subeigenschap is van een klasse c.q. eigenschap uit deze ontologie.</p>
<p>De URI voor zowel klassen als eigenschappen begint met <code>http://definities.geostandaarden.nl/def/nen3610#</code>.</p>
<p>Daarbij geldt dat de verwijzing naar een klasse altijd begint met een hoofdletter (UpperCamelCase) en de verwijzing naar een eigenschap altijd begint met een kleine letter (lowerCamelCase)</p>
<p>Een volledige beschrijving is te vinden op: <a href="https://definities.geostandaarden.nl/def/nen3610">https://definities.geostandaarden.nl/def/nen3610</a></p>
<p>De volgende vocabulaires zijn gebruikt:</p>
<table>
<tbody>
<tr>
<th>Prefix</th>
<th>Namespace</th>
<th>Vocabulaire</th>
</tr>
<tr>
<td>rdf</td>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
<td><a href="https://www.w3.org/TR/rdf11-primer">Resource Description Framework 1.1</a></td>
</tr>
<tr>
<td>rdfs</td>
<td>http://www.w3.org/2000/01/rdf-schema#</td>
<td><a href="https://www.w3.org/TR/rdf-schema">RDF Schema 1.1</a></td>
</tr>
<tr>
<td>dcterms</td>
<td>http://purl.org/dc/terms/</td>
<td><a href="http://www.dublincore.org/documents/dcmi-terms">Dublin Core (terms)</a></td>
</tr>
<tr>
<td>skos</td>
<td>http://www.w3.org/2004/02/skos/core#</td>
<td><a href="https://www.w3.org/TR/skos-primer">Simple Knowledge Organization System</a></td>
</tr>
<tr>
<td>owl</td>
<td>http://www.w3.org/2002/07/owl#</td>
<td><a href="https://www.w3.org/TR/owl-primer">Web Ontology Language</a></td>
</tr>
</tbody>
</table>
<p>We maken gebruik van de volgende eigenschappen en klassen uit deze <a>vocabulaires</a>:</p>
<table>
<tbody>
<tr>
<th>Term</th>
<th>Gebruik</th>
</tr>
<tr>
<td>owl:Ontology</td>
<td>Alle klassen en eigenschappen zijn onderdeel van een <a>ontologie</a>, in ons geval de NEN 3610 Vocabulaire</td>
</tr>
<tr>
<td>owl:Class</td>
<td>Alle klassen uit de NEN 3610 standaard zijn getypeerd als owl:Class</td>
</tr>
<tr>
<td>owl:DatatypeProperty</td>
<td>Alle attribuut-eigenschappen uit de NEN 3610 standaard zijn getypeerd als owl:DatatypeProperty</td>
</tr>
<tr>
<td>owl:ObjectProperty</td>
<td>Alle associatie-eigenschappen (associaties tussen twee klassen) uit de NEN 3610 standaard zijn getypeerd als owl:ObjectProperty</td>
</tr>
<tr>
<td>rdf:type</td>
<td>Geeft het type aan van de vocabulaire (owl:Ontology), klasse (owl:Class) of eigenschap (owl:DatatypeProperty of owl:ObjectProperty)</td>
</tr>
<tr>
<td>rdfs:label</td>
<td>Elke Linked Data resource heeft een voor mensen leesbaar label. Dit is de term waarmee naar de vocabulaire, klasse of eigenschap wordt verwezen in het model.</td>
</tr>
<tr>
<td>rdfs:subClassOf</td>
<td>Geeft aan dat een klasse een subklasse is van een andere klasse. Dit wordt met name voor het semantisch model toegepast. Zo is een Gebouw een subklasse van een Geo-object</td>
</tr>
<tr>
<td>dcterms:subject</td>
<td>Geeft de relatie tussen een klasse uit het basismodel, en een begrip uit het NEN 3610 begrippenkader. Zo wordt de definitie van een klasse opgenomen bij het begrip, en volstaat daarmee een verwijzing naar het begrip voor de definitie van de klasse</td>
</tr>
<tr>
<td>skos:definition</td>
<td>Voor eigenschappen waarvoor geen overeenkomstig begrip is gedefinieerd, wordt hiermee de definitie van de eigenschap beschreven</td>
</tr>
<tr>
<td>skos:scopeNote</td>
<td>Voor eigenschappen waarvoor geen overeenkomstig begrip is gedefinieerd, kan hiermee een toelichting op de definitie van de eigenschap worden beschreven</td>
</tr>
</tbody>
</table>
<p>Om de NEN 3610 klassen een zo breed mogelijk toepassingsgebied te geven, verbinden we de NEN 3610 klassen met andere standaarden. Uitgangspunt daarbij is dat de NEN 3610 klassen specifieker zijn dan de standaarden waarmee we verbinden. Op deze wijze kan een model uitgedrukt in NEN 3610 ook "gelezen" worden in een bredere context:</p>
<table>
<tbody>
<tr>
<th>Prefix</th>
<th>Namespace</th>
<th>Vocabulaire</th>
</tr>
<td>geosparql</td>
<td>http://www.opengis.net/ont/geosparql#</td>
<td><a href="http://www.opengeospatial.org/standards/geosparql">Geographic Query Language for RDF Data</a></td>
</tr>
<tr>
<td>schema</td>
<td>http://schema.org/</td>
<td><a href="https://schema.org">Schema.org</a></td>
</tr>
</tbody>
</table>
<p>Voor de verbinding van de NEN 3610 klassen met de internationale standaarden, verbinden we het NEN 3610 model met de <a>OGC</a> GeoSparql Linked Data vocabulaire. We geven daarbij aan dat een nen3610:GeoObject een subklasse is van de geosparql:Feature klasse.</p>
<p>Voor de aansluiting met search engines, verbinden we het NEN3610 model met schema.org. Daarbij zijn twee classes relevant: <a href="https://schema.org/Place">schema:Place</a> en <a href="https://schema.org/AdministrativeArea">schema:AdministrativeArea</a>. Niet elk nen3610:GeoObject is echter een schema:Place. Zo kan een trein wel gezien worden als een nen3610:GeoObject, maar niet als een schema:Place. Alle huidige NEN 3610 specialisaties van nen3610:GeoObject kunnen echter wel gezien worden als een rdfs:subClassOf schema:Place, waarbij een nen3610:RegistratiefGebied gezien kan worden als een rdfs:subClassOf schema:AdministrativeArea.</p>
<p>De aansluiting met de Europese Core Vocabularies [[semic-core]], in het bijzonder de Core Location Vocabulary verloopt niet rechtstreeks met een NEN 3610 klasse, maar indirect via geosparql. De Core Location Vocabulary gaat over adressen en geometrieën, terwijl NEN 3610 gaat over geo-objecten: dingen met een geometrie. Doordat we een geo-object hebben gedefinieerd als een speciaal soort <code>geosparql:Feature</code>, en een dergelijk feature een geometrie kent (<code>geosparql:Geometry</code>), is daarmee de aansluiting gemaakt.</p>
</section>
<!-- Sectie 6.4 -->
<section id="nen3610-gegevensregels">
<h2>RDF Gegevensregels</h2>
<p>Bij het opstellen van een Linked Data model op basis van NEN 3610 dient de opsteller zich te houden aan de gegevensregels in deze sectie. Deze gegevensregels zijn afgeleid van de gegevensregels uit sectie 7.2 van de NEN 3610 standaard. De gegevensregels zijn toegesplitst op de RDF structuur van de standaard, die vanwege de aard van Linked Data op punten anders is dan de UML standaard.</p>
<!-- Sectie 6.4.1 -->
<section id="nen3610id">
<h3>URI template en NEN3610ID</h3>
<p>Indien een instantie van een klasse uniek identificeerbaar moet zijn binnen het domein van NEN 3610 dan moet deze klasse de eigenschap <code>nen3610:identificatie</code> hebben die verwijst naar een object met de structuur van een NEN3610ID shape. Dit is afgebeeld in onderstaand figuur en opgenomen bij de gegevensregels die als afzonderlijk bestand gebruikt kunnen worden om te valideren of een model voldoet aan de NEN3610 gegevensregels: <a href="media/ttl/nen3610-shapes.ttl">nen3610-shapes.ttl</a></p>
<p><img src="media/gegevensregel-identificatie.png" alt="NEN3610 identificatie"/></p>
<p>Omdat elk geo-object in RDF sowieso een unieke identificatie heeft op basis van een URI, is in RDF het NEN3610ID feitelijk redundant. Het is opgenomen om compliant te zijn aan de originele standaard en om een mogelijkheid te hebben om expliciet de NEN3610ID structuur over te nemen. De URI dient afgeleid te zijn van het NEN3610ID. Indien de <code>namespace</code>-eigenschap uit de NEN 3610-identificatie al een URI-namespace is, kan als het sjabloon <code>{namespace}{lokaalID}{versie}</code> worden gebruikt. Indien dit niet het geval is, dan mag gebruik worden gemaakt van een http-prefix zodat een correcte URI ontstaat, bijvoorbeeld conform het sjabloon <code>http://{domeinnaam}{optioneel-pad}/id/geo-object/{namespace}{lokaalID}{versie}</code>. De <code>rdf:value</code> mag gebruikt worden om het NEN3610ID als één string te beschrijven. Daarbij dient de waarde opbouwd te zijn volgens het sjabloon <code>{namespace}{lokaalID}{versie}</code></p>
</section>
<section id="provenance">
<h3>Temporele kenmerken en versies</h3>
In het NEN 3610 UML model wordt geen expliciet onderscheid gemaakt tussen het geo-object zelf (het fenomeen in de werkelijkheid) en de beschrijving van het geo-object (de geregistreerde eigenschappen). Dit leidt ertoe dat eigenschappen van het geo-object, zoals bijvoorbeeld de identificatie, geometrie of een naam in het UML model bij dezelfde klasse staan als de eigenschappen van de registratiemetadata, zoals de versie-eigenschappen beginGeldigheid en eindeGeldigheid. In het Linked Data model zijn deze eigenschappen ondergebracht bij de "eigen" klasse (zie voor meer uitleg hierover secties <a href="#basisprincipes-classificatie">5.3</a> en <a href="#basisprincipes-normalisatie">5.4</a>). Daarbij kunnen we grotendeels gebruiken maken van de standaard <a>PROV-O</a> vocabulaire, zoals is afgebeeld in onderstaand figuur.</p>
<p><img src="media/gegevensregel-provenance.png" alt="NEN3610 provenance, registratie-eigenschappen van objecten"/></p>
<p>Partijen die Linked Data dataset publiceren die gebaseerd zijn op de NEN 3610 standaarden MOETEN gebruik maken van bovenstaand mechanisme indien zij historie willen modelleren conform de betekenis van NEN 3610.</p>
<p>De eigenschappen <code>prov:generatedAtTime</code> en <code>prov:invalidatedAtTime</code> komen daarbij overeen met de formele historie-eigenschappen tijdstipRegistratie en eindRegistratie.</p>
<p>In het model is niet expliciet de levensduur-eigenschappen opgenomen. Deze zijn af te leiden uit de afzonderlijke eigenschappen en uit de optionele relatie tussen GeoObjectRegistraties.</p>
</section>
</section>
<!-- Sectie 6.5 -->
<section id="nen3610-ld-gebruik">
<h2>Gebruik van het NEN 3610 Linked Data model</h2>
<p>Partijen die Linked Data datasets publiceren die gebaseerd zijn op de NEN 3610 standaard MOETEN daarbij de volgende regels in acht nemen:</p>
<!-- Sectie 6.5.1 -->
<section id="nen3610-ld-gebruik-begrippen">
<h3>Maak gebruik van de NEN 3610 begrippen</h3>
<p>Indien een eigen begrippenkader wordt gehanteerd, MOET daarbij verwezen worden naar de NEN 3610 begrippen waar dit van toepassing is. Daarbij MOET gebruik worden gemaakt van de juiste eigenschappen uit de <a>SKOS</a> vocabulaire.</p>
<p>Onderstaand voorbeeld geeft aan hoe een begrip uit IM-Golf op de juiste wijze verwijst naar een NEN 3610 begrip</p>
<pre class='ex-turtle'>
@prefix nen3610-begrip: <http://definities.geostandaarden.nl/nen3610/id/concept/>.
@prefix imgolf-begrip: <http://definities.geostandaarden.nl/imgolf/id/concept/>.
@prefix skos: <http://www.w3.org/2004/02/skos/core#>.
imgolf-begrip:Golfbaan a skos:Concept;
skos:broadMatch nen3610-begrip:FunctioneelGebied;
skos:definition "Een golfbaan is een functioneel gebied waar de sport golf wordt gespeeld."@nl;
.
</pre>
</section>
<!-- Sectie 6.5.2 -->
<section id="nen3610-ld-gebruik-vocabulaire">
<h3>Maak gebruik van de NEN 3610 vocabulaire</h3>
<p>De klassen en eigenschappen die gebruikt worden in de Linked Dataset MOETEN direct of indirect verwijzen naar de klassen en eigenschappen van de NEN 3610 vocabulaire, voor zover van toepassing.</p>
<p>Voor klassen zal meestal gelden dat een subklasse is gedefinieerd, voor eigenschappen ligt meer voor de hand om rechtstreeks gebruik te maken van de NEN 3610 eigenschappen.</p>
<p>Onderstaand voorbeeld geeft aan hoe een voorkomen en een klasse uit IM-Golf op de juiste wijze verwijst naar de NEN 3610 vocabulaire.</p>
<p>In dit voorbeeld is ook de relatie gelegd tussen de klasse <code>imgolf:Golfbaan</code> en het begrip "Golfbaan". Een goede gewoonte is om hiervoor <code>dct:subject</code> te gebruiken.</p>
<p>Tenslotte laat dit voorbeeld ook zien hoe je vanuit eigen data rechtstreeks kunt verwijzen naar data van een ander. Een goede gewoonte is om hiervoor de URI uit de data van de andere te gebruiken als deze beschikbaar is.</p>
<pre class='ex-turtle'>
@prefix nen3610: <http://definities.geostandaarden.nl/def/nen3610#>.
@prefix imgolf: <http://definities.geostandaarden.nl/def/imgolf#>.
@prefix golfbaan: <http://definities.geostandaarden.nl/nen3610/imgolf/voorbeeld/>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix geosparql: <http://www.opengis.net/ont/geosparql#>.
@prefix dct: <http://purl.org/dc/terms/#>.
imgolf:Golfbaan a owl:Class;
rdfs:label "Golfbaan"@nl;
rdfs:subClassOf nen3610:FunctioneelGebied;
dct:subject imgolf-begrip:Golfbaan;
.
imgolf:naam a owl:DatatypeProperty;
rdfs:label "naam"@nl;
rdfs:subPropertyOf rdfs:label
.
golfbaan:KoninklijkeHaagseGenCC a imgolf:Golfbaan;
owl:sameAs <http://brt.basisregistraties.overheid.nl/top10nl/id/functioneel-gebied/128367769>;
geosparql:hasGeometry geometrie:KoninklijkeHaagseGenCC;
imgolf:naam "Koninklijke Haagse Golf en Country Club"@nl;
nen3610:beginGeldigheid "1938"^^xsd:Date
.
</pre>
</section>
</section>
<!-- Sectie 6.6 -->
<section id="metadata">
<h2>Metadata van datasets</h2>
<p>Hoofdstuk 10 van de NEN 3610 behandelt metadata. Onder metadata wordt in deze norm verstaan: informatie die ruimtelijke datasets en datasetseries beschrijft die het mogelijk maakt om deze te zoeken, te evalueren en te gebruiken. Dit is een beperkte definitie omdat hij alleen betrekking heeft op datasets en datasetseries. Metadata moet voldoen aan het Nederlandse profiel op NEN-EN-ISO 19115 voor Geografie.</p>
<p>Voor een Linked Data model betekent dit dat voor metadata gebruik gemaakt moet worden van de [[geodcat-ap]] standaard, de Linked Data invulling voor de ISO 19115 standaard voor het beschrijven van metadata over geometrische datasets.</p>
<p>Concreet betekent dit dat elke dataset of datasetserie als <code>dcat:Dataset</code>-klasse kan worden beschreven, waarbij de metadata wordt geregistreerd via de eigenschappen van instanties van deze klasse.</p>
<p>NEN 3610 geeft geen specifieke versie aan van bovengenoemde standaarden. Concreet betekent dit dat verwacht wordt dat de meest recente standaard wordt gebruikt. Op het moment van schrijven wordt gewerkt aan een vernieuwing van de DCAT standaard en bijbehorende GeoDCAT profiel. Geadviseerd wordt om deze vernieuwing goed te volgen en tijdig over te stappen op de meest recente versie.</p>
</section>
</section>
<!-- Hoofdstuk 7 -->
<section id='transformatie' class="informative">
<h1>Transformatie van een NEN 3610-UML model naar Linked Data</h1>
<!-- Sectie 7.1 -->
<section id='transformatie-doel'>
<h2>Doel van de transformatie en methode</h2>
<p>Het doel van de transformatie voor NEN 3610 gaat er vanuit dat er op dit moment een grote hoeveelheden NEN 3610 UML modellen bestaan, waarvoor het nuttig zou zijn om van deze modellen ook een Linked Data variant te hebben. Indien een dergelijk Linked Data model zou bestaan, zou het mogelijk kunnen zijn om bestaande data conform deze modellen (bijvoorbeeld concrete data over een BAG pand, WOZ object of IMKL netwerk) te transformeren naar hun Linked Data representant.</p>
<p>In de transformatie wordt daarbij dan ook uitgegaan van een UML informatiemodel. Vanuit een modelleringsaanpak zou het echter beter zijn om te beginnen met een gemeenschappelijk model van begrippen, en vervolgens dit model verder uit te werken naar zowel een UML informatiemodel als een Linked Data ontologie. Dit is echter niet het doel geweest van de transformatiestappen die in dit hoofdstuk zijn beschreven.</p>
<section id='correct-versus-juist'>
<h3>Correct versus juist: handmatige vertaling is deels noodzakelijk</h3>
<p>
De methode voor de toe te passen transformatie van een NEN 3610-UML bronmodel naar een Linked Data doelmodel (RDF/OWL/SHACL) bevat een aantal hoofdlijnen. De transformatieregels worden gespecificeerd conform informatie-elementen uit het metamodel van NEN 3610. Het volgt de basiselementen klassen, attributen en associaties en de daaraan gerelateerde stereotypen. Een groot deel van de transformatieregels zijn standaard op te stellen. Hier is ook al veel werk in verricht onder andere te vinden in INSPIRE RDF guidelines [[INSPIRERDF]]. We noemen dit ‘standaard transformatieregels’. Naast deze standaard transformatieregels zijn er nog ‘specifieke transformatieregels’. Deze zijn specifiek omdat ze extra aanvullingen en aanpassingen zijn om er zinvolle Linked Data modellen van te maken. Ze zijn ook specifiek omdat de verschillende modelleerstijlen van Omgevingswet-DSO, de Bouwsector en Stedelijkwater-GWSW-OroX, specifieke aanpassingen vereisen. Voor elk van deze stijlen worden de standaard transformatieregels aangevuld met specifieke regels. Het geheel van standaard – en specifieke transformatieregels geeft voor elke modelleerstijl een handvat om een NEN 3610-UML model om te zetten naar het specifieke NEN 3610-Linked Data doelmodel.
</p>
<figure>
<img src="media/UoD-requirement.png"width="600">
<figcaption>UoD requirement</figcaption>
</figure>
<p>Bovenstaand figuur geeft ons transformatiedoel weer. Zowel een <a>UML</a> model als een <a>RDF</a> model representeren een bepaalde <a>universe of discourse</a> (UoD), het deel van de wereld dat we wensen te beschrijven met ons model. Waarbij het model een vereenvoudigde weergave is van deze werkelijkheid. Ons transformatiedoel is geslaagd als het RDF model dat ontstaat vanuit de transformatie van het UML model een model is van dezelfde UoD als die van het originele UML model.</p>
<p>We verwachten daarbij dat we dit transformatiedoel niet volledig geautomatiseerd kunnen behalen. Daartoe verschillen de uitgangspunten van UML en RDF te veel, zoals beschreven in <a href="#basisprincipes">hoofdstuk 5</a>. We wensen een <i>correct</i> model automatisch te kunnen vertalen, waarna we handmatig tot een <i>juist</i> model kunnen komen:</p>
<ul>
<li>Een <i>correct</i> model betekent dat het RDF model voldoet aan alle constructie-eisen van een RDF model. Het model voldoet aan het <a>metamodel</a> dat we in dit document vaststellen.</li>
<li>Een <i>juist</i> model is een correct model waarbij het RDF model een model is van hetzelfde UoD als het originele UML model.</li>
</ul>
<figure>
<img src="media/correct-en-juist.png" width="600">
<figcaption>Correct vs Juist model</figcaption>
</figure>
</section>
<section id='data-transformatie'>
<h3>Geautomatiseerde data-transformatie</h3>
<p>Op basis van een dergelijk correct en juist model, zal het dan uiteindelijk mogelijk zijn om concrete geometrische data die gebaseerd is op het <a>UML</a> model, om te zetten naar RDF. Deze vertaling zou geautomatiseerd kunnen worden, waarbij zowel het originele UML model, het RDF metamodel en het correct en juiste RDF model, dat afgeleid is van het originele UML model, als input dienen.</p>
<aside class="note">Na vaststelling van deze standaard kan, als een volgende stap, de automatische vertaler geïmplementeerd worden in bijvoorbeeld een XSLT stylesheet die GML data kan omzetten naar Linked Data.</aside>
<figure>
<img src="media/transformatiedoel.png" width="600">
<figcaption>Transformatie van model en data</figcaption>
</figure>
</section>
<section id='roundtrip'>
<h3>Geen roundtrip</h3>
<p>Het doel van de transformatieregels is om hetzelfde UoD te beschrijven. Hiervoor is van belang dat de betreffende informatie hierover wordt overgenomen. Omdat UML en RDF andere uitgangspunten kennen, zal daarbij aan beide kanten informatie noodzakelijk zijn die niet per sé noodzakelijk is aan de andere kant. Hoewel deze informatie opgenomen zou kunnen worden (bijvoorbeeld als onderdeel van een UML profiel of als aanvullende eigenschappen aan de RDF resources), is dit voor de NEN 3610 vertaling niet uitgevoerd. Een roundtrip of volledige transformatie van alle informatie is dan ook niet uitgewerkt. Alleen die informatie wordt getransformeerd die noodzakelijk is om te komen tot een correct en juist model, waarbij voor dat laatste bovendien handmatige stappen noodzakelijk zijn, zoals beschreven in de voorgaande secties.</p>
<p>Het Metamodel Informatie Modellering [[MIM11]] heeft wel tot doel om een volledige transformatie en roundtrip te verzorgen. De uitwerking hiervan heeft gelijk opgelopen met de uitwerking van de NEN 3610 opzet. Het verschil is dat het MIM uitgaat van een eigen metamodel, uitgedrukt in een UML profiel en een RDF ontologie. Hierdoor is het wel mogelijk om een MIM model volledig uit te drukken in UML en in RDF, inclusief een roundtrip transformatie.</p>
<p>Een vergelijkbaar initiatief heeft plaatsgevonden in Vlaanderen. Hier is geen eigen metamodel ontwikkeld, maar wordt de vertaling direct vanuit Enterprise Architect opgezet [[OSLO-EA-RDF]].</p>
</section>
</section>
<!-- Sectie 7.2 -->
<section id='transformatiebron'>
<h2>Bronmodel: NEN 3610 metamodel</h2>
<p>Het bronmodel in de transformatie moet voldoen aan het metamodel achter NEN 3610.</p>
<p>Het NEN 3610 - metamodel omschrijft de metaklassen die gebruikt worden om een informatiemodel op te bouwen. Elke metaklasse is een type informatie-element. De instanties van de metaklassen zijn de benoemde informatie-elementen in een informatiemodel. In het informatiemodel zijn ze te herkennen aan de UML conventies die voor dat element gelden of het specifiek benoemde stereotype (in geel aangegeven). Bij elke metaklasse is opgenomen wat hun eigenschappen zijn. Het metamodel van NEN 3610 volgt het General Feature Model (GFM) van ISO 19109 [[iso-19109-2015]]. Het in het onderstaande UML beschreven metamodel is daar een aanpassing op voor toepassing binnen de context van NEN 3610.
</p>
<figure>
<img src="media/metamodel_attributes.png" width="600">
<figcaption>Metamodel van NEN 3610. Aanpassing op General Feature Model van ISO 19109. In geel de als stereotype opgenomen metaklassen.</figcaption>
</figure>
<section id='nen3610-toelichting'>
<h3>Toelichting op metamodel NEN 3610</h3>
<p>Voor NEN 3610 is <code>Objecttype</code> een abstracte metaklasse. Alle objecttypen (of objectklassen) in NEN 3610 zijn <a>feature type</a>. Een <code>FeatureType</code> is een <code>Objecttype</code> dat geassocieerd is met een locatie. In NEN 3610 vallen die onder het semantische objecttype <code>GeoObject</code>. Een <code>GeoObject</code> heeft dus als stereotype <code>«FeatureType»</code>. Dit is identiek aan de ISO191xx set van standaarden. Een <code>FeatureType</code> heeft 0 of 1 <a>supertypen</a>; 0 of meer eigenschappen (<code>EigenschapType</code>); 0 of meer beperkingen (<code>Constraint</code>). Eigenschappen zijn attributen (<code>AttribuutType</code>) of relaties naar andere objecttypen. Een relatie wordt gerealiseerd door een ‘uitgaande’ associatie met optioneel een naam maar verplicht de rol (<code>Associatierol</code>) van het ‘target objecttype’.</p>
<p>Attributen hebben een waardetype dat door een <a>datatype</a> wordt beschreven. Een <code>DataType</code> is een <code>PrimitiefDatatype</code> (integer, characterstring boolean, gm_surface enz), een <code>Waardelijst</code>, een <code>Union</code> of gewoon een datatype. In het laatste geval is het een complex datatype dat is samengesteld uit één of meer attributen. Een <code>Union</code> faciliteert een keuze van één attribuut uit een lijst van twee of meer. Een <code>Enumeratie</code> is een niet uitbreidbare <code>Waardelijst</code> in de namespace van het model. Een <code>CodeList</code> is een externe lijst waarvan de waarden buiten het model worden beheerd.
</p>
</section>
</section>
<!-- Sectie 7.3 -->
<section id='transformatie-encoding'>
<h2>Transformatie: basisregels - encoding</h2>
<!-- Sectie 7.3.1 -->
<section id='transformatie-encoding-inleiding'>
<h3>Inleiding</h3>
<p>Deze paragraaf bevat de beschrijving van de basisregels en de uitwerking van details voor transformatie van <a>UML</a> constructen naar Linked Data.</p>
<p>Voor de transformatie van een UML model naar Linked Data maken we gebruik van de volgende vocabulaires:</p>
<ul>
<li>RDF</li>
<li>RDFS</li>
<li>OWL</li>
<li>SKOS</li>
<li>SHACL</li>
<li>GeoSparql</li>
</ul>
<p>De reden om te kiezen voor deze <a>vocabulaires</a> is:</p>
<ul>
<li>Internationale standaarden. Deze standaarden zijn op wereldwijde schaal vastgesteld en in gebruik. Het zijn standaarden die door de <a>W3C</a> zijn vastgesteld, en daarmee door de organisatie die het beheer voert over de Linked Data standaarden.</li>
<li>We gebruiken standaarden die specifiek zijn ontworpen voor het doel waar wij ze voor willen inzetten:
<ul>
<li><a>RDF</a>/RDFS/OWL voor het benoemen en typeren van de termen voor klassen (owl:Class), attributen (owl:DatatypeProperty) en relaties (owl:ObjectProperty).</li>
<li><a>RDFS</a>/<a>OWL</a> voor het specificeren van een formele <a>ontologie</a> (door middel van <code>rdfs:range</code> en <code>rdfs:domain</code>, <code>rdfs:subClassOf</code> en <code>owl:Restriction</code>)</li>
<li><a>SKOS</a> voor het opnemen van definities en aanvullende beschrijvingen voor de gebruikte termen</li>
<li><a>SHACL</a> voor het specificeren van de gegevensstructuren en gegevensregels zoals aanwezig in het UML model</li>
</ul>
</li>
<li>De standaarden sluiten goed aan bij de denkwijze binnen <a>UML</a>, waardoor een vergelijking tussen UML en Linked Data "relatief" eenvoudig is.</li>
<li>Het Linked Data principe maakt het mogelijk om de vier genoemde onderdelen (terminologie, ontologie, betekenis en gegevensregels) van elkaar te onderscheiden en afzonderlijk te beheren. Dit maakt het mogelijk om specifieke aanpassingen te doen, mocht de opzet in het UML model anders geïnterpreteerd moeten worden dan uit een automatische vertaling mogelijk is. We verwachten dat dit met name zal spelen bij de formele ontologie.</li>
</ul>
<p>Specifieke aandacht is nodig voor de vertaling van het UML enerzijds naar <a>RDFS</a> en <a>OWL</a> formele ontologie, en anderzijds naar SHACL gegevensregels.</p>
<p>In beginsel berust de vertaling naar de formele ontologie en naar de SHACL gegevensregels op dezelfde UML onderdelen. Zo worden UML cardinaliteiten enerzijds vertaalt naar owl:Restrictions, en anderszijds naar sh:PropertyShapes. Je zou kunnen stellen dan één van de twee voldoende is. Echter, waar in UML het onderscheid tussen formele ontologie en gegevensregels vaak impliciet is, bestaan hier in Linked Data expliciet verschillende vocabulaires voor.</p>
<p>Door beide varianten te realiseren, bestaat de mogelijkheid voor de afnemer om een keuze te maken welke variant het beste past bij het originele UML model en de specifieke use case.</p>
<p>Hieronder benoemen we enkele verschillen en overeenkomsten tussen UML, SHACL en OWL:</p>
<ul>
<li>Zowel UML als SHACL gaan uit van een <a>closed-world assumption</a>, waarbij het model <i>beperkt</i> wat mogelijk is. Dit in tegenstelling tot OWL dat uitgaat van een <a>open-world assumption</a>, waarbij het model <i>afleidt</i> wat mogelijk is.</li>
<li>Zowel <code>owl:maxCardinality 1</code> als <code>sh:maxCount 1</code> komen overeen met de x..1 cardinaliteit in UML. Er bestaat echter ook een verschil. Mocht bijvoorbeeld bij een eigenschap "is-getrouwd-met" gelden dat een persoon maar met één ander persoon getrouwd mag zijn, en in de database treffen we de waarden "Piet is getrouwd met Marie" en "Klaas is getrouwd met Marie", dan veronderstelt de owl restrictie dat Piet en Klaas dezelfde personen zijn, terwijl de SHACL restrictie aangeeft dat de dataset niet voldoet aan de betreffende gegevensregel.</li>
<li>Eenzelfde verschil speelt rondom het gebruik van <code>rdfs:range</code> en <code>rdfs:domain</code>. Indien bijvoorbeeld een property <code>ex:naam</code> wordt geïntroduceerd met <code>rdfs:range</code> <code>ex:Persoon</code>, dan betekent dit dat als een <a>subject</a> een <code>ex:naam</code> heeft, het een persoon is (zelfs als een dergelijke naam is gegeven aan iets dat eigenlijk een schip is). In geval van SHACL zou een PropertyShape gespecifieerd worden die stelt dat de eigenschap <code>ex:naam</code> alleen maar gebruikt mag worden bij de klasse <code>Persoon</code>.</li>
<li>OWL is ontworpen voor classificatie-doeleinden (afleidingen), terwijl SHACL ontworpen is voor data-validatie. Zie <a href="http://spinrdf.org/shacl-and-owl.html">shacl and owl</a> voor een uitgebreide vergelijking.</li>
<li>Het gebruik van SHACL maakt het mogelijk om Linked Data structuren te valideren (zie bijvoorbeeld de <a href="http://shacl.org/playground">SHACL playground validator.</a></li>
<li>Het gebruik van OWL maakt het mogelijk de kennis in de formele ontologie te gebruiken om nieuwe informatie af te leiden uit bestaande data. Zie <a href="https://www.cs.vu.nl/~guus/public/owl-restrictions/">owl restrictions</a> voor een goede introductie.</li>
</ul>
<p>Het belangrijkste criterium voor het gebruik van SHACL versus OWL formele ontologie ligt hiermee vooral in het beoogde doel van UML:</p>
<ul>
<li>als vastlegging van formele kennis over de ontologie te gebruiken voor het afleiden van nieuwe informatie, of</li>
<li>als vastlegging van gegevensregels over de informatie die mag worden vastgelegd en mag worden uitgewisseld in berichten.</li>
</ul>
<p>Vaak is dit onderscheid niet zo scherp te maken, waardoor wij beide varianten aanbieden. De visualisaties die in dit document staan van de <a>RDF</a> modellen (SHACL en/of OWL) zijn op beide manieren te lezen: als restricties, of als afleidingen.</p>
</section>
<!-- Sectie 7.3.2 -->
<section id="basismetamodel">
<h3>Basis doelmodel: metamodel op basis van <a>W3C</a> standaarden</h3>
<figure>
<img src="media/metamodel_linkeddata.png" height="908">
<figcaption>Metamodel van NEN 3610 uitgedrukt als Linked Data</figcaption>
</figure>
<p>De kleuren in het figuur geven de onderdelen aan van het Linked Data metamodel. Het lichtgele onderdeel betreft de kern van het Linked Data metamodel. De overige onderdelen betreffen uitbreidingen op deze kern die afhankelijk van de situatie relevant zullen zijn. Dit wordt hieronder verder toegelicht.</p>
<p>In de Linked Data community is het gebruikelijk om voor een model zoveel mogelijk gebruik te maken van vocabulaires die reeds breed worden toegepast door anderen. Op deze manier wordt de interoperabiliteit vergroot. Voor het <a>metamodel</a> NEN 3610 maken we gebruik van bestaande en wereldwijd veelvuldig toegepaste standaarden. Deze standaarden zijn in beheer bij de <a href="https://www.w3.org">W3C</a>, de organisatie die de webstandaarden beheert. Voor ons metamodel gaat het daarbij om de volgende standaarden:
</p>
<table>
<tbody>
<tr>
<th>Prefix</th>
<th>Standaard</th>
<th>Namespace</th>
</tr>
<tr>
<td>rdf</td>
<td><a href="http://www.w3.org/TR/rdf11-primer/">Resource description framework</a></td>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
</tr>
<tr>
<td>rdfs</td>
<td><a href="http://www.w3.org/TR/rdf-schema/">RDF schema</a></td>
<td>http://www.w3.org/2000/01/rdf-schema#</td>
</tr>
<tr>
<td>owl</td>
<td><a href="http://www.w3.org/TR/owl2-overview/">Web ontology language</a></td>
<td>http://www.w3.org/2002/07/owl#</td>
</tr>
<tr>
<td>sh</td>