You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Constaterend: We voorzien dat een groot deel van de meerwaarde van het informatiemodel zit in de uitwerking van fysieke borden naar geldingsgebieden van 'ontvlechtte' verkeersmaatregelen.
Constaterend: Voor het (uitputtend) (correct) uitwerken van verkeersmaatregelen is complexe modellering nodig. Bijv. met betrekking tot geldig op bepaalde dagen, voor bepaalde voortuigtypen, voor bepaalde eigenschappen van die voertuigen, voor bepaalde handelingen en combinaties van voorgaande, met uitzonderingen erop. Dit vraagt een uitwerking conform de NEN 2660-2.
Constaterend: Datex II is het datamodel voor verkeersinformatie en bevat sinds v3.4 [TrafficRegulation], een modelmodule die expressief genoeg is om de voorgenoemde complexiteit uit te drukken.
Probleem: De v3.4 TrafficRegulation-module is herschreven t.o.v. eerdere modules en is daarom tot non-stable namespace verklaard. Wanneer het weer stable is, is mij onduidelijk. Vraag: is het te voorzien of we op Datex II's TrafficRegulation kunnen bouwen? Zo ja, dan zijn alle andere problemen minder groot. Zo nee, dan zie ik niet hoe we deze opdracht moeten uitvoeren. Voorstel aan opdrachtgever: We kopieren en gebruiken de begrippen in Datex, maar bouwen niet boven op het model. Dat betekent handmatig herstelwerk in de toekomst.
Probleem: De andere, wel stabiele modules van Datex zijn met JSON-LD [Vocabularia] wel uit te drukken in Linked Data. We moeten hun zo ver krijgen dezelfde stappen te laten zetten om ook van TrafficRegulation een JSON-LD te maken. Op zich is het technisch mogelijk om zelf van de UML, XSD of JSON-Schema van TrafficRegulation een linkeddataschema te fabriceren, en dat is ook wel waardevol werk, maar het is bijzonder tijdrovend werk dat niet hetzelfde zal zijn als het vocabulaire dat Datex kan genereren. Voorstel aan opdrachtgever: DATEX vragen (mail wordt opgesteld) om een JSON-export te leveren zodat we op hun concepten/URI's kunnen verderbouwen.
Probleem: De vocabularia heb ik ook in [TriplyDB] geladen. Er zitten nog kennelijke fouten in, zoals een voorkeursnamespaceprefix genaamd NOT_FOUND. Hoe wordt nu dit JSON-LD vocabulaire gebouwd en hoe betrouwbaar is het als er zulke kennelijke fouten in zitten? Als het antwoord 'niet zo betrouwbaar is', is het nog een hele grote bups werk om van het UML-model tot een IM te komen. Ik kan het in elk geval niet zondermeer. Voorstel aan opdrachtgever: in mail aan Datex ook deze fouten opnemen.
Voorstel: wij bouwen een alternatief/concurrerend model . Dit is dubbel werk. Je wil de complexe materie niet anders uitdrukken dan met Datex II's TrafficRegulation, maar we kúnnen het nu niet daarmee uitdrukken. In de toekomst leidt ons werk tot herstel aan de ene of de andere kant.
Als voorzitter van de CMB van DATEX II is het niet heel moeilijk om deze vragen te beantwoorden.
Versie 3.3 van DATEX II bevat de officiele CEN TS 15167 part 11.
Die wordt momenteel herzien en bevatte onvoldoende ondersteuning voor o.a. milieuzones.
Als tussenversie is versie 3.4 (en inmiddels 3.5) uitgebracht die voor part 11 als basis dient van de herziening. We weten nu al dat de nieuwe stabiele versie geen fundamentele wijzigingen, maar wel uitbreidingen van het model met zich mee zal brengen. Deze zullen landen in versie 3.6 die eind van het jaar wordt verwacht.
Het is veilig om met versie 3.5 aan de slag te gaan.
Aanvullend heb ik heb de JSON versie gedeeld via teams/sharepoint (in de NDW-input map), zodat die gebruikt kan worden. Daarnaast is de json ook te downloaden door de xsd url te gebruiken en dan de .xsd aan te passen naar .json
Wat betreft de linked-data versie van DatexII, de huidige status is twijfelachtig. Doordat er vanuit deze vraag interesse is in de LinkedData, zit ik binnenkort (9 juli) om te kijken of/hoe we hier vorm aan kunnen geven vanuit DatexII en dan vooral ook met focus op de traffic-regulations.
NOT_FOUND
. Hoe wordt nu dit JSON-LD vocabulaire gebouwd en hoe betrouwbaar is het als er zulke kennelijke fouten in zitten? Als het antwoord 'niet zo betrouwbaar is', is het nog een hele grote bups werk om van het UML-model tot een IM te komen. Ik kan het in elk geval niet zondermeer. Voorstel aan opdrachtgever: in mail aan Datex ook deze fouten opnemen.Datex model
Vocabulaire
Voorbeeld not found in Datex model
The text was updated successfully, but these errors were encountered: