Open standard for Data

Description en une ligne: An open standard for data is a documented and reusable agreement that supports people and organisations publishing and using data

Description: An open standard for data is a documented and reusable agreement that supports people and organisations publishing and using data. A good starting point when developing an open standard is a shared understanding of why it is needed and what it will cover. What it isThe 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 to begin development. The Open Standards for Data Canvas is based on the Business Model Canvas and licensed under a Creative Commons Attribution 4.0 International License.What it isn'tThe Open Standards for Data Canvas is not:A detailed document: The canvas is high-level so you can quickly spot gaps and clarify assumptionsA road map: Use the canvas to outline and share the initial solution to the problem you want to solveA complete guide: The canvas focuses only on the core pillars to get you started so you can prepare more detailed documents as neededWho is it for?The Open Standards for Data Canvas is for anyone thinking of developing an open standard. The canvas will be of most interest to:Organisations developing an agreement around using dataPeople exploring what an open standard for data can do for their problemGroups interested in sharing data with at least one other partyHow to use the canvasThe canvas captures the most important things to consider when you start developing an open standard for data. It's a prototype, so let us know if it you find a gap as you work through it.The canvas is built around 9 building blocks, these are the pillars that support your open standard for data. The canvas covers key ingredients: the people and groups your standard will deliver benefits to, how they will use the standard and how you will develop and measure the standard's impact.Expect to complete the canvas at least once and update it as you clarify each building block. To get the most out of the canvas, add the name of the standard and your organisation. It’s fine to use placeholders and update these as you progress.Tip: Work through the canvas quickly to capture the information for each pillar. Don't worry if you get stuck, this highlights areas to develop.Step 1: Start by completing the vision - a single question that clarifies your vision for the standard and how it solves the problem. Try writing this as a short and simple what-if.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)Step 2: Now complete the other high level details: the standard’s name and your organisation’s name. Use placeholders if necessary.Step 3: Use THE STANDARD section to share what your open standard offers and what type of standard it is. Your standard could be guidance, a shared vocabulary or provide a format for publishing 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 consume that data in an interoperable way.The description of GTFS makes it clear that to deliver public transport information easily, the focus is on making transit information work together so it’s easy for public transit agencies to supply and developers to use.Step 4: Your open standard will be developed to solve a particular problem. Use THE PROBLEM section to clarify what the problem is. It’s useful to share why this is a problem that hasn’t been solved as concisely as possible.Finding transit directions in unfamiliar cities is difficult information is not consolidated.From Pioneering Open Data Standards: The GTFS Story, the key problem GTFS is trying to solve is that information isn’t consolidated making it hard to find transit directions in unfamiliar cities. This supports the vision and aligns with the description of the standard. Step 5: With the problem clearly stated, it’s useful to share why your standard solves the problem as opposed to other solutions currently available. Use THE SOLUTION section to share why the standard is the right solution for the problem.Existing transit standards haven’t led to consolidation of public transit information or integration into existing navigation products.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.Step 6: To tie the standard, problem and solution together, use THE USE CASE section to share how the standard will work. This section should clarify how the vision will become reality.A transit agency produce a GTFS feed to share their 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 processes including trip planning, timetable creation, data visualization, accessibility, analysis tools for planningThe GTFS example is explicit about how the key use cases will work: transit agencies will produce feeds that transit developers will consume for a variety of applications and processes. Step 7: People are an essential pillar for open standards for data. In the KEY STAKEHOLDERS section, Make a note of your 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 guidance, vocabulary, format or data produced.Google: Owner, developer and sponsorConsumers: Transit Developers i.e. people or organisations using transit information.Producers: Transit Agencies i.e. organisations that run or manage transit servicesFor GTFS, there are 2 main groups to consider along with Google who are the primary owner, developer and sponsor of the standard.Step 8: Next, share who will be the early adopters. These are the people and organisations that will first use the standard and likely to be most involved in the development process. Keep the EARLY ADOPTERS section as specific as possible by naming the people and organisationsBibiana McHugh (Portland TriMet), Chris Harrelson (Google Maps)The initial GTFS development only had 2 main organisations involved in the alpha or first phase of development. Other transit agencies were quickly recruited for the beta or second phase of development.Step 9: The people developing the standard will keep in touch with early adopters and other stakeholders. In the CHANNELS section, it's useful to consider where your stakeholders can be found: Online? Offline? At networking events? In workshops?Workshops, Google GroupsGTFS began with workshops (offline) and migrated to Google Groups (online).By now, the first 6 pillars have been completed, leaving the final 3 pillars. These 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.Tip: When completing these sections, remember to be concise and focus on getting started. Share 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 develop the standard.Step 10: In the KEY IMPACTS section, 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 the key stakeholders as well as the benefit for their key stakeholder - the general public.Step 11: Next, share known risks in the MAJOR RISKS section. These should focus on things that could derail developing the standard or adoption 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 useComplex technical formats for files - keep a simple formatClosed licensing of transit data - focus on benefits of open dataFrom 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).Step 12: Open standards aren’t developed in a vacuum; developing open standards involves resources like funding, existing tools, support for legislation, and more. Use the KEY RESOURCES section to share the main resources the open standard will need to deliver the key impacts.Funding - GoogleTransit Expertise - TriMet PortlandOpen Format License - Creative Commons Attribution 3.0 License Apache 2.0 LicenseTransit Developer - Google MapsThe list above reflects the key resources for the alpha or first release of GTFS where Google provided the funding and TriMet Portland the expertise. You should now have a single page overview to guide the development of your open standard, prepare additional documents and investigate gaps. It’s worth returning to the canvas as you progress to keep your development on track.Where to find the canvasThe latest version of the canvas: Open Standards for Data Canvas v3Download the canvas as a PDF: Open Standards for Data Canvas v3 [pdf]See an example of the canvas: Open Standards for Data Canvas: GTFS [pdf]

Image:

Site internet: https://docs.google.com/document/d/1iQMpmYFEYHgNQ7OYdbaz663H7DLzkLslLkbw9XipysM/edit#

Organisations intéressées pour contribuer ou qui contribuent déjà:

Organisations utilisatrice ou intéressée par utiliser la ressource

Contributeurs:

Tags:

Catégories:

Thème:

Référent:

Défi auquel répond la ressource:

Personnes clés à solliciter

Autre commun proche:

Type:

Dans le cadre de l'OpenChallenge ?

Niveau de développement

Espace d'échange synchrone (de type chat): [1]

Espace d'échange asynchrone (de type mail):

Lien vers l'outil de gestion des actions:

Lien vers l'outil de partage de fichiers:

Besoins:

Complément:

Prochaine Etape:

Autres informations: