Skip to content

Admin Draft Review

The Admin draft of the Mobility Data Interoperability Principles was developed as part of the California Integrated Travel Project (Cal-ITP), a joint project of Caltrans, CalSTA and CCJPA to respond to common needs across transit stakeholders in California…but which aren’t unique to California.

As much as possible, we (Cal-ITP) would like these principles to reflect a shared vision for transit technology components among the industry as a whole and reduce geographic fragmentation which is often used as an excuse for lack of implementation.

As such, we hope to share authorship and ownership as much as is desired by other parties. “Saying it together” is way more powerful than “Caltrans saying something”....so if there is anything we can change in how we are approaching this so that we can all “say it together”, let us know!

Instructions

  • Add additional reviewers from your organization (or others!) in the Reviewers Table that you feel would strengthen the document through their review by adding their name to the table and commenting with their email address (Cal-ITP will invite).
  • Review the document top-to-bottom and add specific comments or suggestions in-line.
    Add overall comments next to your organization in the Reviewers Table below
  • Indicate anticipated support for the principles in the Reviewers Table(see descriptions)
  • Check off your name in the Reviewers Table

Questions? Feel free to ping the author Scott Frazier who is the product lead for the Principles as part of the Mobility Service Data stream of work for the Cal-ITP project.

THANK YOU

Admin Draft Discussion Session

Held Wednesday July 14: 3-4 ET/2-3 CT/1-2MT/12-1 PT

Agenda/Notes

  • Background
  • Status update
  • High-level questions
  • Concern: Is it possible to affect change this way?
    • Group agreed this was a necessary but not sufficient step and that we shouldn’t oversell the principals as “solving everything”. More work will be needed.
  • Concern: Why this when there are other things?
    • After discussing other related products, the group in attendance agreed that the Principles fill a needed gap.
  • Agree on final decision process:
  • No disagreement raised at the meeting for the proposed governance process which provides equal weight to all co-authors.
  • Discussion of high-level issues:
  • Right-sizing the purpose / scope [ see issue discussion ]
  • Who are the “do-ers”? [ see issue discussion ]
  • How do we make sure not just “bare minimum” is implemented
  • No other issues raised.
  • Getting to a public draft
  • Proposed process briefly referenced.
  • Cal-ITP will ask for assent from tentative co-authors.

What we heard

While the vast majority of admin review comments reinforced the value and need for this document, the following higher-level concerns raised were as follows:

Make definitions easy to access up front and in-line

Definitions are now linked throughout the document via hypertext and a similar approach employed in the Principle’s web mockup.

Make sure mobility, transit, and MaaS are appropriately included consistently throughout the document

Consistency in terminology has been addressed after admin draft editing was frozen.

Improve clarity and definitions for (intended) “open” “data standards” vs (not intended) “standards” for “open data”.

Based on a thorough discussion, reviewers reached consensus at “open standard”.

Tell the story at a high-level better – with graphics

Agreed. This will be addressed in the v1.0 release.

Better define types of mobility data

While previous drafts distinguished various requirements for different categories of data – the current draft just defers to the wishes of the mobility providers (and the regulators who regulate them) as to what to disclose.

How does this relate with TCRP G-18?

This would be supportive of any open standards that G-18 comes forward with; numerous reviewers meet with the G-18 team on a regular basis.

We need a graphic identity and web presence that is cohesive and doesn’t rely on a single organization.

Agreed. All content has been moved to neutral internet locations.

This is a huge scope - should we start smaller?

Resolved via Admin Draft Discussion Session to be “transit first” but inclusive of other mobility.

Clarify the role of this document with respect to other, similar ones such as the California Minimum GTFS Guidelines.

The authors have attempted to address this throughout.

How is this feasible given a competitive private market who will prefer silos? How are these recommendations actionable?

The Admin draft discussion participants believed this is a necessary but not sufficient first step. Broad agreement and consistency are required in order to make progress.

Resolved Issues in Admin Review

“Open” Data Standards vs “Open Source” Data Standards - RESOLVED

Purpose: a term which encompases the attributes already defined. Desires:

  • Consistency with terms already broadly used
  • Clear in its meaning

Decision: “Open Standard” has been decided upon by the group and implemented throughout.

Options Considered:

Proposed term Comments
Open Data Standard - Can be confused with “standards” for “open data”
- The terms “open data standard” and “open standard” are widely used when discussing schema and structure
“Open data standard” does have a different definition as referring to public data sets, which makes it confusing in this context. For example, see: [https://datastandards.directory/]
Open-Source Data Standard - “Open source” is for software ownership/management.
Open Standard (selected) - This is the most widely accepted term for a data standard that is open and freely available for anyone to use. See: [https://en.wikipedia.org/wiki/Open_standard]
“Open Standard for Data” is another good formulation. See: [https://standards.theodi.org/introduction/what-are-open-standards-for-data/]

Data typologies

Purpose: to distinguish between the type of data which is required for internal system operations and may not be desired to be “public” and data which should be publicly consumable.
Decision : No decision was needed because the distinction between these data types was eliminated from the principles text (as of now)
Usage : As of the current draft, the implications of this apply only to if data should be published at a permalink.

Desires:

  • Consistency with terms already broadly used
  • Clear in its meaning

Application Area Scope Bookends

Purpose: Determine whether or not interoperability should extend to such transportation tech components as toll roads, traffic signals, etc.
Decision: Roadways operations, signals, tolls, etc to be excluded at this time in order to maintain a more manageable scope.
Desires:

  • Consistent approach for interoperability in conceptually linked transportation tech components including road management
  • Scope narrow enough to support adaptability and implementability of draft principles

Backend to/from User Experience Scope Bookends

Purpose: To determine whether specific languages or formats need to be identified for purposes of assessing interoperability of systems or if abstraction better preserves the general principle of interoperability
Decision: Remove specific references to programming languages and intra-product data storage formats, maintain specific input/output formats

MaaS Operations Discussion

Purpose: Determine if MaaS is included in this discussion? Decision:

  • Use “Transit Forward” language, remaining inclusive of other mobility options
  • Remove MaaS-specific or centering language

Discussion points:

  • Transit agencies have broader concerns about centering MaaS
  • Inclusion of MaaS terminology can spark issues with co-authorship
  • Many agencies lack policies around MaaS and are not ready for MaaS-specific discussions
  • Other mobility providers and entities want multimodal mobility to continue to be a concern, acknowledge sensitivity of terminology at this stage

Who is the “do-er” in the recommendations?

Purpose: Establish who the recommendations should be directed at Decision: Recommendations will continue to be pointed at Transportation Tech Components, individual units of hardware or software, rather than individuals or companies

Reviewers

The members of public transit, transportation system managers, academic researchers, national and state DOTs, and non-profit advocates were invited to review the admin draft starting on June 23rd, 2021.

Categorization (1) Non responsive / Not involved (2) Private reviewer (3) Public reviewer Co-signer Co-author
Public Transit Provider 31 7 1 5 5
Non-profits 5 0 1 3 3
Federal + State Organizations 3 0 2 2 3
Regional + Local Government 0 0 2 0 1
Academia 10 0 0 6 0

(1) Some organizations could realistically be categorized in multiple categories, but for simplicity of this table were only captured in one so that the cells are additive.
(2) Some of the unresponsiveness was likely due to invitations not finding the correct recipient within an organization.
(3) Several reviewers were unable to make their review public due to organizational processes

Public Reviewers

(in addition to the [co-authors] and [co-signers])

Note: staff at roughly a dozen other organizations provided substantive reviews but are maneuvering organizational frameworks for being able to be listed publicly.