GML.Next: hoe vereenvoudig je een informatiemodel voor lichtere toepassingen?

Standaarden
#1

We zijn op zoek naar ervaringen met het “platslaan” van informatiemodellen. Zou je de wijze van platslaan kunnen ‘standaardiseren’? We zijn op zoek naar best practices, ideeën en opmerkingen hierover! Wat kan Geonovum doen om te zorgen dat informatiemodellen eenvoudiger worden, en wat kan Geonovum doen om te zorgen dat informatiemodellen op uniforme wijze vereenvoudigd worden, als de formele toepassingen verdere vereenvoudiging niet toestaan?

Dit topic starten we n.a.v. de 1e sessie van GML.Next op 17 juli, lees hier het verslag!

3 likes
GML.Next: Doe mee met de Geonovumverkenning naar GML-alternatieven op 17 juli
#2

Voor het Informatiemodel Digitale Bereikbaarheidskaart, IMDBK, zijn (in 2010!) twee modellen gemaakt. Eén genaamd dataspecificatie en de ander toepassingsmodel (conform Simple Features Profile 0). De eerste heeft complex features en meervoudige attributen. De SFO versie is helemaal plat.

De platte versie is te vinden op https://www.geonovum.nl/geo-standaarden/informatiemodellen-nen3610-familie/informatiemodel-berichtenverkeer-digitale

1 like
#3

Wat je in feite nodig hebt is een view op basis van een query met meerdere joins op een relationeel datamodel, de implementatie is erg eenvoudig; maak een view in de database, ontsluit de view als een wfs featuretype. De uitdaging zit aan de functionele zijde, welke attributen en identifiers neem je op in de view en hoe sla je de view definitie op zodat deze overdraagbeer is. In linked data (waar in nog hogere mate sprake is van ‘complex features’) dient een sparql query een vergelijkbaar doel.

Views worden over het algemeen gemaakt met een specifiek gebruiksdoel voor ogen. De hier-en-daar gebruikte term informatieproduct lijkt daarom relevant. Vanuit de metadata hoek kijk hiertegenaan als: zorg dat de data as-is beschikbaar is als parent-dataset en registreer iedere view op de data als een eigen child record, waarbij je met de parent-child relatie linked aan de parent. In de metadata kun je dan beschrijven met welk doel de view gemaakt is.

#4

Ik schreef laatst een blogje over basisregistraties, datamodellen en interoperabiliteit: https://www.md-kwadraat.nl/standaarden/2018/11/13/datamodellen.html

De inhoud daarvan wil ik hier in de (wat doodgebloede) discussie inbrengen. Ik hoop dat dit in mijn ogen belangwekkende topic weer meer aandacht krijgt.

1 like
#5

Zou het niet beter zijn om bij het modelleren al te bedenken hoe de data het best in een kaartlaag-georienteerd GIS getoond kan worden? En dan de modellering daar een (beetje) op aan te passen? En exotische, moeilijk in te lezen, constructies te laten voor wat ze zijn.

Interessante passage.

Ik lees hierin een oproep om gebruikers van standaarden te betrekken bij het bedenken van dezelfde standaarden. Dit is volgens mij precies wat het SDI.Next initiatief probeert te doen (gezien o.a. de topics in het forum). Hulde!

@marco_duiker denk je dat zo’n aanpak voor de nodige veranderingen gaan zorgen?

Verder ben ik benieuwd naar de ervaringen van het SDI.Next initiatiefnemers (@FrisoPenninga?) met deze aanpak tot dusver. Valt de participatie mee/tegen? Op welke andere manieren wordt er geprobeerd om gebruikers te betrekken?

#6

denk je dat zo’n aanpak voor de nodige veranderingen gaan zorgen?

Tja, als het goed is wel natuurlijk.

In mijn ervaring gaat het maken van standaarden over het afwegen van belangen. De bekendste hierin is natuurlijk de afweging tussen flexibiliteit en stabiliteit. Flexibiliteit om tegemoet te kunnen komen aan veranderende wensen in een veranderde wereld, stabiliteit om ervoor te zorgen dat dingen bruikbaar blijven zonder steeds spullen aan te moeten passen.

Zo dient er naar mijn mening dus ook een belangenafweging te komen tussen “ideaal” vanuit het oogpunt van de makers van de datasets en “ideaal” vanuit het oogpunt van de gebruikers van de datasets.

