stichting-crow / imbor

Een informatiemodel en objecttypenbibliotheek (né ontologie) voor assetbeheer van de openbare ruimte

IMBOR (Informatiemodel Beheer Openbare Ruimte)

Het IMBOR uniformeert begrippen voor het vakgebied ‘beheer openbare ruimte’. CROW

Deze repo is gestart m.b.t. de documentatie omtrent de ontwikkeling en het gebruik van IMBOR in LinkedData-formaat. Medio 2021 is deze repo volledig overgegaan op volledig IMBOR.

Deze repository wordt gebruikt voor de actieve ontwikkeling van IMBOR.

Middels de GitHub Issues kunnen bug/features/aanbevelingen worden gegeven op IMBOR en de documentatie.

Documentatie

Documentatie met betrekking tot IMBOR is te vinden op: docs.CROW/IMBOR

Versiebeheer

CROW beraadt zich nog op een duurzame beheersstrategie ten aanzien van IMBOR in Linked data-formaat. Daar hoort ook versiebeheer bij. Zie ook issue #2

Licentie

Deze repository en IMBOR worden beschikbaar gesteld onder verschillende licenties. Zie hiervoor: Technische documentatie, sectie Licenties.

imbor's Issues

Objecttype ‘Beheerobject’ uit tabel [X_Objecttypen] wordt rdfs:subClassOf van bs:PhysicalObject

Omdat we voorzien dat het gebruik van de ontologie vooralsnog alleen maar is voor :

1. het spreken van dezelfde taal
2. het aangeven van eigenschappen per type object
   ...en daarnaast omdat het perspectief van IMBOR tot nu toe alleen maar "Beheer" is, is het simpel om Beheerobject te promoveren tot superklasse. Hierdoor worden alle eigenschappen automatisch overgeërfd naar alle onderliggende typen.
   Dit is wellicht niet geheel semantisch correct en zorgt ervoor dat we alles moeten classificeren als rdfs:subClassOf bs:PhysicalObject, maar deze issues zetten we op de roadmap IMBOR OTL.

Objecttype in de groep 'Informatiemodel', maar geen vinkje bij 'Hulpobject'

Er zijn vijf objecten die niet hulpobjecten zijn (geen vinkje hebben in X_Objecttypes), maar wel in de objecttypegroep "Informatiemodel" zitten. Dit zijn:

• Attribuut
• Hulpobject
• Niet in IMBOR
• Onbekend
• Onderdeel

Deze worden niet bijzonder behandeld.

gebruik hasPart voor raakvlakken (ReSpec document 2.2) niet altijd terecht

Ik weet dat jullie hier ook discussies over voeren.... maar ik open er toch een issue voor.

bs:hasPart is niet de juiste relatie voor o.a.
Groenobject - GroenobjectSoortnaam,
Wegas - WegasVerkeersintensiteit
en nog een paar...
Als otl:Informatiemodel als bs:InformationObject getypeerd wordt kan de bs:describes relatie gebruikt worden die volgens mij wel past hierbij?

IMBOR Vakdiscipline en IMBOR Hierarchie als superklassen

Ter volledigheid introduceren we twee hoofdklassen skos:collection, te weten "IMBOR Hierarchie" en "IMBOR Vakdiscipline". "IMBOR Hierarchie" heeft de nadere subClasses zoals bij issues #17 en #18 vermeld.

Dit onderscheidt wordt gemaakt omdat we dan kunnen zeggen welke van de collecties voor het presenteren van een voor IMBOR gebruikers bekende hierarchie gebruikt kunnen worden, en welke niet.

Taalspecifieke labels

Labels, voor objecttypes zoals "Brug" of eigenschappen als "belastingklasse", zijn taalafhankelijk.

Vanuit de NTA worden geen beperkingen opgelegd, vanuit de taalspecificatie wordt bepaald dat het welgevormd volgens BCP 47 moet zijn, zij het altijd in onderkast. Zie ook de voorbeelden aldaar.

