GWSW.OroX Uitwisselprotocol

GWSW.OroX Uitwisselprotocol Een handreiking voor applicatiebouwers

Datum: Opdrachtgever: Opsteller:

20160421 Stichting RIONED Marinus Vonhof (Grontmij), in samenwerking met Hendrik Kingma (Riodesk) en Frank Zwiers (Antea Group)

Versiegeschiedenis: 20160421: relatie :hasClassId vervalt (alleen naam als concept-identificatie in OroX) 20160408: GWSW-Rib, hoofdstuk 6.3 aangepast 20160205: GWSW-Rib, tabel 6.3 aangepast 20160130: GWSW-Rib, aanscherping bij test GWSW Browser 20151116: GWSW-Bas, aanscherping OroX-inrichting. Vraagpunten resteren, zie gele kaders 20151026: GWSW-Rib: gebruik van korte URI’s Omgaan met samenstelling-relaties voor ruimte/activiteit Overlap OroX-Bas en OroX-Rib (welke Bas-concepten gebruiken) uitgewerkt Uitbreiding met BIM op basis van GWSW-Rib Enkele discussiepunten toegevoegd (gele kaders) 20150820: Door kopgroep vastgesteld op 20 augustus 2015

1

Inhoud 1

2

3

Inleiding ......................................................................................................................................4 1.1

Wijze van aanpak.................................................................................................................5

1.2

Uitgangspunten ...................................................................................................................5

1.3

Gebruikte begrippen............................................................................................................5

Uitwissel architectuur .................................................................................................................6 2.1

Lokale versus webbased uitwisseling ...................................................................................6

2.2

Gellish naar de achtergrond.................................................................................................7

Relationele Database versus Triplestore ......................................................................................8 3.1

Van tabellen naar triples......................................................................................................8

3.2

Native Database en GWSW..................................................................................................8

3.3

GWSW concepten.............................................................................................................. 10

3.3.1

4

3.4

Mapping tussen Native en GWSW ..................................................................................... 11

3.5

Relaties in het BIM............................................................................................................. 11

Uitwisselformaat OroX (Turtle-syntax).......................................................................................12 4.1

Syntax Turtle-bestand:....................................................................................................... 13

4.1.1

Afspraken voor GWSW-BIM: gebruik prefixes ............................................................ 13

4.1.2

Regels Turtle-syntax ................................................................................................... 13

4.2

5

Toegepaste syntax GWSW.OroX ........................................................................................ 14

4.2.1

Gebruik URI en Labels ................................................................................................ 15

4.2.2

Kenmerken van individuals ........................................................................................ 16

OroX op basis GWSW-Bas: Gestructureerd opbouwen .............................................................. 17 5.1

Het voorbeeld-stelsel......................................................................................................... 17

5.2

Classificeren: indelen in soorten ........................................................................................18

5.3

Samenstelling: decompositie .............................................................................................19

5.3.1

Samenstelling: Ruimte / Gebied / Ondergrond ........................................................... 19

5.3.2

Samenstelling: Bestaansvorm / Activiteiten ............................................................... 20

5.4

Samenhang: topologie en geometrie ................................................................................. 22

5.4.1 5.5

Samenhang: grondwaterstand en maaiveldhoogte .................................................... 23

Specificaties: kenmerken en waarden ................................................................................ 24

5.5.1 6

Identificatie GWSW concepten .................................................................................. 10

Ligging / coördinaten aan de topologie koppelen ....................................................... 24

BIM op basis GWSW-Rib: Gestructureerd opbouwen ................................................................ 25 6.1

Het voorbeeldproject ........................................................................................................ 25

6.2

Classificeren: indelen in soorten ........................................................................................26

6.3

Samenstelling: decompositie .............................................................................................26 2

6.4

7

8

9

Specificaties: kenmerken en waarden ................................................................................ 29

6.4.1

Headergegevens ........................................................................................................ 29

6.4.2

Waarnemingen .......................................................................................................... 30

BIM op basis GWSW-Bas: Gestructureerd inlezen......................................................................32 7.1

Selecteren/doorlopen triples vanuit het OroX-bestand ...................................................... 32

7.2

Putten inlezen ................................................................................................................... 32

7.3

Leidingen inlezen ............................................................................................................... 32

BIM op basis GWSW-Rib: Gestructureerd inlezen ...................................................................... 34 8.1

Activiteiten inlezen ............................................................................................................35

8.2

Geïnspecteerde objecten bepalen ..................................................................................... 35

8.3

Resultaten inlezen ............................................................................................................. 36

Gereedschappen en testresultaten ........................................................................................... 37 9.1

Export naar GWSW.OroX (Turtle / Triplestore)...................................................................37

9.2

Import van GWSW.OroX-bestand (Turtle) .......................................................................... 37

9.3

Proefnemingen met OroX .................................................................................................. 38

9.3.1

Gemeente Pijnacker – 20151113................................................................................ 38

9.3.2

Gemeente Zwolle – 20151112.................................................................................... 39

9.3.3

Gemeente Pijnacker – 20160209................................................................................ 39

9.3.4

Gemeente Den Haag – 20160210 ............................................................................... 40

9.3.5

Gemeente Barneveld – 20160218 .............................................................................. 40

9.3.6

OroX-export Kikker – fijntunen................................................................................... 41

3

1 Inleiding Dit document heeft betrekking op versie 1.3 van het Gegevenswoordenboek Stedelijk Water (GWSW), uitgebracht op 1 mei 2016. Sinds mei 2015 zijn de eerste toepassingen van het GWSW in de praktijk gebracht. Beheersystemen passen hun datamodel erop aan, de inspectiewereld gaat het GWSW-Rib model en het uitwisselformaat RibX toepassen, het GWSW-Hyd gaat in 2016 vaste vorm krijgen. Andere GWSWonderdelen zijn in ontwikkeling (Meldingen en klachten; Persleidingen; Gemalen) of staan gepland. Dit document beschrijft het generieke uitwisselprotocol voor het GWSW. Daarmee kan de vakwereld in de volle breedte gebruik gaan maken van de GWSW Ontologie. De basisopzet van het GWSW staat in de Gellish taal, dit is een semantische modelleringstaal in het zogenaamde ORO (Object-Relatie-Object) formaat. Hoewel Gellish een semantisch rijke taal is, wordt het slechts op beperkte schaal gebruikt. Voor de toegankelijkheid van het GWSW is aansluiting op breder toegepaste formaten binnen het “semantisch web” noodzakelijk. Vanwege het karakter van Gellish is omzetting in een andere taal per definitie goed mogelijk. Het W3C definieert standaarden voor het Semantisch Web met als basis een triple-vorm volgens het RDF (Resource Description Framework): de Subject-Predicate-Object constructie, waarbij de “relatie” een richting krijgt (“directed graph”); een subject is ‘iets’ van een object, waarbij ‘iets’ bijvoorbeeld kan zijn een onderdeel, een synoniem of een subklasse. De term RDF wordt in deze notitie gebruikt voor de combinatie van meerdere protocollen: RDF, RDFS en OWL-2. Door het GWSW vanuit Gellish naar RDF te transformeren vinden we aansluiting op andere bibliotheken in het Semantisch Web en baseren we de uitwisseling en doorstroming van gegevens op de gangbare en breed gedragen ontwikkelingen. Voordelen bij de transformatie naar RDF: Maximaal onafhankelijk van basistechniek, gebruik generieke tools • Gellish (ORO) als modelleringsplatform (backend) • Publicatie via RDF/RDFS/OWL Triples Beperking aantal uitwisselformaten/protocollen • “wiel niet steeds uitvinden” bij ontwikkelen transformatoren voor omzetten van BIM van/naar diverse toepassingen/data bases) Optimale toegankelijkheid van GWSW-Model/BIM • beperkte omvang gegevensoverdracht • begrijpbare uitwisselformaten/bestanden • optimale snelheid (wel/niet via internet) Maximaal onafhankelijk van softwareleveranciers/applicaties Aansluiten op bekende concepten/technieken • BAG, BGT/IMGeo, CB-NL • Semantisch Web (Triplestores, SPARQL) Optimale borging van kwaliteit, versiebeheer en onderhoud

Met de hulp van een aantal RDF-specialisten is de daadwerkelijke omzetting van het GWSW van Gellish naar RDF vastgesteld. Het GWSW-model in RDF beschrijft een ontologie waarin zoveel mogelijk kwaliteitsborging is opgenomen. Met een goed model wordt veel validatie van een BIM binnen de RDF omgeving afgehandeld. De omzetting van het GWSW-model naar RDF heeft logischerwijs ook consequenties voor het BIM uitwisselformaat. Onder de werknaam GWSW.OroX is deze nieuwe uitwisselingsvorm uitgewerkt. OroX is daarbij afgeleid van Object-Relatie-Object eXchange. 4

In deze notitie wordt het uitwisselingsprotocol GWSW.OroX beschreven.

1.1 Wijze van aanpak Enkele bedrijven (RioDesk, Grontmij) hadden al ervaring opgedaan met het BIM-uitwisseling onder het Gellish formaat. RIONED heeft deze bedrijven, versterkt met Antea, gevraagd om het OroX te ontwikkelen, in de praktijk te brengen en vervolgens vast te stellen. Deze werkgroep heeft daarop in de software in- en exportfuncties uitgewerkt en de ervaringen uitgewisseld. Op basis daarvan is dit uitwisselprotocol vastgesteld. In de bijlage vindt u een weergave van de werkgroepbijeenkomsten. Het GWSW.OroX is ontwikkeld en getest binnen de lokale werkomgeving (zie hoofdstuk 2). In een later stadium wordt ook de webbased werkomgeving volledig operationeel. Daarmee komt centrale validatie binnen bereik. Parallel aan deze ontwikkeling is de inrichting van een GWSW-Semantische Server ter hand genomen.

1.2 Uitgangspunten In de voorbeelden en in de praktijk (bij de uitwisseling van GWSW-gegevens) wordt het Turtleformaat gebruikt. Voor GWSW-concepten hanteren we in de voorbeelden een blanco prefix “:”, voor individuals in het BIM wordt de prefix “bim:” gebruikt. Voor de ontwikkeling van in- en exportfuncties van een GWSW.OroX binnen beheersystemen zijn de volgende applicaties en documenten nodig: · Een browser voor het GWSW-model versie 1.2 (WebProtégé) · De spreadsheet GWSW_Lijsten_*.xlsx met de belangrijkste overzichten van GWSW versie 1.2

1.3 Gebruikte begrippen Concept Een soort of klasse vanuit de GWSW-Ontologie. Bijvoorbeeld “rioolput” of “leiding”. Individual Een instantie van een concept. Zoals individual “0980” de bestaande betonnen constructie van het soort/klasse/concept “rioolput” is. BIM Onder BIM (bouwwerk informatie model) wordt in dit kader de beschrijving van een bestaand stedelijk water systeem of proces verstaan, de “individuals” op basis van het GWSW. RDF Het RDF staat voor Resource Description Format, de W3C basisdefinitie van modellen op basis van het triplet subject-predicate-object. In de tekst verstaan we onder RDF de combinatie van RDF met het RDF Schema (RDFS) en OWL 2 (Web Ontology Language, zie W3C). Voor de relatie (tussen subject en object) zijn meerdere namen gebruikelijk, we hanteren in de tekst de termen “relatie”, “property” en “predicate”. Triplestore Een Triplestore is een triple-gespecialiseerde database op RDF-basis voorzien van interfaces om de data te kunnen benaderen. 5