Voorzover ik nu kan overzien is die afweging nu een ondergeschoven kindje. Het beter betrekken van de gebruikers bij het ontwerpen van de TECHNISCHE implementatie van de standaard zou daarbij helpen.

In voorgaande passage schreef ik technische met hoofdletters. Dit om het te onderscheiden van de meer inhoudelijke modellering van de dataset waarbij naar mijn opinie iha de gebruikers van de datasets wel voldoende zijn betrokken.

1 like
#7

Helder, dank voor de uiteenzetting!

Hoe zou dit het beste kunnen? Of anders gevraagd: in welke vorm (bijeenkomsten, online discussie, etc.) en onder welk omstandigheden/voorwaarden zou jij willen bijdragen?

#8

hmm, in mijn ervaring gaan een stel slimme jongens (meisjes heb ik daarbij nog niet gezien), gepokt en gemazeld in xsd, aan de slag met het materiaal dat de meer inhoudelijk georiënteerde standaardenmakers hebben bedacht. Resultaat: “de mooist mogelijke implementatie van het inhoudelijk gedachtengoed in xsd”.

Het zou enorm helpen als er dan gelijk INHOUDELIJK ZINNIGE voorbeelddatasets worden gemaakt die ter review worden voorgelegd aan een gebruikerspanel. Het gebruikerspanel zou dan moeten proberen met de data aan de slag te gaan.

Maar … dat zou betekenen dat de data direct inleesbaar zou moeten zijn. De heilige graal …

Daarom denk ik dat de gebruikers in het panel terzijde gestaan moeten worden door ontwikkelaars die dan feedback geven op het gemak waarmee de dataset ZONDER DATAVERLIES in een GIS of ander van toepassing zijnde stuk software kan worden ingelezen. De gebruikers geven dan feedback over het resultaat. Is de data die nodig is in zijn/ haar werkproces voldoende makkelijk toegankelijk/ analyseerbaar/ bewerkbaar.

Al met al een kostbaar proces, dat ook nog eens meerdere malen moet plaatsvinden tijdens de ontwikkeling van een complexe standaard (denk omgevinsgwet).

Maar … het zou zomaar kunnen dat deze kosten dan later weer terugkomen als maatschappelijke baten. Oftewel, dat het BV-Nederland onder de streep geld oplevert.

Andere (goede) ideeën welkom …

Enneh, vooralsnog ben ik bereid overal aan bij te dragen, zolang het maar tot verbetering leidt.

1 like
#9

Ik heb wel een heel aantal xsd’s gemaakt hoor, de meeste voordat ik ‘adviseur’ werd. Maar ook het GML application schema (xsd) van IMGeo.

Volgens mij is het een heel goed én werkbaar idee om tijdens het ontwikkelen van een informatiemodel en daaruit afgeleide xsd, meteen een goede voorbeelddataset te maken en daarmee te proberen te werken. Je kan een informatiemodel ook per onderdeel ontwikkelen in plaats van als één groot monolithisch ding waar je maanden mee bezig bent. Dit doen we nu binnen het BRO standaardisatieteam in sprints van 4 weken… Het is nog wel een beetje zoeken daar maar het gaat.

1 like
#10

Beste Linda,

Fijn te horen dat er ook vrouwen bij het proces betrokken zijn. Daar wordt de wereld beter van!

Ook fijn te horen dat je het werkbaar vindt om tijdens het ontwikkelproces voorbeelddatasets te maken en daarmee te werken.

Indien ik iets bij kan dragen door eens zo’n voorbeelddataset te gebruiken, dan hoor ik dat graag.

Groet, MArco

#11

Ik sluit mij ook aan bij de reactie van @marco_duiker. We zien bij PDOK wel eens dat modellen dermate complex zijn dat het moeilijk is om hier in bijvoorbeeld een WFS nog iets van te maken. Het eerder in het proces nadenken over “light” varianten voor dit soort koppelvlakken zou hierbij m.i. helpen :+1:

1 like
#12

Beste Jeroen,

Dank voor de steun. Wel vind ik het jammer dat je de nadruk legt op “light”. Ik denk juist dat het belangrijk en mogelijk is om te streven naar het makkelijk gebruik van de volledige dataset. Een ‘light’ variant met maar een deel van de data vind ik meer een terugval optie als het makkelijk bruikbaar maken niet goed gelukt is.

Groet, MArco

1 like
#13

@marco_duiker eens! Bedoelde ook niet per sé een uitgeklede versie maar meer een versie die eenvoudiger te gebruiken en te implementeren is waarbij dus andere keuzes gemaakt moeten worden (eerder in het proces zoals jij ook aangeeft). Light is inderdaad niet zo’n handige woordkeuze :slight_smile:

1 like
#14

Ik vraag me af of het mogelijk is een model simpeler te maken zonder data verlies. Ik ben benieuwd hoe mensen dit voor zich zien. Wel is het overduidelijk dat je voor de meeste cases toe kunt met een beperkt model. Als je slechts adres-puntjes op een kaartje wilt zien, heb je geen behoefte aan de volledige BAG. Een afgeleide ingeperkte BAG ter beschikking stellen (voor gebruik in qgis/arcgis/openlayers) is dan ook een goed idee, als daarnaast het origineel wel beschikbaar is voor specialisten die meer willen (oa specialistische applicaties).

Een belangrijke aandachtspunt in deze discussie is de tooling. Het zou voor eindgebruikers veel eenvoudiger moeten zijn om door data op basis van appschema of owl heen te browsen. En op een visuele wijze subsets uit een dataset te selecteren (zonder kennis van SPARQL/XSD). Met GML-AS is een poging gedaan dit binnen de QGIS/GDAL omgeving te realiseren. Deze tool heeft echter een behoorlijke technische insteek. Mogelijk kunnen we voor appschema xml ook een tool als GitHub - architolk/Linked-Data-Theatre: The Linked Data Theatre is a platform for an optimal presentation of Linked Data ontwerpen.

#15

In veel gevallen wel denk ik. Neem nu de manier waarop het openbareruimtelabel in de BGT is gemodelleerd. 100% zekerheid dat het in geen enkel gangbaar gis-pakket direct is in te lezen.

Door gewoon wat meer redundancy te gebruiken zou dezelfde data direct inleesbaar en bruikbaar zijn in de gangbare gis-pakketten.

Het model is dan simpeler zonder dataverlies.

#16

Ha ha, ik ging er helemaal vanuit dat je door versimpeling informatie kwijt raakt, maar inderdaad, versimpeling leidt vaak juist tot verdubbeling van data (model plat slaan). Ten behoeve van visualisatie als kaartlaag te verdedigen, maar ik blijf bij mijn punt dat het de data zelf niet ten goede komt.

1 like
#17

Ten behoeve van visualisatie als kaartlaag te verdedigen, maar ik blijf bij mijn punt dat het de data zelf niet ten goede komt.

Tja, tegenwoordig is een datamodel vaak meer een doel dan een middel. Mijns inziens zou de wijze van gebruik van de data (mede) sturend moeten zijn voor het datamodel.

Het volledig normaliseren van databases leidt in mijn optiek vaak tot slecht bruikbare en slecht performende oplossingen (allemaal te verhelpen, maar wel tegen hoge kosten).

Ik ga ervan uit dat we hierover van mening blijven verschillen. Dat vind ik geen probleem.

1 like
#18

Hear Hear [0] (om even in Engels nieuws te blijven)

Ben het met Marco eens! Wat rekening houden met toekomstig technisch gebruik, mbt complexiteit en performance, zou ik ook best hier en daar hebben aan willen moedigen.

En desnoods wel OPSLAAN op de op dat moment hipste manier, maar dan misschien bij de uitwisseling het wat ‘werkbaarder’ ( :wink: ) maken?

[0] Hear, hear - Wikipedia

1 like
#19

Helemaal mee eens hoor, om voor de traditionele kaartlaag georiënteerde gis gebruikers een dataset ook als platte tabel aan te bieden. Echter diverse redenen om daarnaast ook de originele (of opgewerkte) appschema data te publiceren.

  • vanuit de open data principes (2. primary https://opengovdata.org) wil je de data as is ontsluiten, het zij als Oracle dump, excel of spss.
  • modellen worden vaak ingericht om tot harmonisatie tussen organisaties te komen, mogelijk vallen de modellen regelmatig complexer uit dan noodzakelijk (aangezien je de complexiteiten van beide organisaties wil omvatten). Optimalisatie prima, maar moet niet leiden tot apart opslaan omdat het model te krap is.
1 like
#20

Beste Paul, kun jij mij wat voorbeelden geven van niet-traditioneel GIS dat geo-data visualiseert op een niet-kaartlaag georiënteerde manier? Ik ken zet niet …

Groet, MArco