In RDF worden Nederlandstalige literals soms niet, soms als @nl, soms als @nl-NL getagd. Eng bekeken moet @nl geïnterpreteerd worden als geldend voor de hele Nederlandse taal in alle varianten, @nl-NL als voor het Nederlands van Nederland, waarbij Vlaanderen, Suriname en de Caraïbische delen van het Koninkrijk worden uitgesloten.

CROW bedient Nederland en daarom geniet de explicietere @nl-NL mijn voorkeur.

Relaties tussen Objecttypes wordt bs:hasPart

Er bestaan relaties tussen Objecttypes, deze worden apart behandeld. Het gaat om een filter in de tabel [X_Objecttypes] op de kolom [Hulpobject], met de waarde 'Ja'

Voor deze' relaties tussen Objecttypes zijn wat ons betreft twee opties, skos:related en bs:hasPart. De semantiek van skos:related is meer correct omdat in IMBOR er nauwelijks duidelijkheid wordt gegeven over de relatie. Echter omdat we ook al losjes gekozen hebben om alles een bs:PhysicalObject te laten zijn... kiezen we er hier nu toch voor om al deze IMBOR relaties te classificeren als een bs:hasPart. Zo blijven qua objecten en hun relaties dichter bij de NTA.

Versienummering dataset en datamodel is niet bepaald

De versienummering van de dataset en het datamodel is nog niet bepaald.

Ik stel mij voor dat het datamodel zelf weinig veranderingen zal doormaken gedurende het gebruik ervan. De dataset wordt samen met IMBOR geüpdatet en zal dientengevolge halfjaarlijks een nieuwe versie krijgen.

Hoe wijzigingen aan de dataset bekend worden gemaakt en in de dataset zitten, valt buiten de scope van deze issue.

Datamodel

Voor het abstracte datamodel verwacht ik iets als v1.0.0, met typfoutjes (bugfix) hersteld in v1.0.1, uitbreidingen in een v1.1.0, terwijl verwijderingen en wijzigingen leiden tot v2.0.0.

Dataset

IMBOR is continue ontwikkeling en daarom ook de OTL BIM Pro. Bij deze ontwikkelingen worden voorstellen vastgesteld (IMBOR noemt dit gepubliceerd c.q. bevroren) voor een bepaalde periode. Voorstellen zitten daarmee in de dataset, maar kunnen op elk aspect nog wijzigen.

Voor de afnemers van de dataset kunnen we twee soorten bestanden beschikbaar stellen.

1. De volledige historische versie van IMBOR, inclusief voorstellen en niet-meer-geldige waardes.
2. De versie van IMBOR geldend op een datum. Deze bevat dan alleen vastgestelde onderdelen, zonder niet-meer-geldige waardes. Dit is ook handig voor archivering en bij contractering.

Versies van de dataset geldig-op-een-bepaalde-datum krijgen een versielabel mee van de datum op sorteervolgorde: bijvoorbeeld v20190801 voor de versie geldend vanaf 1 aug. 2019.

De volledige historische versie van IMBOR kan naast voorgenoemde datumstijl, ook versienummering krijgen parallel lopend met IMBOR. IMBOR publiceert 1-2x per jaar een nieuwe versie, e.g. 2019-1, 2019-2, 2020-1. Dan wordt de versienummering v2019.1.0, v2019.1.1, v2019.2.0, v2020.1.0 waarbij ook kleine wijzigingen (typfouten) tussendoor kunnen worden doorgevoerd.

Binnen de tabel X_AttributenDomeinwaarden laten we BovenliggendLabel weg

Binnen de tabel X_AttributenDomeinwaarden hebben sommige waardes een bovenliggend label. Deze bestaat binnen IMBOR om het scrollen door lange lijsten makkelijk te maken. In de LD versie doen we hier niets mee.

GWSW informatie wordt uit de transformatie gelaten

GWSW records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in GWSW