SPARQL Een protocol om Triplestores te kunnen ondervragen en onderhouden. Een belangrijke component is de querytaal waarmee deze bewerkingen worden gedefinieerd.

2 Uitwissel architectuur 2.1 Lokale versus webbased uitwisseling Figuur 1: Lokale uitwisseling

Semantische Server RIONED - GWSW-Ontologie OroX

OroX

Model

Applicatie Stedelijk Water

Model

OroX

Applicatie Stedelijk Water

BIM

Bij lokale uitwisseling is een web-verbinding niet nodig. Applicaties (veelal beheersystemen) wisselen rechtstreeks uit door middel van een OroX-BIM. De applicaties kunnen een verbinding leggen met het GWSW-Model. Daarmee is een mapping met de native-database te definiëren en kan het OroX formaat (tijdens export en import vanuit de applicatie) worden gevalideerd.

6

Figuur 2: Webbased uitwisseling

Semantische Server RIONED - GWSW-Ontologie SPARQL Queries

SPARQL Queries

Valideren

Semantische Server - GWSW-BIM Applicaties: conversie/validatie

OroX

OroX

Model

Model OroX

RibX

OroX

BIM

BIM

BIM

Applicatie B Beheer Stedelijk Water

Applicatie A Beheer Stedelijk Water

Op een Semantische Server heeft RIONED de GWSW-Ontologie als dataset opgeslagen. Externe partijen krijgen toegang tot deze dataset. De Semantische Server verzorgt ook de validatie van BIM’en. De “bouwwerk-informatie” worden daartoe getoetst aan de validatienormen binnen de GWSW-Ontologie. Gebruikers kunnen hiertoe hun eigen (BIM) modellen uploaden. De server verzorgt (via de GWSW Browser) ook de conversie van afwijkende formaten zoals RibX. Zulke afwijkende formaten kunnen voorgeschreven zijn binnen bepaalde disciplines, maar er wordt naar gestreefd om import/export van beheersystemen Stedelijk Water altijd via OroX te verzorgen. Zo kan veel eenvoudiger de conformiteit met het GWSW Model gevalideerd worden en daarmee de kwaliteit van het BIM (OroX). De Semantische Server is grotendeels gerealiseerd parallel aan de implementatie van het GWSW.OroX. De GWSW Semantische Server is als volgt benaderbaar: data.gwsw.nl Ontsluiting (HTML) voor raadpleging van het model door personen data.gwsw.nl\{individual} Ontsluiting (HTML) voor raadpleging van specifieke individuals review.gwsw.nl Ontsluiting (Webprotégé) voor review sparql.gwsw.nl Ontsluiting voor SPARQL queries rechtstreeks op model en datasets

2.2 Gellish naar de achtergrond Het oorspronkelijk Gellish model bevat naast de “triples” extra informatie zoals UiD, UoM, cardinaliteit, taal, discipline, auteur, bron en versiebeheer. Deze “overhead” heeft veelal betrekking op het GWSW-conceptenmodel (-Bas, -Rib, -Kib). Dit GWSW-model blijft op de achtergrond in de Gellish taal gehandhaafd, omdat onderhoud en ontwikkeling van het GWSW-model in ieder geval komende jaren in deze omgeving blijft plaatsvinden. Voor applicatieontwikkelaars en andere gebruikers komt het GWSW-conceptenmodel exclusief beschikbaar in RDF formaat, waardoor ook de generieke tools zoals hiervoor besproken binnen handbereik zijn. Ook het GWSW-BIM wordt in het vervolg altijd in RDF beschreven, daar bestaat geen Gellish versie van. 7

3 Relationele Database versus Triplestore 3.1 Van tabellen naar triples De grootste uitdaging ligt bij het exporteren en importeren van OroX bestanden. Er dient een transformatie tussen native database en een triple-gebaseerd bestand ontwikkeld te worden. De volgende figuren geven het verschil tussen traditionele database-tabellen en RDF-triples weer: Database-tabellen Putten en Leidingen

heeft als aspect Naam Knp0978 Knp0979 Knp0980

Materiaal Beton Beton Beton

Vorm Rechthoekig Rechthoekig Rechthoekig

Breedte 2000 1500 4000

heeft als waarde

is verbonden met Naam Lei001 Lei002

Begin Eind Knp0979 Knp0980 Knp0978 Knp0979

Materiaal Beton Beton

Vorm Rond Rond

Diameter 600 600

Een put-tabel-record in RDF-triples: 1500

= de tabel-naam = de tabelkolom-naam = tabel-relatie

Of, met specificatie van het aspect: 1500

= de tabel-naam = de tabelcel-naam = de tabelkolom-naam 1500 = de tabelcel-inhoud = tabel-relatie

Deze laatste, uitgebreidere methode wordt toegepast in het GWSW. Daarmee wordt het mogelijk extra (meta)gegevens aan een aspect (“tabel-cel”) toe te kennen en aspecten binnen een aspect te definiëren.

3.2 Native Database en GWSW Als hulpmiddel bij de transformatie van relationele databases (RDB) naar GWSW.OroX wordt een spreadsheet GWSW_Lijsten geleverd met daarin de volgende overzichten (in werkbladen): · Klassen: alle in het GWSW opgenomen concepten ° Name: identificatie-string van het concept (in CamelCase). De is het UID in RDF. ° Number: identificatie-nummer van het concept ° Unit: gebruikte eenheid (mm, yyyymmdd, enz) 8

·

·

·

·

° Label: naam van het concept ° Code: de alternatieve notatie van het concept. Eventueel variërend per context. ° Definition: GWSW-definitie ° DefinedBy: Verwijzing naar de normen met definitie ° SuperClass: De superklasse bij het concept Relaties: de voor het BIM relevante relaties tussen de concepten ° Subject: het linker-concept, de relatie geldt ook voor alle subklassen van het Subject ° Property: de relatiesoort ° Object: het rechter-concept, de relatie geldt ook voor alle subklassen van het Object Soortenboom: de “taxonomie”, per concept de bijbehorende superklassen ° Class: het betreffende concept (alle GWSW-concepten staan in de tabel) ° SuperClass1-5, de soortenboom waartoe het concept behoort Collecties: de “domeintabellen” of “codetabellen” ° Aspect: het kenmerk dat refereert aan een element uit de collectie ° Collection: de naam van de collectie ° NameElement: de element-namen en bij de collectie, de UID in RDF ° NumberElement: identificatie-nummer van het element ° CodeElement: de alternatieve notatie van het element. Eventueel variërend per context. Mapping (optioneel): een voorbeeld van een mapping-tabel tussen native database en GWSW-concepten ° Tabel: de naam van de native tabel, met bijvoorbeeld een bepaalde superklasse ° Kolom: de kolom naam van de native tabel ° Inhoud: de voorgeschreven vulling bij de kolom, bijvoorbeeld codes van domeintabellen ° Opm: aanvullende opmerkingen ° GWSW Id_name – zie blad Klassen ° GWSW Id_number – zie blad Klassen ° GWSW Unit – zie blad Klassen

Deze spreadsheet met het betreffende blad wordt in dit document verder aangegeven met “GWSW_Lijsten/Bladnaam”. Per GWSW-module (-Bas, -Rib, -Hyd, enzovoort) wordt zo’n spreadsheet gemaakt. In de naamgeving van het bestand komt de modulenaam terug. De spreadsheets worden beschikbaar gemaakt via www.riool.net /orox (link nog activeren…). 20150819: Aanmaak GWSW_Lijsten De overzichten worden nu door RIONED gevuld met behulp van SPARQL queries op de GWSW-Ontologie. De lijsten worden uitgeleverd in combinatie met nieuwe versies van GWSW-modules. Zodra de Semantische Server functioneel is kunnen gebruikers ook zelf de GWSW-Ontologie ondervragen. Frank geeft hieraan de voorkeur.

Export vanuit een RDB of import naar een RDB kan rechtstreeks via een GWSW.OroX formaat of via SPARQL-queries op een generieke Triplestore in combinatie met alle soorten RDF-uitwisselformaten. Voor wat betreft de export uit een RDB is de syntax van de SPARQL-constructs naar verwachting complexer dan bijvoorbeeld rechtstreeks naar Turtle.

9

20150603: API voor RDF – RDB transformatie Frank vind een nader onderzoek naar een API voor de transformatie tussen RDB en RDF (oftewel tussen SQL en SPARQL) nuttig. Zie ook het document “A survey of RDB to RDF translation approaches and tools” (door Frank gestuurd aan Hendrik/Marinus). Als er meerdere partijen gebruik van gaan maken, zijn Hendrik en Marinus het hiermee eens. Hoeveel partijen dat zijn is nog onduidelijk. Riodesk en Grontmij zullen dit niet toepassen. De positie van RH-DHV (beheersysteem Castor als opvolger van Cortex) is nog niet helder. Voordat ontwikkeling plaatsvindt, zal Stichting RIONED de daadwerkelijke behoefte moeten peilen. Frank heeft de werking van één van de API’s onderzocht: D2RQ. De transformatie van Oracle-tabelschema’s naar RDF gaat daarmee relatief simpel. Ook kunnen de tabelrelaties als parameters worden meegegeven. Daarmee is op basis van een vaststaand database-schema een eenvoudige transformatie mogelijk. Voor het GWSW-RDF hebben we echter te maken met separaat model waarin restricties en definities volgens RDF/OWL syntax zijn opgenomen. Dan wordt toepassing van D2RQ lastig. Ook de Enterprise-versie van Oracle kent een triple store connectie. Door de prijsstelling (€60.000 extra) is deze oplossing niet haalbaar, elke eindgebruiker wordt daarmee dan geconfronteerd.

3.3 GWSW concepten Zoals genoemd zijn in GWSW_Lijsten/Klassen alle GWSW-concepten opgenomen. De RDF praktijk is het hanteren van begrijpbare namen voor concepten. Daarbij wordt de CamelCase / camelCase notatie van de namen voor zowel properties (starten met lowercase) als concepten (starten met uppercase) gehanteerd. Id_Naam

Label

Id_number

Unit

Definition

HoogteLeiding

Height

110003046

mm

Vervuilingsgraad

Vervuilingsgraad

111005558

