Web conference notes, 2021.07.01 (Joint Working Group)
Joint Working Group - Provider Services
- Every other week call at 9am PT / 12pm ET / 6pm CET
Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09
One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)
Dial by phone: +1 929 436 2866 (US) (Find your local number)
Note: We are now collecting attendees upon entry into the Zoom meeting. A count will be posted after the meeting.
19 Attendees
Main Topics
- Modal Specification in MDS
- Architecture of overall MDS API schema for new modes and variants.
- Potential future modes: carshare, passenger services/taxis, delivery robots, drones
- How does it affect vehicles, trips, events?
- What is the impact on the state machine? Are there new version or modifications only?
- Related to Issue #614
- Want to frame the right questions, discuss possible paths to take, and lay groundwork for mode inclusion.
- Will not be discussing specific modes, except in relation to the overall topic.
- Architecture of overall MDS API schema for new modes and variants.
WGSC Meeting Organizers
- Host: Michael Schnuerle
- Facilitator: Angela Giacchetti
- Outreach: Michael Schnuerle
- Note taker: Marie Maxham
Action Items
- Comment in this discussion area about this whole mode topic.
- Turn thoughts into a 3-5 page google doc for sharing and feedback from whole community
- Followup WG meeting to review
- OMF Staff help draft initial mode structure in MDS in an objective way for review by working group
WGSCs
- Board voted in 5 new steering group members 2d ago, 7 per WG, 14 members total
- Discussion about merging WGs but in practice the distinction has blurred; proposal to formally merge. August at earliest, needs board vote. Might go to bi-weekly meetings.
Modes Review
- Currently modes are not specified, are different from vehicles
- Tracked aspects of modes (carshare, taxi, delivery robots) are likely different
- How do we restructure MDS? How much mode-specificity will we need?
- Does it change the definitions of trips and so on?
- #614 was specific to Policy, but likely will have impacts in provider/agency
Need a framework that guides people implementing experiments that might include new/different state machines, or vehicle attributes, etc. Hopefully then new introduced modes will conform to how we think about all modes, not just a particular mode. Don't want to prematurely optimize for e.g. carshare.
Considerations
- Ideally mode work doesn't impact other modes, or as little as possible
- Taxi for example is very different. Multiple simultaneous logical trips are possible.
- From a public policy perspective, keeping modes distinct is very important, for multiple reasons including jurisdictions (e.g. taxi in LA is county, micro is city).
- Conflating modes makes for a very confusing mega-state-machine
- Even very similar modes (taxi, TNC) you have different information, resulting in a lot of "in this case, do A, in this case do B" and the complexity makes it difficult to represent.
- Jurisdiction vary per mode and definitions could be different, eg in LA
Legibility to an implementor vs. legibility (who may need only a single mode) vs legibility for cross-modal data, being able to compare apples to apples in modes. Trips should be as comparable as possible. "Segments" should be comparable. Goal would be to improve cross-modal analysis. Is a unified state machine needed? Or can we "just" have a design goal to enable cross-modal analysis?
Model Options
- Is there a "core" vs. "extension" model?
- How do we make sure that we don't blur the semantics of words in different contexts?
- Agreement in general on concept of base state machine that has modifications per mode
Taxi Example
- Taxi is radically different, with driver and multiple passengers, passenger/party, shared taxis
- To be clear we are not talking about getting any driver or passenger information, just about how trips, events and states of vehicles are defined.
- Trip structure is very different, travel to, delivery, dwell, travel back,
- Trip segments are different than others
- Neil whiteboarded why segments don’t work, gets complicated quickly. Could work but need to be wary of infinite parent/child relationships.
- Current LADOT mds-core implementation of taxi+micro is pretty clean in a way that a single-state-machine was not. We implemented each and abandoned single-state-machine. That's city-side, not provider side.
- So far mode work for Taxi has been mostly a few additional fields, and trips are similar to micro, but attached to passenger/passenger-groups.
- Single-passenger vs multi-passenger requires changes, but once you have multi, trips/segments look similar.
Questions
- You might have diverse state-machines but you'd keep the semantics of the states and events across state-machines.
- Do trips need a trip hierarchy? Linkages, parent-child, segments? The rules would need to be strict. Multiple models have been proposed in the analytics literature.
- Can we introduce new modes in a non-breaking way? Modality is optional, and defaults to micro. LADOT mds-core added taxi in a non-breaking fashion.
- We can add modality without actually adding a second (official, blessed) mode.
- Can we add another mode and still be truly non-breaking? Probably?
Final Thoughts
- Start with discussion, but turn into white paper, challenges to existing users, walk through proposed strategy. Turn into 3-5 page google doc, solicit feedback from whole community and comments in this doc.
- We should create a white-paper with the thinking about modality where we can put down all the arguments e.g. "legibility for whom". Propose strategies to move forward.
- Want to be careful about not architecting ourselves into a corner with one mode, or making mode changes 'non breaking' when they should wait and be 'breaking' in a release.
- The current 1.2.0 release could be a major release, eg, 2.0.0, if this mode structure needs to be breaking, the proposals are ready, and there is some urgency.
New Attendees
N/A