Er is besloten door de provincies dat alles m.b.t. riolering bij de GWSWS gelaten wordt. We willen hier niets zeggen over deze objeccttypen en eigenschappen. Vandaar dat we het geheel uit de ontologie laten om geen overlap te hebben. *uitzoeken

Versie namen releases

Wat hier op Github 0.6 versie heet, hebben we in de communicatie met de Provincies steeds 1.0 genoemd 😉

Dit jaar gaan de 2.0 en 3.0 opleveren, beide gefinancierd vanuit de Provincies.

Licentie ontbreekt

Er is geen LICENSE-bestand aanwezig in de repo.

Vastewaardelijst geniet de voorkeur boven eenheid

Bij sommige eigenschappen in Access wordt zowel naar een vastewaardelijst gewezen ALS naar de eenheden tabel. In dit geval wordt bij de transformatie naar LD, alleen de vastewaardelijst overgenomen.

attributen hebben geen language tag voor label en prefLabel

labels bij Attributen hebben geen @NL-NL tag.

bijvoorbeeld:
p:Attributen_813 rdfs:label "Draagkrachtig" ;
...
skos:prefLabel "Draagkrachtig" .

Alle concepten met de status Vervallen in IMBOR nemen we niet mee in de transformatie

Omdat we een 'nieuwe' versie aan het maken zijn nemen we geen legacy mee.

Duidelijk maken dat SPARQL-voorbeelden.ipynb gebruik maakt van inferencing

De queries in het SPARQL-voorbeelden.ipynb notebook gaan goed omdat er bovenin voor de sparql interpreter geconfigureerd is dat inferencing gebruikt moet worden.

Als je de queries uit het notebook copy-paste naar een andere omgeving gaat dat niet automatisch goed... de rdfs:subClassOf queries doen dan standaard alleen de directe subclasses. Als je de query aanpast naar rdfs:subClassOf* gaat het wel goed.

misschien goed om dat duidelijk te maken in het notebook. ik las er ook even overheen en moest even goed nadenken wat er aan de hand was...

Planning ontwikkeling IMBOR 2.0

Op verzoek van gebruikers: toevoegen van een planning voor IMBOR

Eerstvolgende release: IMBOR 2020-07, in Acces én linked data

• Tot 25 juni kunnen jullie je opmerkingen doorgeven via https://github.com/Stichting-CROW/imbor/issues
• Op 26 juni van 14.00-16.00 uur toelichting en bespreking voorgestelde wijzigingen, via Microsoft teams-overleg (jullie krijgen hiervoor een Outlook-uitnodiging)
• Tot 30 juni doorgeven laatste opmerkingen
• Tot 12 juli verwerken opmerkingen in IMBOR Access Database
• Uiterlijk 17 juli rondsturen Access Database IMBOR 2020-07 (IMBOR-versie juli 2020) naar klankbordgroep softwareleveranciers
• Augustus: publicatie IMBOR 2020-07 als IMBOR Linked Data en in de Kennismodule IMBOR

Deadline gebruikerswensen: NTB

Bijeenkomst met softwareleveranciers: NTB, in mei

Publicatiedatum: 1 juni 2020
Publicatiedatum versie 3.0: 23 december

BAG, BGT, IMKL, NEN3610, "stelsel" informatie wordt uit de transformatie gelaten

Naast issue #12, #11, #13, #14 worden ook de BAG, BGT, IMKL, NEN3610 en "stelsel" records niet overgezet naar de ontologie. Deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Deze informatie komt uit de tabel [X_Informatiemodellen.

Dat zijn aparte informatiemodellen die we vooralsnog niet in de OTLBOR moeten willen onderhouden

Introductie van directe properties voor terugvindbaarheid Access versie

Er worden in het datamodel een aantal properties geïntroduceerd die er alleen maar 'voorlopig' zijn om wat informatie kwijt te kunnen die uit Access komt. Dit betreffen:

• p:dataLabel
• p:guid
• p:geometryAsLineString
• p:geometryAsPoint
• p:geometryAsPolygon
• p:geometryAsMultiPolygon
• p:attribuutsorteergroep
• p:volgorde

Records uit [X_Objecttypes] zijn rdfs:subClassOf van alle records uit [X_Objecttypegroepen]

... uitgezonderd 'Beheerobject';
... en te identificeren d.m.v. de bestaande PK <> FK link in Access.

Objecttypegroepen worden hiermee de tweede laag in de taxonomie. Dit is wederom voor de overerving van eigenschappen. Momenteel worden de objecttypegroepen ook op deze manier gebruikt in de IMBOR. Dat wil zeggen, in de User Interface (de formulieren) van IMBOR. De data (tabellen in IMBOR) stelt het anders. Maar omdat de eindgebruiker van IMBOR ons uitgangspunt is, wordt voor deze oplossing gekozen.

IMBOR Objecttypegroepen zitten nog in de data

@redmer dit is een overblijfsel van een van onze probeersels. Misschien netjes om eruit te halen.

IMBOR Verlichtingsobjecten

De niet meer bestaande objecttypegroep Verlichtingsobjecten staat nog wel in de Access-db.

Dit moet worden aangegeven bij Jochem/Harro.

Attributen gedefinieerd als Datatypeproperty met objecttype als range

Er zijn attributen (zoals Afvoeren, maar er zijn er meer) die gedefinieerd zijn als DatatypeProperty, maar vervolgens wel een Class als range hebben (en daar mee dus ook een ObjectProperty zijn)
volgens mij is dit niet gewenst....

p:Attributen_319 rdfs:label "Afvoeren" ;
p:attribuutsorteergroep "Functie"@NL-NL ;
p:dataLabel "Afvoeren"@NL-NL ;
p:guid urn:uuid:5D80D795-C1AA-4BC2-953E-7BCE768446B3 ;
rdfs:domain otl:Objecttypes_402,
otl:Objecttypes_403,
otl:Objecttypes_433,
otl:Objecttypes_499 ;
rdfs:range p:Attributen_319Type,
xsd:boolean ;
rdfs:subPropertyOf owl:topDataProperty ;
skos:definition "Aanduiding of het groenafval afgevoerd moet worden."@NL-NL ;
skos:prefLabel "Afvoeren" .

Suggestie- en vastewaardelijsten worden verschillend behandeld

Suggestielijsten worden niet meegenomen.
Vastewaardelijsten worden wel meegenomen en leidend gemaakt voor de mogelijke waardes van een attribuut.
De kolom Referentietabel uit de tabel X_Attributen bepaalt of een attribuut een vastewaardelijst heeft (true) of een suggestielijst (false) omvat.

Issue #39 beschrijft hoe attribuutsoort (Vaste lijst/suggestielijst) niet gelijk lopen met referentietabelsoort (Vast/suggestie).

INF18 in de data

groep:INF18 zit nu in de data (Informatiemodel 18 in Access = IMBOR). Dit zijn een flink aantal triples die nu eigenlijk geen waarde hebben. groep:INF18 wordt namelijk nergens gebruikt.

Dus wat mij betreft twee resoluties:

1. Eruit
2. rdfs:label, skos:prefLabel en skos:definiton meegeven

Geometriebeperkingen verwijzen ook naar niet-bestaande objecten

via Luuk Wijnholts

Eigenschappen IMBOR worden owl:topDataProperty. Tenzij een waardelijst, dan owl:topObjectProperty

Alle eigenschappen uit de IMBOR worden owl:topDataProperty, tenzij ze verwijzen naar een waardelijst. Dan worden het owl:topObjectProperty.

We gebruiken geen owl:topAnnotationProperty omdat hierover geen reasoning gedaan kan worden.

Taxonomie wordt op basis van single inherentence

De afgesproken hiërarchie resulteert in de rdfs:subClassOf structuur:

• bs:PhysicalObject
• Beheerobject
• Objecttype groep
• Objecttype
• Type
• TypePlus
• TypePlus2
• TypePlus3

We kiezen dus voor single inheretence (t.o.v. multiple inheretence) omdat deze taxonomie ook voor eindgebruikers bij de provincies werkbaar moet zijn en de usecase vooralsnog alleen "het managen van eigenschappen" is.

Gedetailleerde IMBOR types worden Classes

De records uit [REF_Type/TypePlus/TypePlus2/TypePlus3] worden allemaal Classes, hiërarchisch gezien rdfs:subClassOf van de records uit [X_Objecttypes], d.m.v. de bestaande PK <> FK link in Access. Daar waar mogelijk voegen we bestaande definities toe.

Omdat uit gesprekken met de provincies is gehaald dat bij sommige provincies deze typen geinstantieerd worden (om er specifieke attributen aan te hangen). Kiezen we ervoor om deze als Classes te modelleren, i.p.v. de attribuut waarden die ze nu zijn in Access. Dit worden voorlopige Classes zonder dat er direct attributen aanhangen (uiteraard wel via overerving). Dit kan resulteren in Classes zonder definities.

IMBOR hierarchie wordt skos:collection

Om een filter te kunnen maken per 'type' IMBOR object (gezien van de IMBOR hierarchie) maken we deze skos:collection. Dit worden dan:

• ObjectTypeGroep
• ObjectType
• Type
• TypeGedetailleerd
• TypeExtraGedetailleerd
• TypeExtraExtraGedetailleerd

We maken er skos:collection van omdat deze skos:member hebben. De relatie skos:inScheme heeft last van overerving dus kunnen we niet gebruiken. De relatie loopt zodoende van de collectie naar de class (IMBOR type). Er is geen waarde meer voor de relaties tussen de collectie, want we maken Beheerobject een superklasse en we 'objectificeren' ObjectTypeGroepen. De collectie relatie is zodoende alleen maar om aan te geven welk type het was.

Attribuutsoort en Tabelsoort gaan niet altijd gelijk op

Vanuit de tabel X_Attribuutsoorten worden er o.a. "Vaste lijst" en "Suggestielijst" onderscheiden.
Vanuit de tabel X_Tabelsoort (via X_Attributen.referentietabel.tabelsoort) worden REF_ en REFS_ tabellen onderscheiden.

REFS_ is een suggestielijst, REF_ een vaste lijst.

De waardes voor individuele attributen komen echter niet overeen tussen beide lijsten.

#	attr	attribuutSoort	attribuut	tabel	attrSoort	ts	tabelsoort
1	135	1	Bereikbaarheid gedetailleerd	181	Vaste lijst	3	REFS_
2	1241	1	Regelprogramma	627	Vaste lijst	3	REFS_
3	1201	1	Type voorschakelapparaat	609	Vaste lijst	3	REFS_
4	1266	1	Netbeheerder	634	Vaste lijst	3	REFS_
5	1198	1	Brandregime	606	Vaste lijst	3	REFS_
6	207	1	Beschermingsstatus gedetailleerd	144	Vaste lijst	3	REFS_
7	1200	1	Optiek	608	Vaste lijst	3	REFS_
8	1207	1	Remplacegroep	613	Vaste lijst	3	REFS_
9	910	1	Attribuut	150	Vaste lijst	7	X_
10	911	1	Domeinwaarde	459	Vaste lijst	7	X_
11	912	1	Objecttype	163	Vaste lijst	7	X_
12	376	4	Soort plantenbak	294	Suggestielijst	2	REF_
13	1257	4	Type reiniging	361	Suggestielijst	2	REF_

Select *