De bij het materiaal gebruikelijke aanduiding van de hoogte van een leiding (bijvoorbeeld beton = binnenhoogte, kunststof = buitenhoogte Het percentage van de inwendige hoogte waarmee de leiding gevuld is met verontreiniging.

Activiteit Functionaliteit TijdstipMeting ReinigenHoge_drukRioolput Deelreparatie

Activiteit Functionaliteit Tijdstip meting Reinigen hoge-druk rioolput Deelreparatie

111001924 111005395 120001026 111001132 111000859

3.3.1

Identificatie GWSW concepten

De conceptnaam (UID) in het GWSW-model staat in CamelCase notatie. De UID wordt opgebouwd door de uitgeschreven conceptnaam te comprimeren (spaties en bijzondere tekens verwijderen) en in camelcase te plaatsen. De uitgeschreven conceptnaam komt terug als object bij property rdfs:label. Binnen RDF is de property rdfs:label ook niet uniek per subject. Zoals gebruikelijk wordt in RDF elke vertaling in een apart label gezet. Voor de mapping tussen native database en het GWSW-model is het identificatienummer (id_number) de primaire ingang per concept. In volgende versies van het GWSW is een gelijke naam bij het nummer niet gegarandeerd. Een naam zou in detail kunnen wijzigen met behoud van het nummer. Er wordt wel naar gestreefd om in toekomstige versies alleen de namen als identificatie te gaan hanteren, dan kan het id_number vervallen. De camelcase UID kunnen in sommige gevallen zeer lang worden. Bijvoorbeeld bij de concepten uit de EN13508-2, daarin zijn inspectie-waarnemingen en karakteriseringen daarvan opgenomen. Vooral de bijbehorende keuzelijsten zijn in de standaard UID nauwelijks bruikbaar. In zo’n geval is er voor 10

gekozen om voor de UID de EN-coderingen te hanteren. Omdat in de inspectiewereld is het gebruikelijk de EN-coderingen te hanteren. De UID blijft daarmee begrijpelijk.

20150603: Gebruik namen of nummers Beide opties blijven open. Hendrik past ook de relatie rdf:type in combinatie met Id_name toe. 20150519: GWSW_Lijsten/Klassen uitgebreid met kolom AltLabels, die alle synoniemen van het concept bevat. De kolom Label gewijzigd in Labels, bevat nu ook de labels in andere talen. In de kolom Labels is nu ook vermeld (met “(coll)”) dat het een collectie betreft. 20150603: Mapping Gellish-labels naar RDF In GWSW_Lijsten/Collecties ontbreken de Gellish-labels voor de elementen. Frank heeft die nodig voor de mapping. Deze worden in een extra kolom toegevoegd (Marinus). Let op: als er vertalingen van het label voorkomen worden deze ook in de label-kolom vermeld. Meerdere labels worden gescheiden door een “/”.

3.4 Mapping tussen Native en GWSW In GWSW_Lijsten/Mapping staat een voorbeeldtabel met daarin de GWSW-concepten gelinkt aan een native database. Tabel

Kolom

Inhoud

Opm

Grp

TypGrp

G

1 Afvalwatersysteem

110000001

Grp

TypGrp

1

1 Hemelwaterstelsel

110000006

Grp

TypGrp

0

1 GemengdStelsel

110000008

Grp

TypGrp

R

1 Randvoorziening

110000050

Grp

TypGrp

2

1 Vuilwaterstelsel

110000106

Grp

TypGrp

C

1 HorizontaalDrainagesysteem

110000108

Grp

TypGrp

W

1 Wadi

110000108

Grp

_wgb

StedelijkWatersysteem

110000004

Grp

_pos

Positie

110003180

Grp

TypGrp

1 Grondwatermeetnet

111001112

Grp Afm

Hgt

HoogteReservoir

110001065

InspLei

_opdr

contractor

109999883

InspLei

_proj

Rioleringsinspectieproject

110001534

InspLei

_insplei

VisueelInspecterenVrijvervalLeidingVanuitLeiding

111000030

P

GWSW Id_name

GWSW Id_number

GWSW Unit

mm

De geel-gemarkeerde kolommen bevatten de invulling vanuit GWSW_Lijsten/Klassen. Afhankelijk van de native datastructuur wordt deze tabel aangevuld met de corresponderende native concepten. Zoals eerder genoemd (hoofdstuk 3.3.1) is het id_number bij de mapping maatgevend, de namen van GWSW-concepten zouden (in detail) kunnen wijzigen bij gelijkblijvend id_number. Geadviseerd wordt om in de mapping zowel naam als nummer te gebruiken, in toekomstige versies kan het nummer vervallen (zodra de naamgeving stabiel is).

3.5 Relaties in het BIM In een BIM worden de volgende properties gebruikt. Property rdf:type

Toelichting Subject is van het type Object (klasse-naam)

11

rdfs:label :hasAspect :hasValue :hasReference :hasInput :hasOutput :hasPart :hasConnection :hasRepresentation

Subject heeft als naam Literal Subject heeft als kenmerk Object Subject heeft als waarde Literal (subject is kenmerk) Subject heeft als referentie Object (subject is kenmerk) Subject heeft als invoer Object Subject heeft als uitvoer Object Subject heeft als deel Object Subject heeft verbinding met Object (symmetrisch, subject en object uitwisselbaar) Subject heeft als representatie Object

Alle voor een BIM relevante relaties tussen de concepten staan in GWSW_Lijsten/Relaties: OwnerOfProperty

Subject

Leiding

VrijvervalRioolleiding

hasAspect

Property

Object Leidingorientatie

Leiding

VrijvervalRioolleiding

hasAspect

MateriaalLeiding

Leiding

VrijvervalRioolleiding

hasAspect

VormLeiding

Leiding

VrijvervalRioolleiding

hasAspect

Verbindingstype

VrijvervalRioolleiding

VrijvervalRioolleiding

hasAspect

Lining

VrijvervalRioolleiding

VrijvervalRioolleiding

hasAspect

AfvoerendOppervlak

VrijvervalRioolleiding

VrijvervalRioolleiding

hasConnection

Rioolput

VrijvervalRioolleiding

VrijvervalRioolleiding

hasConnection

Rioolput

Relaties kunnen geërfd worden van superklassen. In principe zijn alle relevante geërfde relaties per subject in de tabel opgenomen. Sorteren op property en vervolgens op subject geeft de, al dan niet geërfde, relaties per GWSW. 20150519: Het blad GWSW_Lijsten/Relaties is uitgebreid met OwnerOfProperty. Alle subject-relaties per GWSWconcept zijn nu zichtbaar, inclusief de geërfde (van het subject OwnerOfProperty).

Voor de identificatie van GWSW-concept wordt altijd de naam gebruikt: Gebruik id-naam:

4 Uitwisselformaat OroX (Turtle-syntax) Eerder geschetste ontwikkelingen gaven de koers al aan: het OroX uitwisselformaat wordt gebaseerd op RDF, aansluitend op het Semantisch Web. Het GWSW-conceptenmodel bevat de metagegevens en de restricties op de BIM-data. Een GWSW-BIM bevat veel minder overhead dan het model, vaak kan volstaan worden met enkele header-gegevens (zoals GWSW-versie, auteur). Er zijn meerdere uitwisselvormen voor RDF. Die zijn allen onderling uitwisselbaar, alleen de syntax verschilt. GWSW.OroX wordt in het zogenaamde Turtle-formaat beschreven.

12

De overwegingen bij RDF Turtle op een rij: •

• • • • •

De syntax is helder en ontworpen voor triples. Bijvoorbeeld: in XML kan subject als xml-attribuut van xmlelement en als xml-element onder voorkomen. Dat maakt het complex. XML sluit als structuur niet goed aan, is oorspronkelijk niet voor triples bedoeld. RDF Turtle heeft geen beperking in URI’s (lokale naamgeving/karakters); RDF Turtle heeft compacte syntax voor toevoegen van eenheden en taal; RDF Turtle wordt algemeen gebruikt, de Turtle-syntax komt ook terug in de SPARQL syntax (de querytaal voor Triplestores); Gebruik van bekende XML-parsers zou een voordeel kunnen zijn maar die zijn nauwelijks bruikbaar voor RDF/XML; RDF-formaten zijn uitwisselbaar, zodat zonder grote problemen gereageerd kan worden op toekomstige ontwikkelingen.

4.1 Syntax Turtle-bestand: Gebruik voor de vulling van een GWSW.OroX Turtle bestand de UTF-8 karakterset. Bovenaan in het bestand wordt de namespace-prefix vermeld, analoog aan namespace-alias voor xml/xsd formaten: @prefix rdf: @prefix rdfs: @prefix owl: @prefix xsd: @prefix skos: @prefix : @prefix bim:

. . . . . . .

Deze prefixdefinities zijn in feite ook triples (ze bestaan uit drie componenten afgesloten met een “.”). 4.1.1 Afspraken voor GWSW-BIM: gebruik prefixes In de gaande praktijk staat de keuze voor de prefix vrij, die lijn wordt gevolgd. In de voorbeelden wordt de lege prefix “:” gebruikt voor de GWSW-concepten. Die heeft ook de voorkeur voor het OroX maar dat is dus geen verplichting. De URL waarnaar de prefix verwijst kan wijzigen afhankelijk van de inrichting van de Semantische Server. 20150608: De URL is aangepast op GWSW versie 1.2, dd 20150527 20151027: De URL is aangepast op de Semantische Server

De prefix “bim:” gebruiken we voor de individuals binnen het BIM. Dus voor de fysieke objecten met hun aspecten. 4.1.2 Regels Turtle-syntax Na de prefixdefinitie volgen de triples (“subject”-“predicate”-“object”). Hou hierbij de volgende regels aan:

13

· · · ·

Triples separated by . URI’s in < > (opm: URI’s vormen concept-identificaties/namen) Literals in “ “ URI’s can be abbreviated by prefixed name spaces (opm: BIM-toepassing) ° opm: geen bijzondere tekens in korte URI gebruiken: @ ? · Three types of triple abbreviations: ° Parallel: Same subject via ; separator ° Parallel: Same subject-predicate via , separator ° Sequential: End of one triple is start of the next triple via […] grouping ° Special ° Typed literal add ^^xsd: … (include xsd prefix) ° Untyped literal can be multi-lingual via @ …like @nl ° Blank nodes via _:… or [ … ] grouping ° Lists via / (of type: unordered list, ordered list, set of choices) ° Reification via extra meta-node + 3 standard references ° “a” is shorthand for “rdf:type”

Bron: Michel Böhms

Triples kunnen dus ook gebundeld (afgekort) worden: 1. het subject éénmalig noemen en vervolgens de bijbehoren predicates+objects 2. het subject+predicate éénmalig noemen en vervolgens de bijbehorende objects 3. geschakelde triples, het object wordt het subject van de volgende triple Hou hierbij de volgende regels aan: 1. Parallel triples with common source · a1 b1 c1 . · a1 b2 c2 . · shorthand: a1 b1 c1 ; b2 c2 . (note also allowed: a1 b1 c1 ; b2 c2 . ; . (TBC-way) 2. Parallel triples with common source and predicate · a1 b2 c2 . · a1 b2 c3 . · shorthand: a1 b2 c2 , c3 . 3. Sequential triples where the end of one triple is the start of another triple · a1 b3 c4 . · c4 b4 c5 . · shorthand: a1 b3 [c4 b4 c5] . Bron: Michel Böhms

4.2 Toegepaste syntax GWSW.OroX Voorbeeld van een GWSW.OroX met namespaces en enkele triples:

14

@prefix rdf: @prefix rdfs: @prefix owl: @prefix xsd: @prefix skos: @prefix : @prefix bim:

. . . . . . .

bim:Stelsel_1 bim:Stelsel_1 bim:Stelsel_1 bim:Knp0980 bim:Knp0980

rdfs:label rdf:type :hasPart rdfs:label rdf:type

"DM" . :GemengdStelsel . bim:Knp0980 . "DM/0980" . :Inspectieput .

Het gedeelte met de “bim:”-triples kan ook ingekort worden geschreven, de subjecten worden dan na een “;” niet in de volgende triple herhaald. Dat ziet het er als volgt uit: bim:Stelsel_1 bim:Stelsel_1 bim:Knp0980

rdfs:label rdf:type :hasPart rdfs:label rdf:type

"DM" ; :GemengdStelsel . bim:Knp0980 . “DM/0980" ; :Inspectieput .

De URI “bim:Stelsel_1” is een BIM-individual, de URI “:GemengdStelsel” verwijst naar een GWSWconcept (zie GWSW_Lijsten/Klassen). De URI “bim:Stelsel_1” is noodzakelijk om het individu te kunnen onderscheiden. Voor deze URI kan het beste een begrijpbare naam worden gekozen. Het label kan de door de beheerder gebruikte naam of codering te bevatten. 4.2.1

Gebruik URI en Labels

20150603: Afspraken gemaakt over omgaan met URI en labels voor herkenning gebied, put, leiding.

Er zijn in RDF Turtle meerdere mogelijkheden voor het gebruik van labels en URI’s. Voor het OroX houden we uniform het volgende aan: · De URI dient in het OroX alleen voor identificatie binnen de Turtle-syntax, voor de eindgebruiker heeft het geen betekenis; 20150819: Frank geeft aan dat deze benadering niet aansluit op de gangbare praktijk. Daarin vormt de URI de unieke aanduiding voor een concept. De werkgroep is van mening dat dit het “wenkend perspectief” moet zijn. Dan zijn echter eerst bindende (nationale) afspraken nodig over de unieke identificatie van “individuals” (bijvoorbeeld gemeentelijke fysieke objecten). Dit punt is de onder de aandacht van RIONED gebracht.

· De labels bij de concepten Stelsel (“DM”), Rioolput (“0987”) en Leiding (“0987-0989”) dienen de unieke identificatie voor de eindgebruiker/beheerder te bevatten; · In het label staat dus de gangbare objectnaam. Samenstellingen van objectnamen worden gebruikt als er anders geen unieke identificatie mogelijk is. Als bijvoorbeeld rioolput “0987” in meerdere stelsels binnen hetzelfde beheergebied voorkomt, dan dient het label van de rioolput te bestaan uit stelselnaam en putnaam, gescheiden door een “/”. Bijvoorbeeld “DM/0978”. Bij twijfel kan deze aanduiding altijd gebruikt worden, de “/” in de naam geeft aan dat het bestaat uit stelselnaam + objectnaam. 15

4.2.2

Kenmerken van individuals

Voor kenmerken van individuals (zoals bijvoorbeeld het materiaal van put bim:Knp0980) is niet persé een URI nodig. In die gevallen kan ook een zogenaamde “blank node” worden gebruikt. Die worden aangeduid met _:nnn (nnn = unieke naam). De volgende mogelijkheden zijn er: Aspecten met URI aanduiden: bim:Knp0980 bim:Mat_Knp0980 bim:Mat_Knp0980

rdf:type rdfs:label :hasAspect rdf:type :hasReference

:Inspectieput ; “DM/0980” ; bim:Mat_Knp0980 . :MateriaalPut . :Beton .

Aspecten via blank node aanduiden: bim:Knp0980 _:Materiaal_111

rdf:type rdfs:label :hasAspect rdf:type :hasReference

:Inspectieput ; “DM/0980” ; _:Materiaal_111 . :MateriaalPut ; :Beton .

Aspecten niet benoemen, alleen het type en de waarde aangeven: bim:Knp0980 [ ].

rdf:type rdfs:label :hasAspect rdf:type :hasReference

:Inspectieput ; “DM/0980” ; :MateriaalPut ; :Beton

Waarde-toekenning De elementen van collecties (domeintabellen) zijn in het GWSW als aparte concepten benoemd. Als kenmerken (zoals :MateriaalPut) de waarde van een concept krijgen, wordt de relatie :hasReference gebruikt. Als kenmerken een “datatype” als waarde krijgen, dan geldt de relatie :hasValue. Voorbeelden waarde-toekenning: bim:Knp0980 [ ], [ ].

rdf:type rdfs:label :hasAspect rdf:type :hasReference

:Inspectieput ; “DM/0980” ;

rdf:type :hasValue

:BreedtePut ; 4000 (of 4000^^xsd:integer)

:MateriaalPut ; :Beton

In dit voorbeeld is ook de afkorting voor de combinatie subject+predicate gebruikt. De waarde voor twee aspecten is ingevuld bij de combinatie <:hasAspect>. Specificeren datatypes Datatypes bij waarden kunnen in veel gevallen automatisch afgeleid worden uit de syntax. Voor datum/tijd datatypes is echter een specifieke typering nodig, de RDF-validatie zal daar anders een foutmelding op geven. 16

bim:Knp0980 [ ], [ ], [ ].

rdf:type :hasAspect rdf:type :hasValue

:Inspectieput ;

rdf:type :hasValue

:DateOfInspectionManhole ; "2013-01-05"^^xsd:date

rdf:type :hasValue

:TimeOfInspectionManhole ; "11:50:00"^^xsd:time

:YearCameIntoOperation ; "1980"^^xsd:gYear

5 OroX op basis GWSW-Bas: Gestructureerd opbouwen Op basis van een eerdere presentatie (uit de “Gellish-tijd”, december 2013) bouwen we in de volgende hoofdstukken stapsgewijs een BIM.

5.1 Het voorbeeld-stelsel Bij dit document hoort een Turtle-bestand met daarin een voorbeeld-stelsel. Dit bestand is beschikbaar via www.riool.net /orox (link nog activeren…). Dit schema representeert dat stelsel.

De detailconstructies:

17

5.2 Classificeren: indelen in soorten

18

5.3 Samenstelling: decompositie

De decompositie passen we toe op stelselniveau, maar ook op de opbouw van bijvoorbeeld putconstructies:

5.3.1

Samenstelling: Ruimte / Gebied / Ondergrond

Het GWSW beschrijft ook de samenstelling van concepten van het type Ruimte. Voor deze relaties wordt ook :hasPart gehanteerd. Er hoeft hierbij echter geen sprake te zijn van een compositie zoals in het vorige hoofdstuk. Een ruimte kan een andere ruimte bevatten maar ook een fysiek object. Daarmee geven we aan dat een stelsel of een leiding in een bepaalde ruimte ligt. Voorbeelden van het type ruimte zijn: 19

· · · ·

Straat District Kern Ondergrond

De straat of het district wordt dus niet als :hasAspect opgenomen bij het fysieke object, maar als volgt: In de GWSW-Ontologie :Gebied :District :Straat :District :Ondergrond

rdf:type rdf:type rdf:type rdf:type rdf:type

:Ruimte . :Gebied . :Ruimte . :Gebied . :Ruimte

rdf:type :hasPart rdf:type rdf:type :hasAspect

:District . bim:Stelsel_A . :Rioolstelsel . (het district is hiermee bij alle leidingen/putten bekend) :Straat .

rdf:type :hasValue

:Straatnaam ; “straatnaam”

:hasPart rdf:type rdf:type :hasAspect

bim:DM/0989-0990 . :Leiding . (straatnaam is hiermee bij de leiding bekend) :Ondergrond .

rdf:type :hasReference

:Grondsoort ; :Klei

:hasPart

bim:Stelsel_A . (alle stelsel-leidingen/putten liggen in klei)

In het BIM: bim:District_A bim:District_A bim:Stelsel_A bim:Straat_A bim:Straat_A [ ]. bim:Straat_A bim:DM/0989-0990 bim:Ondergrond_A bim:Ondergrond_A [ ]. bim:Ondergrond_A

20151117/mv: Voorstel om het kenmerk Straatnaam te vervangen door labeling van het concept Straat. Akkoord? 20160107: Toetsen aan BAG – openbare ruimte (zit zo in GBI, Kikker) 20160205: In BAG bestaat alleen het begrip Openbare Ruimte, één van de typen is Weg. Gebruik BAG-begrip Naam Openbare Ruimte voor Straatnaam. Hou Straat voorlopig als specialisatie van Bovengrond, Straatnaam blijft kenmerk van Straat

5.3.2

Samenstelling: Bestaansvorm / Activiteiten

De samenstelling van deze concepten is als volgt opgezet: Een bestaansvorm (bijvoorbeeld een organisatie) kan als uitvoer (:hasOutput) of als invoer (:hasInput) een Activiteit hebben. Een activiteit kan een project zijn, in dat geval heeft de bestaansvorm Opdrachtgever als uitvoer het Project (is controller, bestuurder), de Opdrachtnemer heeft als invoer het Project (is uitvoerder). Het project (de activiteit) kan deelactiviteiten (:hasPart) hebben en als uitvoer (:hasOutput) of als invoer (:hasInput) een Fysiek Object. In de GWSW-Ontologie

20

:Opdrachtgever :Opdrachtnemer :Inspecteur :InspectieProject :InspecterenLeiding :InspectieProject

rdf:type rdf:type rdf:type rdf:type rdf:type :hasPart

:Bestaansvorm . :Bestaansvorm . :Opdrachtnemer . :Activiteit . :Activiteit . (ingekorte conceptnaam) :InspecterenLeiding .

In het BIM: bim:Opdr_A bim:Opdr_A bim:Insp_A bim:Insp_A bim:Proj_A bim:Opdr_A bim:Insp_A bim:Proj_A_lei bim:Proj_A bim:DM/0989-0990 bim:Proj_A_lei bim:Proj_A_lei

rdf:type rdfs:label rdf:type rdfs:label rdf:type :hasOutput :hasInput rdf:type :hasPart rdf:type :hasInput :hasOutput

:Opdrachtgever . “opdrachtgevernaam” . :Inspecteur . “inspectiebedrijfsnaam” . :Inspectieproject . bim:Proj_A . (opdrachtgever doet aansturing van het project) bim:Proj_A . (opdrachtnemer doet uitvoering van het project) :InspecterenLeiding . bim:Proj_A_lei . (de deelactiviteit binnen het project) :Leiding . bim:DM/0989-0990 . (de input van de deelactiviteit - projectdefinitie) bim:DM/0989-0990 . (de output van de deelactiviteit - inspectieresultaat)

De registratie van de reinigingsdatum bij een leiding in minimale vorm: bim:Proj_A_lei [ ].

rdf:type :hasInput :hasAspect rdf:type :hasValue

:ReinigenLeiding ; (de activiteit) bim:DM/0989-0990 ; (de input van de activiteit) :DatumMaatregel ; “2015-01-31”^^xsd:date

21

5.4 Samenhang: topologie en geometrie

22

Zie hoofdstuk 5.5.1 voor de koppeling van ligging (coördinaten, hoogte) aan de topologie. 20151120: Voorstel vereenvoudiging Aspect positie er tussenuit, modellering-efficiëntie weegt niet op tegen balast voor OroX. Daarnaast worden niet altijd consequent de 3 waarden X,Y,Z toegepast (bob leiding, maaiveldhoogte). Ontologie consequent handhaven, optioneel de aspecten X,Y,Z aan vertex meegeven. Dringend advies van Matthé; beter om positie te handhaven, heldere scheiding tussen geometrie en topologie, heeft daarnaast eigen metadata zoals coördinatenstelsel 20150508: Snelle oplossing geometrie Marinus noemt als alternatief een kort-door-de-bocht oplossing voor standaardsituaties. Bij de doorsnee verbinding leiding (zonder knikpunten) – inspectieput zou de topologiedefinitie buiten beeld kunnen blijven. Dan alleen twee extra aspecten bij de put (x/y coördinaat) voor deze standaardsituatie. Besloten wordt om consequent de topologiedefinitie te hanteren, voor bijzondere situaties is die toch nodig, dus inbouwen moet sowieso.

20150907: Snelle oplossing geometrie - vervolg Hendrik stelt voor (zie mailbox) om constructieonderdelen als Wand, Pomp direct te verbinden met een rioolput. Dus niet via onderdeeloriëntatie

5.4.1

Samenhang: grondwaterstand en maaiveldhoogte

Als er bij een individual naar een grondwaterpeil of maaiveldhoogte verwezen wordt, gebeurt dit volgens hetzelfde principe:

In dit voorbeeld zijn de kenmerken maaiveldhoogte en grondwaterniveau en hun waarde al opgenomen. Zie het volgende hoofdstuk voor de verdere beschrijving hiervan. 20151117/mv: De z-waarde van maaiveld en grondwaterstand is niet via het algemene concept Positie verwerkt. Akkoord? Volgens Matthé niet doen!

23

5.5 Specificaties: kenmerken en waarden

20151117/mv: Het kenmerk Diameter handhaven naast Breedte/Hoogte/Vorm? 20160107: diameter naast breedte/hoogte handhaven, igv ronde buis: diameter of hoogte+breedte of hoogte of breedte

5.5.1

Ligging / coördinaten aan de topologie koppelen

Het aspect :Positie bevat de coördinaten bij de topologische elementen.

Op deze wijze kan ook een leiding met of zonder knikpunten een eigen positionering meekrijgen. In de meeste gevallen is de topologische verbinding met de putten voldoende. Daaruit is voor applicaties de leidingligging af te leiden. De hoogteligging van de leiding (de z-waarde, de binnenonderkant buis) wordt ook de topologie gekoppeld:

24

6 BIM op basis GWSW-Rib: Gestructureerd opbouwen Het GWSW-Rib wordt toegepast voor inspectie- en reinigingsprojecten. Een OroX voor zo’n project kan zowel de projectdefinitie (welke objecten moeten geïnspecteerd/gereinigd worden, wat zijn de algemene projectgegevens) als de resultaten van het project (welke waarnemingen zijn gedaan, hoeveel slib is afgevoerd) bevatten. Analoog aan het uitwisselingsformaat RibX zijn de volgende soorten projecten uit te wisselen met het OroX op basis van het GWSW-Rib: · Inspecteren leidingen en putten (codenaam Rib) · Reinigen leidingen en putten (codenaam Rrb) · Reinigen en inspecteren kolken (codenaam Kib) De projectdefinitie (welke objecten worden geïnspecteerd of gereinigd en welke gegevens horen daarbij) kan grotendeels op basis van het GWSW-Bas worden beschreven. In het hoofdstuk Samenstelling wordt daar in detail op in gegaan. In de spreadsheet GWSW_Lijsten.xlsx is ook het complete GWSW-Rib model opgenomen, die vormt de basis voor de OroX definitie. Daarnaast kunnen de volgende brondocumenten behulpzaam zijn: · Document GWSW-Rib en GWSW.Ribx (versie 1.2, 27 mei 2015) · EN 13508-2+A1 (2011) · NEN 3399 (2015)

6.1 Het voorbeeldproject Bij dit document hoort een Turtle-bestand met daarin een voorbeeldproject. Dit bestand is beschikbaar via www.riool.net/orox [... nog te maken pagina]. In het voorbeeld bestand zijn de resultaten van een inspectieproject opgenomen. De inhoud is te vergelijken met het GWSW.RibX, het gaat tenslotte om dezelfde projectresultaten, maar de structuur is natuurlijk afwijkend. 25

6.2 Classificeren: indelen in soorten

6.3 Samenstelling: decompositie Zie de eerdere hoofdstukken voor een toelichting over samenstellingen van Ruimtes en Activiteiten Schematisch is de opbouw van een OroX voor inspectie- en reinigingsprojecten als volgt: Project hasAspect Kenmerk (projectreferenties) Project hasInput Opdrachtgever Project hasOutput Opdrachtnemer Project hasPart Activiteit (inspecteren of reinigen van put/leiding/kolk)

· Activiteit hasInput Object (in geval van een projectdefinitie - aangeleverd) (put/leiding/kolk) ° Object hasAspect Kenmerk (materiaal enz., uit beheersysteem) · Activiteit hasOutput Object (in geval van een projectresultaat - teruggeleverd) ° Object hasAspect Kenmerk (materiaal enz., waargenomen) · Activiteit hasOutput Waarneming (de toestandsaspecten bij de put, leiding, kolk) ° Waarneming hasAspect Kenmerk (afstand, toestandscode, enz.) · Activiteit hasOutput Divers (datum, tijdstip, neerslag) Een inspectie- of reinigingsproject wordt gedefinieerd als een activiteit met als deelactiviteiten (:hasPart) “Inspecteren Inspectieput”, “Inspecteren Vrijverval Rioolleiding” enzovoort. De deelactiviteit heeft als invoer (:hasInput) het te inspecteren object. Elke deelactiviteit heeft als inspectieresultaat (:hasOutput) algemene gegevens (inspectiedatum, videobestand, …), een serie waarnemingen (deformatie, aantasting, enz.) en het geïnspecteerde object met waargenomen kenmerken (materiaal, afmeting, enz.). Elke waarneming heeft vervolgens een aantal aspecten (afstand, klokstand, karakterisering 1 en 2, enz.). Deze structuur geldt zowel voor de projectdefinitie, waarbij de opdrachtgever aangeeft voor welke objecten de activiteit geldt en welke kenmerken de activiteit en die objecten hebben, als voor het projectresultaat, waarbij waarnemingen en eventueel aangepaste objectkenmerken worden teruggeleverd. 26

Gegevens die al in het GWSW-Bas (basismodel) zijn gemodelleerd worden toegepast binnen het GWSW-Rib. Dat geldt met name voor de (waargenomen) kenmerken van de geïnspecteerde objecten. In de volgende tabel staan de concepten die binnen GWSW-Bas zijn gemodelleerd en voor GWSWRib worden gebruikt. Naam concept GWSW-Bas

Opmerking

VrijvervalRioolleiding

Project hasPart Insp/Rein hasInput … (projectdefinitie) Project hasPart Insp/Rein hasOutput … (projectresultaat)

StartNodeReference (geen GWSW-Bas)

BeginpuntLeiding EindpuntLeiding PositieBeginpunt PositieEindpunt ProjectreferentieOpdrachtnemer

Opmerking: StartNodeReference is een GWSW-Rib concept. In het OroX verwijst dit concept (hasReference) naar één van de GWSW-Bas concepten BeginpuntLeiding of EindpuntLeiding (zie verder). De bijbehorende coördinaten (AAC, GAC) zijn altijd afgeleid en worden niet in het OroX opgenomen

Leidingoriëntatie hasPart Beginpunt hasConnection Putoriëntatie isAspectOf … Leidingoriëntatie hasPart Eindpunt hasConnection Putoriëntatie isAspectOf … Leidingoriëntatie hasPart Beginpunt hasAspect Positie hasAspect … Leidingoriëntatie hasPart Eindpunt hasAspect Positie hasAspect … Project hasAspect … (wordt bij projectresultaat bij deelactiviteit vermeld: opdrachtcode inspecteur/reiniger)

ProjectreferentieOpdrachtgever

Project hasAspect …

Opdrachtgever

Project hasInput …

Inspecteur

Project hasOutput …

Reiniger

Project hasOutput …

Locatie (=Straatnaam)

… hasPart Object

Kern

… hasPart Object (kan ook stelsel zijn)

27

Code Norm

Van toepassing op Object

Project

AAA GAA

Leiding Leiding

Inspectie Reiniging

AAB GAB (AAC) (GAC)

Leiding Leiding

Inspectie Reiniging

AAD GAD

Leiding Leiding

Inspectie Reiniging

AAF GAF

Leiding Leiding

Inspectie Reiniging

AAE GAE AAG GAG ABI CBI EBI GBI JBI ABJ CBJ EBJ GBJ JBJ AAM CAM EAM GAM JAM ABH CBH EBH GBH JBH AAJ CAJ EAJ GAJ JAJ

Leiding Leiding Leiding Leiding Leiding Rioolput Kolk Leiding Rioolput Leiding Rioolput Kolk Leiding Rioolput Leiding Rioolput Kolk Leiding Rioolput Leiding Rioolput Kolk Leiding Rioolput Leiding Rioolput Kolk Leiding Rioolput

Inspectie Reiniging Inspectie Inspectie Inspectie Inspectie Insp+Rein Reiniging Reiniging Inspectie Inspectie Insp+Rein Reiniging Reiniging Inspectie Inspectie Insp+Rein Reiniging Reiniging Inspectie Inspectie Insp+Rein Reiniging Reiniging Inspectie Inspectie Rein+Insp Reiniging Reiniging

AAN CAN EAN GAN

Leiding Rioolput Kolk Leiding

Inspectie Inspectie Rein+Insp Reiniging

JAN

Rioolput

Reiniging

Leiding Rioolput Kolk Leiding Rioolput Leiding Rioolput Leiding Rioolput Leiding Rioolput Kolk Leiding Rioolput Leiding

Inspectie Inspectie Rein+Insp Reiniging Reiniging Inspectie Inspectie Reiniging Reiniging Inspectie Inspectie Rein+Insp Reiniging Reiniging Inspectie

Leiding Leiding Leiding Leiding Leiding Leiding

Inspectie Reiniging Inspectie Reiniging Inspectie Inspectie

SoortLining

AAO CAO EAO GAO JAO … hasPart Object AAP CAP GAP JAP Project hasPart Inspecteren hasAspect ABF … CBF EBF Project hasPart Reinigen hasAspect … GBF JBF Object hasAspect … (generalisatie van ABQ “verwachte lengte inspectie”) Object hasAspect … ACA GCA Object hasAspect … ACB GCB Object hasAspect … (alleen breedte ACC (geen hoogte): omzetten naar hoogte GCC (geen breedte) Object hasAspect … ACD GCD Object hasPart Lining hasAspect … ACE

Leiding Leiding Leiding

Inspectie Reiniging Inspectie

MateriaalLining

Object hasPart Lining hasAspect …

ACF

Leiding

Inspectie

LengteBuisdeel

Object hasPart Buisdeel hasAspect …

ACG

Leiding

Inspectie

ReinigenVrijvervalLeiding

… hasInput Object (als reiniging voorkomt als activiteit binnen het project: leiding is vooraf gereinigd) Afleiden uit: Object hasAspect Begindatum

ACM

Leiding

Inspectie

ACN CCN ECN AXB CXB

Leiding Rioolput Kolk Leiding Rioolput

Inspectie Inspectie Inspectie Inspectie Inspectie

AXE CXE AXF GXF AXG GXG AXH GXH AXY GXY CAA JAA

Leiding Rioolput Leiding Leiding Leiding Leiding Leiding Leiding Leiding Leiding Rioolput Rioolput

Inspectie Inspectie Inspectie Reiniging Inspectie Reiniging Inspectie Reiniging Inspectie Reiniging Inspectie Reiniging

CAB EAB JAB CAS

Rioolput Kolk Rioolput Rioolput

Inspectie Rein+Insp Reiniging Inspectie

CCD ECD JCD CCG

Rioolput Kolk Rioolput Rioolput

Inspectie Rein+Insp Reiniging Inspectie

District

VrijvervalRioolstelsel

Inspectiedatum Reinigingsdatum LengteLeiding VormLeiding HoogteLeiding BreedteLeiding MateriaalLeiding

JaarVanIngebruikneming

… hasPart Object (kan ook stelsel zijn)

Verhardingstype

Straat hasPart Object + Straat hasAspect Verhardingstype

Wanddikte

Object hasAspect …

Verbindingstype

Object hasAspect …

BobBeginpuntLeiding

Leidingorientatie hasPart Beginpunt hasAspect Positie hasAspect … Leidingorientatie hasPart Eindpunt hasAspect Positie hasAspect … Object hasAspect …

BobEindpuntLeiding Leidingorientatie Rioolput

Positie Putdekselniveau

Project hasPart Insp/Rein hasInput … (projectdefinitie) Project hasPart Insp/Rein hasOutput … (projectresultaat) Putorientatie hasAspect … (generalisatie van PutCoordinaat)

MateriaalPut

Rioolput hasPart Putdeksel hasAspect Dekselorientatie hasAspect Positie hasAspect … Object hasAspect …

LengtePutdeel

Object hasPart Putdeel hasAspect …

28

JCG ReinigenRioolput

VormDeksel MateriaalDeksel LengteDeksel BreedteDeksel Kolk

ReinigenRioolput hasInput … (als CCM reiniging voorkomt als activiteit binnen het project: put is vooraf gereinigd) Object hasPart Putdeksel hasAspect … CCO JCO Object hasPart Putdeksel hasAspect … CCP JCP Object hasPart Putdeksel hasAspect … CCQ JCQ Object hasPart Putdeksel hasAspect … CCR JCR Project hasPart Insp+Rein hasInput … EAA (projectdefinitie) Project hasPart Insp+Rein hasOutput … (projectresultaat)

6.4 Specificaties: kenmerken en waarden 6.4.1

Headergegevens

29

Rioolput

Reiniging

Rioolput

Inspectie

Rioolput Rioolput Rioolput Rioolput Rioolput Rioolput Rioolput Rioolput Kolk

Inspectie Reiniging Inspectie Reiniging Inspectie Reiniging Inspectie Reiniging Rein+Insp

6.4.2

Waarnemingen

20150904: Opmerking Codes van waarnemingen en headergegevens variëren per context. Voor het reiniging van een leiding worden bijvoorbeeld andere codes gebruikt dan voor het inspecteren van een leiding. Om dat onderscheid te kunnen maken is in de GWSW-Ontologie een datatype aan de code toegevoegd. Dat datatype representeert het geldende notatieschema. :StartNodeReference skos:notation “AAB"^^:Dt_Notation_IL . (inspecteren leiding) :StartNodeReference skos:notation "GAB"^^:Dt_Notation_RL . (reinigen leiding) De volgende afkorgingen worden gehanteerd: IL = inspecteren leiding RL = reinigen leiding IP = inspecteren put RP = reinigen put RK = reinigen/inspecteren kolk RS = stortbon reinigen

De klokstanden bij waarnemingen verschijnen in 3 soorten: · CircumferentialLocation1 · CircumferentialLocation_1And2 ( kan aspect CircumferentialLocation2 hebben) · CircumferentialLocation_1Opt2 (moet aspect CircumferentialLocation2 hebben) Klokstand 2 is dus als aspect van klokstand 1 gemodelleerd. Dit is gedaan om het OroX compact te houden en om de al dan niet verplichte klokstand-combinaties eenvoudig te kunnen beschrijven.

30



31

7 BIM op basis GWSW-Bas: Gestructureerd inlezen Er zijn verschillende wijzen van aanpak. In dit hoofdstuk wordt dan ook een voorbeeld van een stappenplan beschreven.

7.1 Selecteren/doorlopen triples vanuit het OroX-bestand · Gebruik dotNetRdf om een OroX-bestand te parsen naar Triples (prestaties ok: 100000 feiten < 1 sec). · Enkele methoden om de dataset (met triples) te doorzoeken: ° Plaats de dataset in een relationele database, een tabel met de drie kolommen. Gebruik SQL om de dataset te ondervragen ° Hou de dataset beschikbaar als triplestore (gebruik een library zoals dotNetRdf) en ondervraag de dataset met SPARQL. ° De nodige queries beperken zich tot selecteren op subject, relatie of object. Voor die overzichtelijke functies kunnen ook interne containers (bijvoorbeeld of <map> van C++ STL) gebruikt worden. Met containerfuncties (zoals “find”) kan zo’n dataset effectief worden doorzocht. · Selecteer op de relatie rdf:type om alle “individuals” in de dataset te vinden · Selecteer op de relatie rdfs:label om de gangbare namen bij de individuals te achterhalen · Selecteer op de relaties :hasPart om de samenstelling van individuals te achterhalen. Bijvoorbeeld rioolstelsel “DM” heeft als deel rioolput “DM/0980”. · Selecteer op de relatie :hasAspect om de kenmerken bij de individuals te lezen, zoek vervolgens op de relaties :hasValue of :hasReference om de bijbehorende waarde in te lezen · Selecteer op de relatie :hasCollection om de verbindingen tussen topologische individuals (middelpunt put, beginpunt leiding, eindpunt leiding) te achterhalen.

7.2 Putten inlezen

· Doorloop de dataset en selecteer op basis van de GWSW-Naam (of –Id) de aanwezige stelsels (alle soorten: vrijverval rioolstelsel, drukrioleringssysteem, …) · Doorloop de dataset en selecteer op basis van de relatie :hasPart de onderdelen van het stelsel. · Bepaal per onderdeel op basis van de GWSW-Naam (of –Id) of het een put is (alle soorten: inspectieput, overstortput, pompput, …) · Doorloop de kenmerken per put (relatie :hasAspect) en bepaal de bruikbaarheid: is het bekend of relevant binnen de native database · Voor het inlezen van de putcoördinaten: Doorloop de kenmerken (relatie :hasAspect) en zoek de bijbehorende Putoriëntatie, zoek vervolgens naar de Positie (relatie :hasAspect), dan de X/Y aspecten (relatie :hasAspect) en vervolgens de waarden (relatie :hasValue)

7.3 Leidingen inlezen

· Doorloop de dataset en selecteer op basis van de GWSW-Naam (of –Id) de aanwezige stelsels (alle soorten: vrijverval rioolstelsel, drukrioleringssysteem, …) · Doorloop de dataset en selecteer op basis van de relatie :hasPart de onderdelen van het stelsel. · Bepaal per onderdeel op basis van de GWSW-Naam (of –Id) of het een leiding is (alle soorten: persleiding, vrijverval rioolleiding, …) · Doorloop de kenmerken per leiding (relatie :hasAspect) en bepaal de bruikbaarheid: is het bekend of relevant binnen de native database 32

· De verbindingen tussen leidingen en putten zullen ook in de native database staan, vaak in de vorm van de beginputnaam en eindputnaam als attribuut bij de leiding. Om deze verbindingen te vinden: Doorloop de kenmerken (relatie :hasAspect) en zoek de bijbehorende Leidingoriëntatie. Zoek vervolgens per Leidingoriëntatie het Beginpunt Leiding en Eindpunt Leiding (relatie: hasPart). Zoek bij het begin/eindpunt de koppeling (relatie :hasConnection, symetrisch) met de Putoriëntaties (of Compartimentoriëntaties). Bij de relatie :hasConnection is de positie subject/object (links/rechts) willekeurig. Zoek vanuit de Putoriëntatie naar de Putnaam (relatie :hasAspect).



33

8 BIM op basis GWSW-Rib: Gestructureerd inlezen Zie het vorige hoofdstuk voor de basisprincipes. In het OroX op basis van het GWSW-Rib zijn activiteiten met invoer (de leiding, put, kolk) en uitvoer (de waarnemingen) gemodelleerd. Een OroX op basis van GWSW-Rib met de resultaten van inspecties en/of reiniging is veelal omgezet vanuit het zogenaamde RibX-formaat. Bij die omzetting zijn een aantal aannames gedaan (met name over de typering van put en leiding) die relevant zijn bij het inlezen van het BIM: In het RibX wordt een leiding en put als volgt geïdentificeerd: 980-987/2 980 987/2 Opdrachtgever 250

(de header bij een leiding) (de leidingnaam) (de put bij beginpunt) (de put bij eindpunt) (de naam van de opdrachtgever) (de diameter van leiding)

(de header bij een put) 980 (de putnaam) (de coördinaten van de put) 168508.00 442706.30

De omzetting van die RibX-gegevens naar een BIM in OroX gaat als volgt:

34

Eerst de put vanuit : bim:Put1 bim:PutOri1 [ [ [

rdf:type rdfs:label :hasAspect rdf:type :hasAspect rdf:type :hasAspect rdf:type :hasValue

:Rioolput ; “980” ; bim:PutOri1 . :OrientatiePut ; :Positie

(meer detail is er niet bekend) (vanuit element ) (de x-coordinaat vanuit )

:X_coordinaat ; 168508.00 ] ] ] .

Dan de leiding vanuit : bim:Leiding1 bim:Dia1

rdf:type rdfs:label :hasAspect rdf:type :hasValue

:VrijvervalRioolleiding ; “980-987” ; bim:Dia1 . :BreedteLeiding ; 250 .

(meer detail is er niet bekend) (vanuit element )

De koppeling van de leiding met de al bekende put: bim:Leiding1 bim:Ori1 bim:Bpunt1

:hasAspect rdf:type :hasPart rdf:type :hasConnection

bim:Ori1 . :LeidingOrientatie ; bim:Bpunt1 . :BeginpuntLeiding ; bim:PutOri1 .

(op basis van de putnaam “980” kan de verbinding gelegd worden)

De rioolput “987/2” uit element wordt niet gevonden, die wordt aangemaakt: bim:Put2 bim:PutOri2

rdf:type rdfs:label :hasAspect rdf:type

:Rioolput ; “987/2” ; bim:PutOri2 . :OrientatiePut .

(meer detail is er niet bekend) (vanuit element )

De koppeling van leiding met put “987/2”: bim:Ori1 bim:Epunt1

:hasPart rdf:type :hasConnection

bim:Epunt1 . :EindpuntLeiding ; bim:PutOri2 .

(op basis van de putnaam “980” kan de verbinding gelegd worden)

8.1 Activiteiten inlezen

· Doorloop de dataset en selecteer op basis van de GWSW-Naam (of –Id) het aanwezige inspectie- of reinigingsproject · Doorloop de dataset en selecteer op basis van de relatie :hasPart bij het project de uitgevoerde inspectie- of reinigingsactiviteiten (Visueel Inspecteren Inspectieput, enz.)

8.2 Geïnspecteerde objecten bepalen

· Doorloop de inspectie- of reinigingsactiviteit en selecteer op de relatie :hasInput met als object de referentie naar de leiding, rioolput of kolk. · De leiding, rioolput of kolk is conform het GWSW-Bas gemodelleerd, dat geldt ook voor de kenmerken van het object zoals materiaal, diameter zijn met de relatie :hasAspect. Die kenmerken kunnen ook resultaat van een activiteit (zoals een geconstateerd materiaal) zijn.

35

8.3 Resultaten inlezen

· Doorloop per inspectie- of reinigingsactiviteit de inspectieresultaten, selecteer op de relatie :hasOutput. De gevonden objecten zijn aanvullende headergegevens of waarnemingen. · De waarnemingen bevatten toestandsaspecten van het eerder gevonden inspectie/reinigingsobject · Doorloop per waarneming de kenmerken (relatie :hasAspect) om aanvullende informatie over afstand, karakteristieken en dergelijke te achterhalen



36

9 Gereedschappen en testresultaten Zoals genoemd komt op langere termijn met de inrichting van de Semantische Server door RIONED voor applicatiebouwers in het GWSW.OroX traject meer functionaliteit ter beschikking. Dit omvat: · Ondervragen GWSW-ontologie (via eigen en standaard SPARQL-queries); · Uploaden BIM-modellen als Turtle-bestand (naar BIM-triplestore); · Bijwerken/vullen BIM-triplestore via SPARQL of uploads; · Valideren BIM-inhoud (juiste syntax, restricties op basis GWSW-ontologie); · Ondervragen BIM via SPARQL of browsing, eventueel in combinatie met GWSW-Model; · Geautoriseerde toegang per database (BIM): editen en/of viewen.

9.1 Export naar GWSW.OroX (Turtle / Triplestore) In het eerste deel van het GWSW.OroX traject wordt minimaal een export in Turtle-formaat gemaakt. Bij de transformatie van de native database naar een GWSW.OroX kunnen de volgende tools ondersteunen: · Export van uit Relationele database naar Triplestore ° GWSW_Lijsten: alle relevante GWSW-concepten en relaties ° HTML-presentatie (vooralsnog vanuit Topbraid) van het GWSW model ° Een tool als D2RQ, een server voor mapping SQL versus SPARQL, is vooralsnog te generiek. Het voorgedefinieerde GWSW-model zou veel toegesneden aanpassingen vergen. ° Zoals genoemd kan export via SPARQL-constructs naar een generieke Triplestore en van daaruit naar alle soorten RDF-formaten. Voor de verwerking van SPARQL-queries zijn er freeware-apps zoals Protégé, TopBraid, Jena-Fuseki. De kans is echter groot dat de SPARQLsyntax hiervoor nagenoeg het uiteindelijke Turle-formaat benaderd. ° Het SPARQL Protocol kent ook HTTP bindings. Er zijn bibliotheken/API’s zoals SNARL Linked Data API (native Stardog) of dotnetRDF om via HTTP triplestores te benaderen. · Valideren geëxporteerde triplestore (in Turtle-formaat) ° Pellet-reasoner is te adviseren, commandline based of als plug-in bij Protégé ° HTML-presentatie van BIM (analoog aan GWSW-model) ° Er zijn gecombineerde viewer/editors voor RDF-modellen beschikbaar. Voor het view- (en validatie-) aspect is relevant: - Protégé is een RDF-editor en –viewer. De Pellet reasoner draait als plug-in binnen Protégé. - Topbraid is de profesionele variant van Protégé. Bevat bijvoorbeeld de HTML-export. De eerste ervaring met Protégé met heel grote BIM’en zijn niet goed, mogelijk is Topbraid een goede variant.

9.2 Import van GWSW.OroX-bestand (Turtle) De importfunctie is ook van breder belang omdat daarmee een cirkeltest, via de import van het eerder geëxporteerde GSWW.OroX bestand, kan worden uitgevoerd. Zoals besproken is het Turtle-bestand relatief eenvoudig van opbouw, maar het kan vanwege de mogelijke afkortingen vele vormen aannemen. Er zijn op het web gelukkig veel tools beschikbaar die bij de import kunnen assisteren. Voor de dotnet-omgeving is een goed voorbeeld het eerder genoemde dotNetRDF. 37

dotNetRDF is een goed verzorgd open source pakket voor verwerken van RDF triples. Inclusief Wiki met uitgebreide handleiding: https://bitbucket.org/dotnetrdf/dotnetrdf/wiki/Home Na download van de libraries (sources zijn niet nodig) kan in de dotnet-omgeving gerefereerd worden aan dotNetRDF.dll. Daarna is het een kleine stap een Turtle-bestand in te lezen en te verwerken. Als voorbeeld deze code (onder C++/CLR):

short cOro::ReadOroTtl(char *nam) { // Lees het GWSW-BIM Turtle-besand *nam // Namespace VDS::RDF: Referentie naar ..\..\Utilities\dotNetRDF\Libraries\Core\net40\dotNetRDF.dll // Load a Graph from a File VDS::RDF::Graph ^g = gcnew VDS::RDF::Graph(); VDS::RDF::Parsing::TurtleParser ^ttlparser = gcnew VDS::RDF::Parsing::TurtleParser(); ttlparser->Load(g, STRING(nam)); // Lees het BIM, zet in graph VDS::RDF::INamespaceMapper ^nsw = g->NamespaceMap; // De namespace mapper (gebruikte Turtle-prefixes) System::String ^sPrf; // String met prefix ipv URI System::String ^Subj, ^Pred, ^Obj; // De uit te lezen triples (subject, predicate, object) VDS::RDF::Triple ^tri; for each (tri in g->Triples) // Lees al de triples uit de Graph (= turtle bestand) { if (tri->Subject->NodeType == VDS::RDF::NodeType::Blank) Subj = tri->Subject->ToString(); else { nsw->ReduceToQName(tri->Subject->ToString(), sPrf); // Zet URL om naar prefix (bim:, :, _:) if (sPrf == "") // Geen prefix = Subj = tri->Subject->ToString(); else Subj = sPrf;

} nsw->ReduceToQName(tri->Predicate->ToString(), sPrf); // Zet URL om naar prefix (bim:, :, _:) Pred = sPrf; if (tri->Object->NodeType == VDS::RDF::NodeType::Blank) Obj = tri->Object->ToString(); else if (tri->Object->NodeType == VDS::RDF::NodeType::Literal) // Waarde (numeriek / string) (inclusief datatype: 1000^^xsd:integer) Obj = tri->Object->ToString(); else { nsw->ReduceToQName(tri->Object->ToString(), sPrf); // Zet URL om naar prefix (bim:, :, _:)

}

} } return 0;

