Open Standards for Data Canvas

A good starting point when developing an open standard is a shared understanding of why it is needed and what it will cover. The canvas is a way of documenting and sharing that understanding

Who is it for?

The Open Standards for Data Canvas is for anyone thinking of using or developing an open standard. The canvas will be of most interest to organisations, people and groups that are:

• using or developing an agreement based on sharing data

• exploring how an open standard for data can solve their problem

• interested in sharing data with at least one other party

What it is

The canvas is a single view of the pillars that support your open standard: the problem, solution, resources, risks and impacts. It outlines how your standard delivers benefits to stakeholders and what you need in order to begin using or developing the standard.

The Open Standards for Data Canvas is based on the Business Model Canvas and licensed under a Creative Commons Attribution 4.0 International License. Please attribute The Open Data Institute.

What it isn't

The Open Standards for Data Canvas is not:

• a detailed document: the canvas is high-level so you can quickly spot gaps and clarify assumptions

• a roadmap: you can use the canvas to outline and share the initial solution to the problem you want to solve. The canvas will help you develop a roadmap during the later scoping and starting stage

• a complete guide: the canvas focuses only on key areas to get you started so you can prepare more detailed documents as needed

How to use the canvas

The canvas details the most important things to consider when you start developing an open standard for data.

The canvas is built around three sections:

• Why the standard is necessary

• Who the standard will affect

• How the standard was or will be developed

In the sections are nine building blocks. These are the pillars that support the open standard for data. The canvas covers:

• the people and groups the standard will deliver benefits to

• how they will use the standard

• how you will develop the standard and measure its impact

Expect to complete the canvas at least once and update it as you clarify each section. It’s fine to use placeholders and update these as you make progress.

Work through the canvas quickly to capture the information for each section. Don't worry if you get stuck, this highlights areas to develop.

Step one: Start by outlining the vision – a single question that clarifies the vision for the standard and how it solves the problem. Try writing this as a short and simple what-if question.

What if it was as easy to find public transport information as it is to find driving directions?

This was the question that triggered Google’s General Transit Feed Specification (GTFS) and provided the vision for the standard GTFS Example [pdf]

Step two: Now complete the other high level details: the standard’s name and the organisation’s name. Use placeholders if necessary.

Why

‌Use the 'Why' section to make the case for the standard – the information here will be useful in building a business case, engaging stakeholders and demonstrating you have done your research on existing standards.

Step three: Start with 'The standard' pillar to say what the open standard offers and what type of standard it is.

The standard could be a guide, a shared vocabulary or might provide a format for sharing and using data. Keep this section as concise as possible and make sure it aligns with the vision.

Common format for public transportation schedules and associated geographic information that lets public transit agencies publish their transit data and developers write applications that use that data in an interoperable way.

The above description of GTFS makes it clear that to deliver public transport information easily, the focus must be on making transit information work together so it’s easy for public transit agencies to supply and developers to use. GTFS Example [pdf]

Step four: An open standard is developed to solve a particular problem. Use ‘The problem’ pillar to clarify what the problem is.‌

It’s a useful way to summarise a problem that might not yet have been solved.

Finding transit directions in unfamiliar cities is difficult & information is not consolidated.‌

From Pioneering Open Data Standards: The GTFS Story, the problem GTFS is trying to solve here is information not being consolidated, which makes it hard to find transit directions in unfamiliar cities. This supports the vision and accords with the description of the standard. GTFS Example [pdf]

‌Step five: Use ‘The solution’ pillar to share why the standard is the right solution for the problem.

With the problem clearly stated, it’s useful to say why the standard is a better solution than others currently available.

GTFS uses a simple format and approach to make it easy to consolidate public transit information and integrate it into navigation products used by the public.

Here, the key reasons why GTFS is the solution to the problem are shared: the public uses navigation products to get directions, so it makes sense to shift the focus here. GTFS Example [pdf]

Step six: To tie the standard, problem and solution together, use ‘The use case’ pillar to share how the standard will work.

This section should clarify how the vision will become reality.

A transit agency produces a GTFS feed to share its public transit information with developers, who write tools that consume GTFS feeds to incorporate public transit information into their applications.