WHERE {
    GRAPH graph:X_Attributen {
        ?attr imborp:attribuutSoort ?attribuutSoort ; rdfs:label ?attribuut; imborp:referentietabel ?tabel .
    }

    GRAPH graph:X_Attribuutsoorten {
        ?attribuutSoort rdfs:label ?attrSoort ;
    }
    
    GRAPH graph:X_Tabellen {
        ?tabel imborp:tabelsoort ?ts ;
    }
    
	GRAPH graph:X_Tabelsoort {
        ?ts rdfs:label ?tabelsoort ;
              }
}

URI Strategie en Waardelijsten

In de wiki staat een duidelijke uri-strategie beschreven met /def/objecttype en def/prop voor objecttypes en attributen. Ik zou een /def/waardelijst (of cv voor ControlledVocabulary) willen voorstellen voor waardelijsten/domeinen.

Gebruikerswens samenhang IMBOR en IMGeo

Partijen willen een combinatie van IMGeo en IMBOR gebruiken in hun OTL, en ook om uit te vragen aan de markt. De bestaande mapping in Access is daar gelaten, deze is geschikt voor het berichtenverkeer van de BGT, maar niet voor een zuivere vertaling in linked data waarmee automatisering kan plaatsvinden. De wens is een mapping te hebben in IMBOR-linked data

Domeinwaardes (vastewaardelijsten) kunnen in een hiërarchie staan

Sommige IMBOR Domeinwaardes hebben een BovenliggendeDomeinwaarde. Dit staat in X_AttributenDomeinwaarden.

AttribuutID	Domeinwaarde	BovenliggendeDomeinwaarde	Definitie
Gebruiksfunctie	Fauna weren	Afscherming	Wild weren, fauna/wild keren
Gebruiksfunctie	Anti-parkeer	Algemeen	Tegengaan van parkeren
Gebruiksfunctie	Verbetering koeling	Milieu en klimaat	Beschaduwing, koeling
Gebruiksfunctie	Begrazingsgebied	Natuurwaarde	Rust- en/of verblijfplaats voor grazers en andere diersoorten. Soms ‘begrazingsgebied’ genoemd. Valt hieronder wanneer het gebied bedoeld is om de grazers voedsel, drinkwater, beschutting en soortgenoten te bieden.

Het is niet helemaal duidelijk hoe dit conform NTA 8035 gemodelleerd moet worden.

Verhoudt zich tot #22.

IMGEO informatie wordt uit de transformatie gelaten

IMGEO records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in IMGEO

IMGEO is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden

Aanpassen copyright en andere verwijzingen naar W3C in ReSpec

Shapes voor objecten en eigenschappen die niet in IMBOR zitten

Bijvoorbeeld shape:OBB788Shape.

via Luuk Wijnholts

Domeinwaardes met secundaire eigenschappen

Sommige eigenschappen hebben eigenschappen naast rdfs:label en skos:description.
Die eigenschappen staan niet in X_Attributen, X_AttributenDomeinwaarden, maar in individuele tabellen genaamd REF_ of REFS_.

Hoewel de meeste domeinwaardes geen secundaire eigenschappen hebben, hebben 86 tabellen meerdere eigenschappen.
Er moet worden bepaald of deze eigenschappen ook meegenomen moeten worden in OTL BIM Pro.

`REFS?_(.+)\n\t\1ID.+\n\t\1.+\n\tDefinitie\t\(.+\)\n\n`

KOR-IMBOR informatie wordt uit de transformatie gelaten

KOR-IMBOR records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in KOR-IMBOR.

KOR-IMBOR is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden

IMBOR Vakdisciplines worden skos:collection

Voor Vakdisciplines gebruiken we dezelfde constructie als bij #17. Dus skos:collection, met skos:member

Zodoende kunnen we aangeven op basis van [X_Publicatiegroepen], welke objecttypes in welke groepen horen en dat presenteren waar nodig.

Voor Objecten gebruiken we NTA, voor eigenschappen OWL (nee: SHACL)

We gebruiken de NTA om bij objecten semantiek toe te voegen (physical object), maar het hele eigenschappen verhaal wordt al door OWL geregeld dus daar gebruiken we de NTA verder niet voor.