if (sPrf == "") // Geen prefix = Obj = tri->Object->ToString(); else Obj = sPrf;

9.3 Proefnemingen met OroX 9.3.1

Gemeente Pijnacker – 20151113

Omvang (na OroX import in Obsurv) Putten Leidingen Kenmerken per put (ca) Put-onderdelen (compartimenten) Kenmerken per leiding (ca) Leiding-knikpunten Leiding-reinigingen Leiding-inspecties

7500 9600 8 0 10 53000 0 0

Bijzonderheden: · Grondsoort erin (aspect van ondergrond, ondergrond bevat object) · Knikpunten komen mee, wel alles dubbelop, niet alle verbindingen correct Export GWSW-OroX via Kikker Omvang: 3.160.000 regels / 1.540.000 triples / 118 Mb 38

Export bestand bevat syntax fouten en veel dubbelingen. Achteraf gecorrigeerd met ConvTxt.exe (1 Mb eraf, dubbele) Import GWSW-OroX via Obsurv Snelheid: ca. 3 min Import GWSW-OroX via GraphDB Import GWSW-BIM-Orox: ca 0,5 min Upload GWSW-Ontologie, combineren met BIM, inclusief OWL inference: circa 40 min 9.3.2

Gemeente Zwolle – 20151112

Omvang (na OroX import in Obsurv) Putten Leidingen Kenmerken per put (ca) Put-onderdelen (compartimenten) Kenmerken per leiding (ca) Leiding-knikpunten Leiding-reinigingen Leiding-inspecties

