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¶
|Product related||Information about the product/device that someone has attempted to fix. To help relate repair issues to particular groupings of products.||
|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.||
|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.||
|Provider related||Information about the data provider, i.e. which organisation collected and submitted the data.||
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.
|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*.|
|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”.|
A unique identifier across all partners that can identify the group responsible for the repair.
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”.|
Date. YYYY-MM-DD format.
The date that the record was last updated.
3.4.2. ORDS product category values¶
|Food processor||e.g. multi processor, blender, juicer, coffee grinder, stick blender, hand mixer|
|Decorative or safety lights||e.g. bike lights, fairy lights, Christmas lights|
|Digital compact 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|
|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|
|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|
|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¶
|3||End of life|
3.4.4. Repair barrier values¶
|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¶
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.