Na klikken op de link Verken het vocabularium in https://data.vlaanderen.be/ns/mobiliteit/trips-en-aanbod is het ttl bestand niet vindbaar op https://data.vlaanderen.be/ns/mobiliteit/trips-en-aanbod.ttl .

Deze mss ook nog toevoegen aan de referentielijst?

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst transportgebiedtype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

(1)
De baseuri voor het vocabularium dat we hier definiëren wordt op dit ogenblik verondersteld te zijn:
https://data.vlaanderen.be/ns/mobiliteit#. Zie ook #1 .
Dit kan niet, want deze uri is al bezet (volg hem maar eens).
Voorstel: wijzigen naar
https://data.vlaanderen.be/ns/deelmobiliteit#.
(2)
Om verwarring te vermijden zou ik voorstellen om meteen ook de naam van deze repository te veranderen in OSLOthema-deelmobiliteit. Iedereen zou wel zijn links moeten aanpassen, maar liever korte pijn dan lang lijden...

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst vervoersbewijstype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

URI achter de codelijsten geeft een error weer.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
Momenteel beperkt uitgewerkt.

Omschrijving van een mogelijke oplossing:
Kijken naar bestaande beschrijvingen, bv https://support.google.com/transitpartners/answer/6377425 of http://wiki.goodrelations-vocabulary.org/Cookbook/Pricing.

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
In het huidige model mis ik het concept “Aan te schaffen vervoersrechten”. Dan zijn de vervoerstitels die nodig zijn om de geplande reis te kunnen maken. In de toekomst worden dit waarschijnlijk elektronische vervoersbewijzen of zelfs combi-ticketten.

Langs de ontwikkelaarszijde is dit concept ook nodig. Voor elke mogelijke Route zal aan de Reiziger (rekening houdend met zijn Kenmerk van het type huidige abonnementen) de lijst aangeboden worden van de vervoersrechten die nog moeten aangeschaft worden om voor elk Routesegment een vervoersrecht te hebben. Met de prijs per aan te schaffen recht, kan de reiziger een Route kiezen, niet enkel gebaseerd op duurtijd maar ook op prijs. Mogelijk toont de aanbieder per mogelijke Route meerdere mogelijkheden van aan te schaffen vervoersrechten. Zo kan je voor een treintrip naar de kust een ticket kopen of een Rail Pass. En misschien kan de gebruiker enkele van de aan te schaffen vervoersrechten uitvinken omdat hij bijvoorbeeld nog ergens een Rail Pass liggen heeft. In elk geval, de reiziger kan uit de mogelijke routes, met kennis van tijdsduur en totale kostprijs (rekening houdend met zijn actieve abonnementen) zijn gekozenRoute met de voorgestelde aan te schaffen vervoersrechten selecteren, misschien nog enkele voorgestelde vervoersrechten uitvinken en daarna de resterende vervoersrechten aanschaffen.

Omschrijving van een mogelijke oplossing:
Omdat deze aan te schaffen vervoersrechten voor de aanbieder in een 1 to many relatie aan de mogelijkeRoutes hangt, zou ik de uiteindelijke aangeschafte vervoersrechten ook aan de Route (de gekozenRoute) en niet aan de Reis hangen. Er kan nog nagedacht worden of er een concept “aan te schaffen vervoersrechten” en een andere concept “aangeschafte vervoersrechten” nodig is of deze samen kunnen genomen worden. De structuur is waarschijnlijk identiek.

Peter Peeters
MOW, analist Mobilidata

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
Huidige lijst met Reizigerskenmerken verwijst naar https://www.crow.nl/publicaties/woordenboek-reizigerskenmerken maar deze lijst is beperkt tot kenmerken van mindervaliden.

Omschrijving van een mogelijke oplossing:
Alternatieve lijst zoeken of opstellen.

Naar aanleiding van de workgroup 23/10 voorstel tot testcase om te kijken of het model blijft rechtop staan:
Stad X heeft een opgenomen in hun licentievoorwaarden dat het gemiddelde gebruik van voertuigen 0.5/dag moet zijn. Mobiliteitsaanbieders moeten data toeleveren om aan te tonen dat ze aan deze voorwaarde voldoen.

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst gebruikerstype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Ik vond dit artikel via de mensen van TOMP over de overlap in standaarden in multimodale systemen
https://publications.jrc.ec.europa.eu/repository/handle/JRC118744
Zeker te bekijkeb

Een aantal attributen zouden optioneel gemaakt kunnen worden om zo weinig mogelijk duplicatie van dezelfde informatie te hebben. Dit naar aanleiding van een specificatie die ik aan het opstellen ben:
https://github.com/brechtvdv/third-party-support-maas-specification/tree/master/provider