20000 20000 8 136 14 900 3500 3500

Bijzonderheden: · Knikpunten correct komen mee · Activiteiten reinigen en onderhoud komen mee (alleen datum, input = leiding) Export GWSW-OroX via Obsurv Omvang: 2.370.000 regels / 1.610.000 triples / 94 Mb Snelheid: ca. 2 min Import GWSW-OroX via Obsurv Snelheid: ca. 3 min Import GWSW-OroX via GraphDB Import GWSW-BIM-Orox: ca 0,5 min Upload GWSW-Ontologie, combineren met BIM, inclusief OWL inference: circa 55 min 9.3.3

Gemeente Pijnacker – 20160209

Import laatste versie: Omvang 2.115.000 regels / 1.063.000 triples / 75 Mb Snelheid: ca. 2 min (primaire inleesactie 65 sec) Opmerkingen bij OroX-export Kikker (kikker_vrij.ttl): Onbekend element Fundering: · kode hr Onbekend element Grondsoort: · klei/zand/veen · venige klei · zand/klei/veen Onbekend element Materiaal: · fictief · h.p.e. 0.63 mpa 39

· overig · volgeschuimd gres · volgeschuimd pvc Onbekend element Vorm: · overig 9.3.4

Gemeente Den Haag – 20160210

Opmerkingen bij OroX-export Kikker: Onbekend element Fundering: · kend · fundering · ingegraven in zand/duin · riool in betonconstructie Onbekend element Grondsoort (??) · boorkernklasse d1 · boorkernklasse d2 · boorkernklasse d3 · boorkernklasse d4 · boorkernklasse d5 · geen boorkern · kend Onbekend element Materiaal: · relining kousmethode · polypropyleen/polypp vez…. · 00 sdr 17 · polypropyleen/sedi buis · h.p.e. · relining wikkelmethode · relining dubb. Inschuifmethode… · fiktief · relining kousmethode/asb…. · 0 sdr 11 · sdr 34 · vervallen/volgeschuimd · hoge druk poly ethyleen · beton met staalkern · 0 sdr 17 · sdr 26 · 5 sdr 11 · 00 sdr 11 Onbekend element Vorm: · tunnelprof. a:1610*1800…. · rechthoekig/trapeziumvor… · bosbuis · …. nog meer merknamen 9.3.5

