Dilemma: uitwisseling alfanumerieke data over objecten opnemen als eis aan NLCS applicaties en uitwisselformaat voorschrijven?

ElisabethKloren commented 4 months ago

Ter discussie met de beheercommissie

Vanuit de wensen binnen NLCS Netbeheer, waarbij de uitwisseling van alfanumerieke data over objecten centraal staat ("NLCS ++), ontstaat een belangrijk dilemma met betrekking tot het te kiezen uitwisselformaat. Dit vraagstuk heeft directe implicaties voor softwareleveranciers, marktpartijen en de algehele interoperabiliteit tussen verschillende domeinen zoals riolering (GWSW), openbare ruimte (IMBOR ,informatiemodel Verkeersborden) en netbeheer.

Tijdens de laatste bespreking van de werkgroep netbeheer is dit onderwerp ter sprake gekomen, maar tot op heden heeft er nog geen verzoek plaatsgevonden om de huidige standaard uit te breiden met de mogelijkheid tot uitwisseling van alfanumerieke data. Het lijkt erop dat de netbeheerders binnen NLCS snel XML willen invoeren als uitwisselformaat. Ik wil de Beheercommissie vragen om te overwegen wat hier de juiste weg is.

Het gebruik van JSON (linked data) als uitwisselformaat lijkt, gezien de samenhang met informatiemodellen zoals GWSW, IMBOR en het Informatiemodel Verkeersborden, logischer en meer in lijn met moderne ontwikkelingen in de sector. Een uniforme aanpak met JSON zou niet alleen de consistentie bevorderen, maar ook de interoperabiliteit tussen verschillende projecten en domeinen vergroten. Het is in dit kader ook relevant om te vermelden dat Mijn Aansluiting al de keuze heeft gemaakt om afscheid te nemen van SOAP XML en zich te richten op REST JSON voor hun API's.

Om tot een weloverwogen beslissing te komen, stel ik voor dat we in het bredere verband van DigiGO een discussie initiëren over de voordelen en nadelen van zowel XML als JSON, rekening houdend met de behoeften van diverse domeinen en betrokken partijen, waaronder de netbeheerders die in het ontwikkelproject al gewerkt hebben met xml en hun informatieleveringsspecificatie in bijbehorend XSD formaat hebben opgesteld. De vraag is of het nadeel van hun ontwikkelingen aanpassen naar een andere techniek voor hen opweegt tegen het voordeel, dat marktpartijen zich direct kunnen gaan richten op de meer schaalbare linked data techniek JSON.

Daarnaast is de vraag aan de beheercommissie: willen we als eis aan NLCS leveranciers gaan stellen, dat zij ook kunnen omgaan met alfanumerieke data bij objecten, en daarbij specifiek (1) deze data kunnen inlezen en tonen bij objecten, (2) attribuutvelden kunnen invullen in de applicatie en (3) vervolgens deze data kunnen exporteren. Dit zou een fundamentele ontwikkeopgave zijn voor de leveranciers, waarbij een redelijke termijn voor implementatie moet worden meegegeven.

theokolman commented 4 months ago

De paren SOAP/XML en REST/JSON worden vaak in die combi gebruikt, maar dat is niet strikt met elkaar verbonden. Het lijkt me goed om onderscheid te maken tussen het berichtenprotocol en het formaat van het berichten. Als voor de inhoud van de informatie het "zwaardere" formaat van XML gewenst is, kan dit goed gecombineerd worden met het lichtere, flexibelere REST ipv gangbare SOAP/XML.

ElisabethKloren commented 4 months ago

Input van mijnaansluiting:

afweging uitwisselformaat

• GeoJSON <> JSON. Zie bijvoorbeelde stukje tekst op https://stackshare.io/stackups/geojson-vs-json Mijn vraag gaat over de afweging XML & JSON, niet XML & GeoJSON • De twee minnetjes bij (Geo)JSON zijn wat mij betreft niet correct. We stappen bij onze diensten DSP en LIP op dit moment over van XML naar JSON, en daarbij is uitgebreid onderzocht wat de mogelijkheid is om validaties toe te passen, en waardelijsten onderdeel van de specificatie te maken. Conclusie daarbij is dat dit inderdaad iets eenvoudiger is bij XML, maar prima mogelijk is met JSON.

Ik heb Glenn Stringer, onze Product Owner DSP, in de CC meegenomen. Wellicht kan hij verder aanvullen. Of benader hem gerust over het onderzoekje wat zijn team heeft uitgevoerd hierover.

• De ++ bij XML/XSD (eenvoudig voor softwaredevelopers) vind ik wat aan de hoge kant:

Wij merken dat bij implementaties van DSP en ook de Mijnaansluiting.nl-webservices (die allebei met SOAP XML werken) dat onze deelnemers het steeds lastiger vinden om goede developers aan te trekken die met XML kunnen werken. Een REST API aanspreken met JSON-berichten is echt eenvoudiger dan een SOAP XML-webservice.

ElisabethKloren commented 4 months ago

De paren SOAP/XML en REST/JSON worden vaak in die combi gebruikt, maar dat is niet strikt met elkaar verbonden. Het lijkt me goed om onderscheid te maken tussen het berichtenprotocol en het formaat van het berichten. Als voor de inhoud van de informatie het "zwaardere" formaat van XML gewenst is, kan dit goed gecombineerd worden met het lichtere, flexibelere REST ipv gangbare SOAP/XML.

Grappig; ik zou zeggen dat je met json zwaardere informatie kan leveren, omdat de geleverde data kan worden verbonden met het informatiemodel, en je flexibeler kan omgaan met de gewenste inhoud van de berichten (bijvoorbeeld de te gebruiken waardelijst per netbeheerder)

En inderdaad, we moeten onderscheid maken tussen het uitwisselformaat en het protocol; deze issue gaat wat mij betreft over het uitwisselformaat, dus XML versus JSON (en dus NIET GeoJSON)

ElisabethKloren commented 4 months ago

Even opgezogt wat het DSGO zegt over JSON:

JSON | JavaScript Object Notation (JSON) is een open standaard data format die niet afhankelijk is van een specifieke programmeertaal. Dit compacte dataformaat maakt gebruik van gemakkelijk te lezen tekst om dataobjecten uit te wisselen tussen toepassingen en voor dataopslag. In het afsprakenstelsel wordt JSON wordt voor het sturen van gegevens in de context van datadiensten. Dit geldt niet voor de inhoud van de data die wordt uitgewisseld, het DSGO is data agnostisch en ondersteund hiervoor alle mogelijke data soorten. | JSON -- | -- | --

ElisabethKloren commented 2 months ago

Mijn advies aan DSGO zou zijn, om

Te onderzoeken hoe ver men hiermee is op internationaal gebied, oa bij building smart, en welke techniek daar in gebruik is. Als er ook een techniek gangbaar is om alfanumerieke data met IFC te combineren, zou dat een reële optie zijn.
Of anders aan te sluiten op de NEN 2660-2 voor uitwisseling, en daarmee ook op de combinatie van een informatiemodel, een ils en een uitwisselformaat met linked data talen en formaten.

ElisabethKloren commented 2 months ago

Indien NLCS sneller wil gaan dan de discussie bij DSGO, in verband met de gebruikersbehoefte van de netbeheerders, zou ik adviseren om uit te gaan van linked data (een ontologie in rfd/owl, databeohefte definiëren met shacl en dan json als uitwisselformaat)

theokolman commented 2 months ago

In de voorbereiding op de discussie wellicht een boeiende vergelijking: https://medium.com/wallscope/understanding-linked-data-formats-rdf-xml-vs-turtle-vs-n-triples-eb931dbe9827

ElisabethKloren commented 2 months ago

18-04-2024: De beheercommissie vraagt de programmacommissie om hiermee aan de slag te gaan.

nl-digigo / NLCS

Dilemma: uitwisseling alfanumerieke data over objecten opnemen als eis aan NLCS applicaties en uitwisselformaat voorschrijven? #305