3. The Standard

3.1. Guiding principles

As members of the Open Repair Alliance, organisations are committed to share data that is accessible, useful and usable for a range of partners.

To ensure this, organisations are expected to consider that their Open Repair data is:

  • Structured - data is valid in line with the requirements of the standard
  • Comparable - data can be linked across publishers through codelists and shared references
  • Open - data is appropriately licensed and published
  • Accurate - data is as accurate as possible
  • Timely - data is kept up-to-date and updated regularly

The standard is focused on collecting and sharing information about repair of small electricals and consumer electronics. Due to the open nature of the standard, it could in the future lead to adaptations to cater for other areas of repair information.

3.2. Collected data

This section describes the data that we collect as part of the standard.

There is a wide variety of data that can be and is being collected on the topic of repair. We recognise that not all organisations have the need or capacity to collect all of this data, and further we recognise the tension between the ideal data we would like to collect and the ability to collect that data in busy repair environments, usually by volunteers.

As such, the standard is grouped into logical ‘modules’ that group together related fields, and within these modules fields are classified as required or optional. Modules are described as either primary or additional. To be fully compliant with the standard, data must aim to include all required fields in the primary modules.

The decision to define a field as ‘required’ is based on a number of factors surrounding use cases and benefits of the data the question would produce, and the complexity of data collection for that question, including who is being asked to collect the data and how - for example, we wish to avoid overloading volunteers with data collection. Every required field should be traceable back to a particular use case and goal.

3.3. Input fields

3.3.1. Overview

Module Description Required fields Optional
Product related Information about the product/device that someone has attempted to fix. To help relate repair issues to particular groupings of products.
  • Partner product category
  • Product category
  • Brand
  • Year of manufacture
Repair related Information about the attempted fix and its outcome. To help ascertain common ways in which devices fail and the results of repair attempts.
  • Repair status
  • Problem
  • Repair barrier
Session related Information about when the repair took place and through which entity, e.g. a specific community repair group on a particular date. To help verify the provenance of the repair data.
  • ID
  • Event date
  • Country
  • Group identifier
Provider related Information about the data provider, i.e. which organisation collected and submitted the data.
  • Data provider
  • Record date

3.3.2. Details

This section provides detailed information on each of the fields included in the standard.

3.4. Field reference

3.4.1. Field names and data types

For some fields a formal set of options is required, referred to here as a ‘codelist’. A codelist provides mandatory codes and publishers should only use values provided in the official list. Changes to codelists take place through the governance and revision process.

Title Field name Type
ID id Unique identifier from the partner organisation. Does not have to be unique across all partner data.
Partner category partner_product_category Option from partner codelist.
Product category product_category Option from ORDS *product category codelist*.
Brand brand Free text.
Year of manufacture year_of_manufacture Year. YYYY.
Problem problem Free text. Personal data should be removed, e.g. email addresses,.
Repair status repair_status Option from ORDS *repair status codelist*.
Repair barrier repair_barrier_if_end_of_life Option from ORDS *repair barrier codelist*. Optional. Only relevant where repair_status = “End of life”.
Group identifier group_identifier

String. Unique.

A unique identifier across all partners that can identify the group responsible for the repair.

Event date event_date

Date. YYYY-MM-DD format.

The date of the repair event that the repair took place at.

Data provider data_provider Option from ORDS codelist. Name of partner organisation.
Country country String. 3 letter ISO code, e.g. “GBR”.
Record date record_date

Date. YYYY-MM-DD format.

The date that the record was last updated.

3.4.2. ORDS product category values

Product category Notes
Food processor e.g. multi processor, blender, juicer, coffee grinder, stick blender, hand mixer
Coffee maker  
Decorative or safety lights e.g. bike lights, fairy lights, Christmas lights
Desktop computer  
Digital compact camera  
DSLR/video camera  
Fan e.g. cooling fan, fan heater
Flat screen TVs and monitors
Games console e.g. Playstation, Gameboy
Hair & beauty item e.g. hair straightener, toothbrush, shaver
Hair dryer  
Handheld entertainment device e.g. iPod, Walkman
Hi-Fi integrated e.g. “Boombox”, stereo
Hi-Fi separates e.g. amplifier, speaker, turntable
Large home electrical e.g lawnmower, fitness machine, steam mop
Musical instrument e.g. electric keyboard, electric guitar
Paper shredder  
PC accessory e.g. mice, keyboard, webcam
Portable radio e.g. radio alarm, transistor radio
Power tool e.g. DIY tool
Projector e.g. slide projector, video projector, digital projector
Sewing machine  
Small home electrical e.g. baby monitor, doorbell, multimeter
Small kitchen item e.g. breadmaker, rice cooker, popcorn machine
Tablet e.g. Kindle, satnav
TV and gaming-related accessories e.g. set-top box, DVD player

3.4.3. Repair status values

Code Text
0 Unknown
1 Fixed
2 Repairable
3 End of life

3.4.4. Repair barrier values

Code Text
1 Spare parts not available
2 Spare parts too expensive
3 No way to open product
4 Repair information not available
5 Lack of equipment
6 Item too worn out

3.5. Producing and sharing compliant data

Compliant data is data that

  • contains the required data as agreed per this standard
  • conforms to the field definitions as agreed per this standard
  • is provided in the format as agreed per this standard
  • is licensed as agreed per this standard
  • is publicly available for download

3.5.1. Data format

For data to be comparable, the values recorded for each field need to conform as prescribed e.g. a date value should conform to the agreed date format. See *Field names and data types* for a detailed field reference.

The data should be supplied in Comma Separated Values (CSV) format, where each row represents a single repair attempt, and will contain columns for each of the required fields listed above as well as additional fields where possible. The first row should be a header row and contain the column names matching those of the field names described in *Field names and data types*. The header row should be in English if possible.

Wherever possible, partners’ original values should be mapped to the ORDS codelist values as described in the *Field reference* section.

Should there be a discrepancy between the prescribed data format and the supplied data format it would be desirable that a changelog or manifest or some form of documentation describing the differences be supplied also. See the *Collected data modules section* for details of the required input. See *Field names and data types* for a detailed field reference.

The data definitions will undergo review as and when the standard evolves.

3.5.2. Data collection tools

The Open Repair Alliance does not prescribe any particular tools for data collection or provision, however individual members are encouraged to share advice and help on any tools they have found useful. Partners are welcome to reach out to the organising body for assistance and advice in regard to tools and processes.

3.5.3. Data publishing

The Open Repair Alliance aims to publish every 6 months. The processed datasets are stored in a *public version control repository* and made available for download at *openrepair.org*.

3.5.4. Data output

The export process results in a package for each partner and one that contains an aggregate of all partner data.

Each package is labelled using a convention that describes its contents and comprises two data files - one CSV format, one JSON format - along with a manifest file that describes the package contents including schema, provider details, licence and description.

3.5.5. Data versioning

The *ORA repository* makes available all previous published datasets. Naming conventions are used in filenames to maintain version identification.

3.5.6. Data licensing

Supplied data must be licensed under the *Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0*).

As the Data Standard evolves, licensing will be reviewed in order to best address the potential commercial use of the data by third parties.