Gemeente Barneveld – 20160218 40

Opmerkingen bij OroX-export Kikker: Onbekend element Materiaal: · hpe · beton infiltratie · overig · pvc infiltratie 9.3.6

OroX-export Kikker – fijntunen

9.3.6.1 Opgelost in Orox-export Kikker: #mv: diameter, ook breedte en lengte (dubbelop) # afspaak maken in OroX (1 van beiden gebruiken) bim:knp010002_dia rdf:type :DiameterPut . #mv: lengte put consequent 100x te groot bim:knp027014_len rdf:type :LengtePut . bim:knp027014 :hasAspect bim:knp027014_len . bim:knp027014_len :hasValue 80000 . #mv: datum format moet zijn jjjj-mm-dd bim:knp027103_beg rdf:type :Begindatum . #mv: zie putten, bre en hoo naast dia bim:lei222280-222304-155290_bre rdf:type :BreedteLeiding . #mv: drukleiding ipv vv-leiding ?? (nu als mechnische leiding vermeld) bim:lei108011-108257-154451 rdf:type :VrijvervalRioolleiding ; rdfs:label "108011-108257-154451" . #mv: wanddikte bij rond 63? (wanddikte is niet meer opgenomen) bim:lei108011-108257-154451_wan :hasValue 130 . #mv: ontbrekende afsluitende quote (tig-keer) :hasValue "duikersloot, pijnacker" . #mv: dubbel (tig-keer) bim:hm_12_pijnacker_nootdorp :hasPart bim:lei254621-254628-151104 . #mv: 2x connectie met put en edge bim:leiV23006-V23007-155762_lei6398_beg6398 :hasConnection bim:knpV23006_put9496 . #mv: knikpunten niet nodig?? bim:leiV23006-V23007-155762_lei6398_kni22280 rdf:type :KnikpuntLeiding . bim:leiV23006-V23007-155762_lei6398 :hasPart bim:leiV23006-V23007-155762_lei6398_kni22280 . #mv: z-coordinaat 0 - niet melden bim:lei222754-222755-156176_lei1896_kni12320_pos12320_z_c rdf:type :Z_coordinaat . bim:lei222754-222755-156176_lei1896_kni12320_pos12320 :hasAspect bim:lei222754-222755156176_lei1896_kni12320_pos12320_z_c . bim:lei222754-222755-156176_lei1896_kni12320_pos12320_z_c :hasValue 0.0000 . Notatie datum inclusief quotes # :hasValue 2005-01-01 . :hasValue "2005-01-01" .