• [ ] Reis:reisweg. Bij gebruik van routesegmenten is dit overbodig.
• Route: vertrek- en aankomstpunt. Kan afgeleid worden uit de gesorteerde lijst van routesegmenten.
• Route:reisduur. Kan afgeleid worden uit Route:vertrek- en aankomsttijdstip.
• Link:aankomst- en vertrekknoop. Kan afgeleid worden uit Link:geometriemiddenlijn + GerichteLink:richting.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
Waar past deze in het model? Wat is de definitie? Verschil met vervoersautoriteit (zie definitie https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R1926)?

Omschrijving van een mogelijke oplossing:
Momenteel geen.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/ns/mobiliteit/trips-en-aanbod

Omschrijving van het probleem:
Veel voorkomende attributen zoals naam, identificator, type etc zijn nu niet gemapt op externe uri's. Ze kregen een eigen uri, waarbij deze zelfs gedisambigueerd moest worden, bv Mobiliteitsdienst.type en Resource.type.

Omschrijving van een mogelijke oplossing:
Voor bv type mappen naar http://purl.org/dc/terms/type dat domeinloos is. Voordeel: veel minder door OSLO gedefinieerde termen.

(zie TC1)
Een gebruiker wil het traject van Zwemdoklei, Brasschaat naar Den Bell, Antwerpen afleggen. (ref: https://www.slimnaarantwerpen.be/nl/routeplanner?departureType=LEAVE_NOW&departureCoordinates=51.2962833%2C4.4496752&destinationCoordinates=51.20509677381817%2C4.398732438664224)

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst transportknooptype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
Huidige lijst met Aandrijftypes verwijst naar https://github.com/openmobilityfoundation/mobility-data-specification/tree/dev/agency#propulsion-type maar deze lijst is beperkt, bv hybrid of soort verbrandingsmotor (diesel, waterstof) ontbreekt. Kan probleem zijn voor rapportage van bv aandeel milieuvriendelijke ritten.

Omschrijving van een mogelijke oplossing:

Alternatieve lijst zoeken of opstellen.

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst transporttype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
De term Resource is mogelijk verwarrend. Suggereert dat het gaat over een Resource zoals bedoeld in RDF.

Omschrijving van een mogelijke oplossing:

• Mobiliteitsresource
• Ding
• Asset
• Middel
• Bedrijfsmiddel

In Transmodel lijkt een model aanwezig om Trips te modelleren, zie link.

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst routetype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Onderstaande use-case na te kijken hoe deze in het model past:

Als MaaS-service provider wil ik gegevens kunnen krijgen van mobiliteitsaanbieders over een bepaalde eindgebruiker en zijn ‘contracten’ met de mobiliteitsaanbieder zodat ik weet welk soort trips ik kan aanbieden (bvb. consumptielimieten, geabonneerde zones,…) en wat de prijs voor de eindgebruiker zal zijn (abo-formule, lopende tickets,..)

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst connectietype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
Is de Uitvoerder steeds een GeregistreerdeOrganisatie? Wat bv met Mobiliteitsdiensten als UBER die privépersonen als Uitvoerder inzetten.

Omschrijving van een mogelijke oplossing:
Agent ipv GeregistreerdeOrganisatie maken van Uitvoerder.

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst reizigersvoorkeur is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Link waar het probleem zich voor doet:
https://otl-test.data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/ontwerpstandaard/20191216

Omschrijving van het probleem:
VOC INSPIRE:Transportnetwerk ontbreekt. Voorlopig domein fixme gebruikt, bv http://fixme.com/#Netwerkelement.identificator.

Omschrijving van een mogelijke oplossing:
Zelf VOC Transportnetwerk maken?

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst dienstverleningtype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst resourcetype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Micromobility heeft een voorstel tot nieuwe voertuigcategorie actie die volgens mij wel zinvol kan zijn. Mss interessant om te bekijken.

Hierbij nog bijkomende definities en taxonomie termen die mogelijk interessant zijn voor OSLO
https://www.sae.org/shared-mobility/
https://www.sae.org/standards/content/j3163_201809/preview/

What will be the landing page for our specification? https://data.vlaanderen.be/ns/mobiliteit?

Model(len) waarop de issue van toepassing is:
OSLO Mobiliteit: Trips en Aanbod

Omschrijving van het probleem:
De codelijst aandrijftype is onvolledig.

Omschrijving van een mogelijke oplossing:
Suggesties, toevoegingen en nuttige bronnen mogen in deze thread gedeeld worden.

Huidige tekst:

Hieronder verstaan we zowel klassieke mobiliteitsdiensten zoals openbaar vervoer (typisch aangeboden als lijndienst, bv metrolijn 5 in Brussel), maar ook deelvervoer zoals free floating deelsteps (bv deelsteps in grote steden).

Voorgestelde tekst

Hieronder verstaan we zowel klassieke mobiliteitsdiensten zoals openbaar vervoer, maar ook deelmobiliteit en MaaS-aanbieders.

Dit was denk ik één van de langere discussies. Anders hebben we nergens waar we MaaS kunnen capteren...