GTFS feeds can be used in a variety of applications and processes, including trip planning, timetable creation, data visualisation, accessibility, and analysis tools for planning.

‌The GTFS example is explicit about how the key solutions will work: transit agencies will produce feeds that transit developers can consume for a variety of applications and processes. GTFS Example [pdf]

Who

Successful engagement with the right people is essential for a successful open standard for data. Use the 'Who' section to establish who will be affected by and use the open standard. Say how you expect to communicate with them.

Step seven: In the ‘Key stakeholders’ pillar, make a note of the key stakeholders. These are the people and organisations that will own, fund and develop the standard as well as those who will share and use the guide, vocabulary, format or data produced.

• Google: Owner, developer and sponsor

• Consumers: Transit Developers, ie people or organisations using transit information

• Producers: Transit Agencies, ie organisations that run or manage transit services

For GTFS, there are two main groups to consider besides Google, who are the primary owner, developer and sponsor of the standard. GTFS Example [pdf]

Step eight: Next, share who will be the early adopters. These will be the people and organisations to first use the standard and likely to be the most involved in the development process.

Keep the ‘Early adopters’ pillar as specific as possible by naming the people and organisations.

Bibiana McHugh (Portland TriMet), Chris Harrelson (Google Maps)

The initial GTFS development had two main organisations involved in the alpha or first phase of development. GTFS Example [pdf]

Step nine: The people developing the standard will keep in touch with early adopters and other stakeholders. In the ‘Engagement’ pillar, it’s useful to consider where stakeholders can be found: Online? Offline? At networking events? In workshops?

Workshops, Google Groups

GTFS began with workshops (offline) and migrated to Google Groups (online). GTFS Example [pdf]

How

At this stage, the first six pillars describing the nature of the standard ('What'), and 'Who' the standard is aimed at have been completed, leaving the final section – 'How'.

These three pillars focus on impacts, risks and resources – what benefits the standard will bring, what could derail the standard and what’s available to help the standard deliver those benefits.

When completing these sections, remember to be concise and focus on getting started.

List the strongest benefits, the major risks and known resources. Keep in mind that unexpected benefits, new risks and unknown resources may come up as you assess or develop the standard.

Step 10: In the ‘Key impacts’ pillar, share what will change once the standard is developed and adopted. What benefits will stakeholders see?

A standard open format will make public transit information available to any developer, provide good publicity for transit agencies and a useful service to the general public.

For GTFS, this outlines the benefits for key stakeholders as well as the benefit for its key stakeholder – the general public. GTFS Example [pdf]

Step 11: Next, share known risks in the ‘Major risks’ pillar.

These should focus on things that could derail the development or adoption of the standard.

Include technical, legal, social, environmental, or political challenges or weaknesses. Where possible, briefly describe how risks will be mitigated.

• Perceived lack of benefits to transit agencies – demonstrate universal use

• Complex technical formats for files – keep a simple format

• Closed licensing of transit data – focus on benefits of open data

From Pioneering Open Data Standards: The GTFS Story, the main risks were one stakeholder gaining all the benefits (social), keeping file formats simple (technical) and ensuring transit data was open (legal). GTFS Example [pdf]

Step 12: Open standards aren’t developed in a vacuum. Developing open standards requires resources like funding, existing tools, support for legislation, and more.

Use the 'Key resources' pillar to share the main resources that the open standard will need to deliver the key solutions.

• Funding – Google

• Transit expertise – TriMet Portland

• Open format license – Creative Commons Attribution 3.0 License and Apache 2.0 License

• Transit developer – Google Maps

The above list reflects the key resources for the alpha or first release of GTFS, where Google provided the funding and TriMet Portland the expertise. GTFS Example [pdf]

Once you have completed the canvas, you will have an overview of your open standard. This can guide the development or adoption of the open standard including any additional documents you need to prepare or gaps in your understanding that need to be filled. You will now have a single page overview to guide the development or adoption of the open standard, prepare additional documents and investigate gaps.

Sharing the canvas for comment either as a public document or directly with key stakeholders and early adopters will open you up to useful feedback early on.

It’s worth returning to the canvas as you progress to keep your development on track.