Deze prefixes s.v.p. afstemmen op de laatste GWSW-inrichting: # @prefix : .

41

@prefix : . # @prefix bim: . @prefix bim: .

Deze leiding heeft knikpunten die (nagenoeg) dezelfde coördinaten als de aansluitende putten hebben. Dat geldt voor heel veel leidingen in een bepaald gebied, heeft iets met afronding te maken? bim:lei874-875-160405 rdf:type :VrijvervalRioolleiding . # put 875 heeft x/y 90129.6600/447004.2800 # knikpunt heeft x/y 90129.6640/447004.2830

In een bepaald gebied lopen veel leidingen kris-kras. Het Orox-bestand ziet er in de basis wel goed uit. Bijvoorbeeld de leiding 211035-211036: · Bevat een knikpunt (waar het eindpunt van de leiding hoort ?) · Put 211036 is wel netjes verbonden met andere leidingen Reactie Hendrik: · Het feit dat veel leidingen kris kras lopen lijkt te komen doordat deze verkeerd in GBI6 staan. Knoopnummer 211036 heeft in GBI6 andere coördinaten dan het eindpunt volgens de geometrie van de streng. Zie onderstaande weergave, waarbij knoop: 211036 ook in kikker niet aanwezig is op de plek waar die zou moeten zijn. Dit verklaard ook de overige kris-kras lijnen. Kris-kras lijnen omdat de “verkeerde” geometrie van de knoop wordt gebruikt om een edge van een streng te tekenen Gecorrigeerd: leidingen eigen geometrie, incl. begin/eindpunt