Vandaar dat de 'gewone' constructies gebruik worden als: rdsf:range, rdfs:domain, owl:topObjectProperty en owl:topDataProperty.

[X_Objecttype] wordt [X_Objecttypegroep] op basis van "HoofdobjecttypeID"

In de tabel X_Objecttypegroepen staat de kolom, "HoofdobjecttypeID". Waar dit van toepassing is, wordt de groep vervangen door de corresponderende record uit 'X_Objecttype'.

Zodoende hoeven we niet de single name aan te passen. De record 'Informatiemodel' wordt verder wel opgenomen als klasse. Want de onderliggende klassen (die niet samenvallen met een objecttypegroep nemen we gewoon op. 'Hulpobjecten' blijft ook over (die we dan wel gewoon als Class aanmaken)

[X_Informatiemodellen] wordt niet apart behandeld.

Voor de verdere informatiemodellen uit [X_Informatiemodellen] maken we nog geen onderscheidt. Deze worden zodoende 'automatisch' meegetransformeerd.

De rest van de informatie die opgenomen is im IMBOR behandelen we hetzelfde als alle IMBOR informatie. We beschouwen het nu als 'onderdeel' van de IMBOR en zodoende wordt alle informatie op dezelfde manier getransformeerd. Eventuele uitzonderingen hier op moeten nog worden vastgesteld.

Interpretatie van IMBOR eenheden naar CDT/UMUC/QUDT

Zolang de NTA niet is vastgesteld, maken we gebruik van owl:DataTypeProperty en sh:datatype voor de eigenschappen waarbij een nta8035:unit is bepaald.

Dit zouden volgens de laatste versie NTA 8035 bij schrijven moeten zijn: owl:ObjectPropertys met een rdfs:range naar nta8035:QuantityValue.

De NTA zegt dat de range van dataproperties een xsd:string is, tenzij er een eenheid is aangegeven. Dit is in IMBOR zo. Die eenheden interpreteren wij naar de CDT/UMUC ontologie. Hiervoor maken we een interpretatie van de tabel [X_Eenheden], deze wordt apart verstrekt.

Objecttype “Beheerobject” wordt supertype van alle records uit [X_Objecttypegroepen]

Omdat we voorzien dat het gebruik van de ontologie vooralsnog alleen maar is voor :

1. het spreken van dezelfde taal
2. het aangeven van eigenschappen per type object
   ...en daarnaast omdat het perspectief van IMBOR tot nu toe alleen maar "Beheer" is, is het simpel om Beheerobject te promoveren tot superklasse. Hierdoor worden alle eigenschappen automatisch overgeërfd naar alle onderliggende typen.
   Dit is wellicht niet geheel semantisch correct en zorgt ervoor dat we alles moeten classificeren als rdfs:subClassOf bs:PhysicalObject, maar deze issues zetten we op de roadmap IMBOR OTL.

Gebruikerswens decompositie kunstwerken in IMBOR of NEN 2767

In IMBOR staan de vaste gegevens die een asset manager nodig heeft voor het tactisch beheer van een kunstwerk, in aanvulling op de gegevens die in IMGeo gevraagd worden.
Bij NEN 2767 (Conditiemeting gebouwen en kunstwerken) wordt een lijst van kunstwerk- en gebouwonderdelen verstrekt, met enkele gegevens die uit een inspectie of conditiemeting kunnen komen. Deze lijst bevat een soort decompositie, en wordt in de bouwwereld vaak als zodanig gebruikt.

Als IMBOR gebruikt wordt om een objecttypebibliotheek op te stellen en areaalgegevens te kunnen modelleren, willen de opstellers daarbij graag een decompositie hebben op basis van NEN 2767 om:

1. De onderdelen van kunstwerken en hun eigenschappen te kunnen opnemen in hun objecttypebibliotheek. Dit vraagt om publicatie van de bekende onderdelen uit NEN 2767 in linked data formaat.
2. Automatisch te kunnen controleren of bij een dataset over een kunstwerk alle onderdelen geleverd zijn met bijbehorende informatie; met de vraag: zijn alle / is het juiste aantal van alle kunstwerkonderdelen meegeleverd bij de data over dit kunstwerk? Dit vraagt om publicatie van een decompositie met cardinaliteiten van de onderdelen in linked data formaat (hoeveel minimaal en maximaal van elk onderdeel aanwezig moet zijn in de data). De gegevens uit de NEN 2767 tabellen moeten daarbij wel opnieuw worden beoordeeld op volledigheid en betrouwbaarheid, omdat er nu soms foutjes en circelredeneringen in zitten, en niet per se de regels voor decomponeren zijn gevolgd die voor redeneringen voor computers nodig zijn, zoals de geheel-deel relatie. (checken of dit klopt: soms zijn alleen de onderdelen benoemd waar een inspectie op nodig is, logisch maar leidt niet tot volledigheid.

Hoe gebeurt dat nu?
Gebruikers "vertalen" elk op eigen manier de gegevens uit NEN 2767 naar een decompositie, met die onderdelen / het detailniveau die zij zelf nodig hebben. Dit zorgt voor werk bij elke asset manager, in plaats van een keer een collectieve inspanning.

Dubbele labels, veelal enkelvoud en meervoud.

Er zijn behoorlijk wat Objecttypes die dubbele labels en preflabels hebben...
Over het algemeen een enkelvoud en een meervoudsvorm.
Waarschijnlijk omdat het vanuit IMBOR zowel collecties zijn als nu in de ontologie 'supertypen'?

otl:Objecttypes_499
rdf:type rdfs:Class ;
p:dataLabel "Waterobject"@NL-NL ;
p:geometryAsPolygon true ;
p:guid urn:uuid:08C0CFA2-8234-40B4-83CA-5C216D83F677 ;
p:guid urn:uuid:81CBE022-0D94-4377-82CA-3AA12937FE8D ;
rdfs:label "Waterobject"@NL-NL ;
rdfs:label "Waterobjecten"@NL-NL ;
rdfs:subClassOf otl:Beheerobject ;
skos:definition "Kleinste functioneel onafhankelijk stukje water met gelijkblijvende, homogene eigenschappen en relaties dat er binnen het objecttype Water van NEN 3610 wordt onderscheiden en dat permanent met water bedekt is."@NL-NL ;
skos:prefLabel "Waterobject"@NL-NL ;
skos:prefLabel "Waterobjecten"@NL-NL ;
.

Shacl Shapes in het metamodel beschrijven instanties, niet de IMBOR klasses

Dit vormt een probleem als we de OTL zelf willen controleren.

Of een OTL die voortbouwt op IMBOR willen controleren.

spaties achter labels

Omdat je veel queries wil doen via binding met de labels is het extra irritant als er spaties in staan

otl:TypePlus2_2053
rdf:type rdfs:Class ;
p:guid urn:uuid:34C101EE-B6C9-46D9-A0FE-9519EE0F0968 ;
rdfs:label "BW201-RB "@NL-NL ;
rdfs:subClassOf otl:TypePlus_2543 ;
skos:definition "Fietsers rechts oversteken"@NL-NL ;
skos:prefLabel "BW201-RB "@NL-NL ;
.

SUF-BENCHMARKS informatie wordt uit de transformatie gelaten

SUF-BENCHMARKS records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in SUF-BENCHMARK.

SUF-BENCHMARKS is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden

Introductie van superklasse voor 'Domeinwaarden'

NTA schijft voor dat datatype owl:class zijn. Wij introduceren één superklasse om ze bij elkaar te houden in taxonomie. Deze klasse is 'domeinwaarde".

Zodoende kunnen we ook aangeven dat de rdfs:range van een owl:topObjectProperty in ons geval alleen deze klasse "domeinwaarde" kan zijn.