9.3.6.2 Nog op te lossen in Orox-export Kikker: Vorm rioolput ontbreekt, vaak wel breedte en hoogte vermeld (oorzaak in native-database?). Vorm bij leiding wel ok. bim:knp211618 :hasAspect bim:knp211618_bre . bim:knp211618_bre :hasValue 1000 .

Reactie Hendrik: De vorm van de rioolputten zijn onbekend in het GBI6 bestand en daarom ook niet uitgevoerd. Materiaal leiding ontbreekt vaak (oorzaak in native-database?) Reactie Hendrik: 126 km streng heeft onbekende materiaalsoort. Geen inspecties bij leiding (bijvoorbeeld inspectiedatum) opgenomen (oorzaak in native-database?). Reactie Hendrik: Inspecties worden nog niet uit GBI6 gehaald. Zal ik nog eens bekijken. GBI6 heeft een naar mijn mening wat gekke databank. 20160224: Aan datumstring nog xsd-datatype toevoegen. Zie hoofdstuk 4.2.2. Later op te lossen in Orox-export Kikker (nu niet relevant of niet urgent): #mv: deksel lijkt overbodig, aangeven dat ie er is? bim:knp028005_dek109 rdf:type :Deksel . Volgens model 1.2 is Maaiveldhoogte nog een aspect van Put Deze structuur geldt vanaf versie 1.3: # mv: maaiveldhoogte (buitenwereld, analoog aan gws) via topologie bim:knp052139_put685 :hasConnection bim:knp052139_put685_mvori . bim:knp052139_put685_mvori rdf:type :Maaiveldorientatie . bim:knp052139_maa rdf:type :Maaiveldhoogte . bim:knp052139_put685_mvori :hasAspect bim:knp052139_maa . #mv: ondergrond gebruiken voor bijv aspect grondsoort

42

# 1 ondergrond kan meerdere objecten bevatten bim:knp028006_ond110 rdf:type :Ondergrond .

43

Bijlage: Bijeenkomsten kopgroep GWSW.OroX De kopgroep bestaat uit de applicatiebouwers van drie belangrijke beheersystemen op het gebied van Stedelijk Water: Riodesk/Kikker/Hendrik Kingma, Antea Group/GBI6/Frank Zwiers en Grontmij/Obsurv/Marinus Vonhof. Het doel van deze groep is te komen tot de eerste daadwerkelijke uitwisseling op basis van het RDF/Turtle formaat. In deze bijlage zijn de overlegverslagen opgenomen. Overleg 7 oktober 2015 – GWSW-Rib Vervolgoverleg: OroX toepassen op GWSW-Rib. Behandelde punten: · Frank oppert om nu ook UID’s ook voor BIM-objecten te gaan hanteren. Marinus heeft dat ondertussen bij RIONED in de week gelegd. Heeft veel potentie. · Binnen het GWSW zou ook meer het uitwisselingsproces meegenomen kunnen worden, bijvoorbeeld een was/wordt functie bij uitwisseling (bij retourlevering vlag “verwijderd”, “gewijzigd”, “aangepast”). · GWSW_Lijsten zo mogelijk compleet maken, niet opsplitsen per module. Marinus gaat na of dit met een redelijke performance te regelen is. · Marinus heeft een eerste opzet gemaakt voor OroX / Rib. Van het principe uitgaan dat zoveel mogelijk gebruik wordt gemaakt van OroX / Bas modellering. Niet één op één het RibX nabouwen in OroX. Marinus werkt dit verder uit. · Om de uitwisseling compact te houden worden voor de UID van de waarneming de codering gehanteerd. Deze zijn in de inspectiewereld voldoende begrijpelijk. · Het OroX-Bas is nog niet met complete vulling getest. Hendrik heeft alle velden opgenomen, Marinus gaat dat ook doen. Hendrik/Marinus: Let op omgaan met straatnaam, grondsoort. Toets het model. Ook drempel, hoe verbindt je een wand aan compartimenten. Hou vast aan model Bas-1.2

Overleg 19 augustus 2015 – Afronding GWSW-Bas 20150603: RioDesk en Grontmij verwachten dan de beta-versies op te kunnen leveren. Antea Group zal het definitieve OroX in het voorjaar van 2016 opleveren (nieuwe release 2x/jaar). Antea Group zal de export verder uitwerken, de import is nog niet ingepland.

· Ervaringen uitwisselen: ° Frank heeft met Visual Basic proefnemingen gedaan met de import via de DotNetRdf-SDK. Hij stelt de werkwijze ter discussie, nadat de triples (bijvoorbeeld via DotNetRdf) vanuit OroX “geparst” zijn, volgen er globaal gezien drie methoden van verwerken: - Inlezen in interne containers (bijvoorbeeld of <map> van C++ STL) en containerfuncties (zoals “find”) gebruiken voor selecties - Triples in Oracle-tabel opslaan en vervolgens via SQL bevragen - Triples in DotNetRdf-library (of een variant daarvan) houden en vervolgens via SPARQL bevragen De eerste methode wordt door Marinus/Hendrik gebruikt. Frank gebruikt nu de tweede methode maar neigt tot het gebruik van SPARQL (methode 3). ° Hendrik heeft de im- en export functies verder uitgetest. Hij loopt wel tegen enkele nietbestaande concepten aan in het voorbeeld BIM (item :Locatie). Marinus kijkt het na. Hendrik wil graag doortesten met “echte” praktijk gevallen. Marinus stuurt enkele (grotere) OroX-exports vanuit Obsurv naar Hendrik. 44

° Marinus heeft ook de im- en export functies verder uitgewerkt. Nu kunnen ook de compartimenten binnen rioolputten inclusief positionering worden uitgewisseld. · Vaststellen GWSW.OroX formaat ° Uit de tests komen geen verdere aanpassingen van de OroX-semantiek naar voren, deze OroX-versie kan worden vastgesteld. Wel benadrukt Frank dat we hiermee niet achterover kunnen gaan leunen. De verwachtingen van de gebruikers richten zich vooral op het GWSW-Rib, daarover zijn met de GBI-gebruikers afspraken gemaakt. Ook Hendrik benadrukt dat belang. Frank en/of Marinus zullen dit bij RIONED aankaarten, zie ook de opmerkingen bij het overleg van 20150603. Werkgroep GWSW-Basis. De werkgroep is onder de noemer van GWSW-MDS (minimale dataset) gebracht. Het eerstvolgende overleg is op 25 september 2015. De werkgroep is breed (gemeentes, waterschappen, leveranciers) en focust op:

° ° ° °

vaststellen conformiteitniveaus, welke gegevenskwaliteit (volledigheid, nauwkeurigheid) per toepassing uitvoeren effectanalyses in de praktijk toetsen kwaliteitsniveau (via OroX, validatie) start met ontwikkeling GWSW.RibX via OroX uitwisselen

· Voorbereiden presentatie aan de werkgroep GWSW-Basis op 25 september 2015 ° Presenteren resultaten deze werkgroep OroX, waaronder planning implementatie in beheersystemen. Gezamenlijk optrekken, aandacht voor verwachtingen Almere c.a. - Marinus breidt een Powerpoint presentatie voor ° Uitwisselbestand van Kikker naar Obsurv en vise versa? (aandacht voor snelheid, omvang) - Frank en Hendrik zullen een live-demo voorbereiden. De export is mogelijk vanuit GBI, met Kikker kan de import worden aangetoond. ° Demonstratie Semantische Server, upload + validatie - Als dit aan de orde komt kan Marinus hiervan een live-demo geven. Overleg (3 juni 2015) · Ervaringen uitwisselen: ° Frank heeft eerste export gemaakt. Het uitwerken van de import, waar het gebruik van een Turtle parser meespeelt, zet Frank intern uit. De planning daarvan is nu nog ongewis. De topologie structuur is nog even wennen. Daarnaast heeft Frank de labeling uit het GWSW 1.1 gebruikt binnen de Oracle-database van GBI. Wel hiermee oppassen, de labeling is niet perse uniek in de GWSW.RDF Ontologie (zie verder). De labeling wordt waar nodig (bijvoorbeeld collectie-elementen) toegevoegd aan GWSW-Lijsten, zodat Frank de mapping kan realiseren. ° Hendrik heeft een eerste export gemaakt. De programmacode voor de oude Gellish-BIM is grotendeels bruikbaar. De triplestore wordt als omslachtig ervaren, maar ook als heel flexibel. De bouw van de complete import/export gaat lukken voor het volgende overleg. ° Marinus heeft eveneens een eerste export (en import) gemaakt. Gelijk aan Hendrik is de vorige programmacode relatief eenvoudig bruikbaar. Als parser voor de omzetting van Turtle naar Triples (bij de import) is dotNetRDF toegepast. Zie ook het voorbeeld in hoofdstuk 6.2. · De RDF-syntax beoordelen op volledigheid (kan elk GWSW-BAS bouwwerk er in beschreven worden): ° De concepten Knooppunt en Verbinding zijn bedoeld om een rioleringsschema voor hydraulische modellering te representeren. Deze verwijderen uit het GWSW-Bas model, zijn nu verwarrend. · Een importfunctie maken in de beheerapplicatie, RDF (Turtle) naar Relationele Database 45

· Een cirkeltest uitvoeren (tussen meerdere beheersystemen) levert import/export consistente gegevens op? 20150603: Antea Group ontwikkelt geen aparte RibX import/export. Zij sluiten aan bij het GWSW-concept waarbij alle uitwisseling via OroX plaatsvindt. Grontmij houdt deze lijn ook vast. Om praktische redenen (lopende projecten) heeft RioDesk wel de RibX import/export ontwikkeld. Frank dringt er om deze redenen op aan dat de OroX uitwisseling voor het GWSW-Rib zo snel mogelijk na dit traject wordt opgepakt.

Startoverleg (6 mei 2015) · GWSW.RDF Ontologie behandelen, mapping op nummers en namen. Voorlopig alleen de GWSW-BAS context, dat zijn de basisgegevens voor een beheersysteem. Daarmee kan de stelselopbouw worden beschreven en bijvoorbeeld een voorinvulling voor RibX worden gemaakt. · OroX-formaat (Turtle) bespreken · Vulling van een OroX, hoe structureren we de gegevens · Tools behandelen (HTML-viewer, GWSW_Lijsten, Protégé). Eerst lokale situatie uitwerken. · Als gezamenlijk testgebied het oorspronkelijk Gellish-BIM gebruiken. Zie ook hoofdstuk 5.1 20150603: Hendrik levert UUD (import voor GBI) hiervan aan Frank.

· Een exportfunctie maken in de beheerapplicatie, Relationele Database naar RDF (Turtle) 20150508: Vakantieplanning • Frank: gehele maand juli • Hendrik: midden juli – begin augustus • Marinus: gehele maand juni

46