The Standard ======================= 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. 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. Input fields ------------ Overview ~~~~~~~~ +------------------+----------------+-----------------------------+-------------------------+ | *Module* | *Description* | *Required fields* | *Optional* | | | | | | +==================+================+=============================+=========================+ | Product related | Information | - Partner product category | - Product category | | | about the | | | | | product/device | | - Brand | | | that someone | | | | | has attempted | | - Year of manufacture | | | to fix. To | | | | | help relate | | - Product age | | | repair issues | | | | | to particular | | | | | groupings of | | | | | products. | | | +------------------+----------------+-----------------------------+-------------------------+ | Repair related | Information | - Repair status | - Repair barrier | | | about the | | | | | attempted fix | - Problem | | | | and its | | | | | outcome. To | | | | | help ascertain | | | | | common ways in | | | | | which devices | | | | | fail and the | | | | | results of | | | | | repair | | | | | attempts. | | | +------------------+----------------+-----------------------------+-------------------------+ | Session related | Information | - ID | - Group identifier | | | about when the | | | | | repair took | - Event date | | | | place and | | | | | through which | - Country | | | | entity, e.g. a | | | | | specific | | | | | community | | | | | repair group | | | | | on a | | | | | particular | | | | | date. To help | | | | | verify the | | | | | provenance of | | | | | the repair | | | | | data. | | | +------------------+----------------+-----------------------------+-------------------------+ | Provider related | Information | - Data provider | - Record date | | | about the data | | | | | provider, i.e. | | | | | which | | | | | organisation | | | | | collected and | | | | | submitted the | | | | | data. | | | +------------------+----------------+-----------------------------+-------------------------+ Details ~~~~~~~ This section provides detailed information on each of the fields included in the standard. Product-related ^^^^^^^^^^^^^^^ **Product category** '''''''''''''''''''' EEE- “powered” - devices *Description:* A value drawn from a list of ORDS category strings. See `Product categories <#ords-product-category-values>`__. These values represent a reduced set of categories based on all item types seen across partner members. They are a cross-section of those regularly seen at community repair events, as well as those relevant to policy discussions. If an item type does not fall into an existing category, it is included in an aggregate category, e.g. “Small home electrical” or “Misc”. *Use cases:* Product categorisation allows for analysis on individual categories or combinations of categories. Repair rates and barriers across categories can be compared. We can use this to inform policy discussions on specific product categories. *Ease of collection:* These values are not generally collected or supplied but mapped from partner-provided category values to ORDS category values. See `Partner product category <#partner-product-category>`__. Non-EEE- “unpowered” - items ORDS focuses on EEE products, as they are more commonly presented at repair events and the most relevant from a policymaking perspective for the foreseeable future. **Partner product category** '''''''''''''''''''''''''''' *Description:* The original product categorisation supplied within the partner dataset i.e. the categories used to map to the ORDS product categories. *Use cases:* Including this value alongside the ORDS category will allow for alternative ways of analysing the data by end-users. It will also allow for the identification of errors, mistranslation, ambiguity and judgement-calls in the mapping, allowing for data quality enhancements. *Ease of collection:* Partners have always supplied their own categories within their datasets. The most valuable categorisations have uniformity and convention, i.e. they relate to predefined sets of values and are sanity checked at source. Ideally they are already mapped to the `ORDS product category values <#ords-product-category-values>`__. Some partner categorisation comes as free text and sometimes in languages other than English. During processing the partner category is often concatenated with another field, e.g. “product_kind” or “item_type”, e.g. “Household appliances electric ~ Coffee maker”, this extra detail helps in the mapping. Normalising the supplied categorisation makes the process of mapping less prone to error, mistranslation, ambiguity and subjectivity. **Brand** ''''''''' *Description:* Name of the item’s “brand” if it is identifiable. *Use cases:* Useful for analysing the relationship between design practices of specific manufacturers and the repairability of their products brought to repair events. *Ease of collection:* Brand is not always identifiable, some items brought to an event may be of a “generic” make. **Product age / Year of manufacture** ''''''''''''''''''''''''''''''''''''' *Description:* Product age: The estimated age of the product when seen. Year of manufacture: The year, or approximate year, that the item was made. *Use cases:* These fields allow for the analysis of estimated product age of items, i.e. how old they were when they were repaired. Useful for analysing the lifespan or durability of various product categories or brands. *Ease of collection: Product age and* year of manufacture are not always easy to record accurately. In some cases, a product's age or year of manufacture may be based on an estimate by the owner of the item. This may, in some cases, only represent how long they have owned the item, and not necessarily the exact date of manufacture or age. As such, years of manufacture and product ages should be considered estimates only, to give an indicative suggestion of how old items are when brought to community repair events. Repair-related ^^^^^^^^^^^^^^ **Repair status** ''''''''''''''''' *Description:* This is the outcome of the repair attempt that was undertaken on the device at the event. - 1: “Fixed” - if the repairer and owner were satisfied that the item can continue to be used - 2: “Repairable” - if the repairer and owner didn’t complete a repair, but identified what reasonable additional steps or professional help is needed - 3: “End of life” - if the repairer and the owner decided that it is not cost-effective or realistic to repair the device - 0: An empty or zero value is recorded as “Unknown” *Use cases:* The repair status allows us to report on rates of repair on the devices we see at repair events. In conjunction with the product category and repair barrier, we can investigate which types of products are most difficult to repair in a community context, and why. *Ease of collection:* Most providers currently record information on the repair outcome. Mapping is required to go from current partner values to the ORDS recommended values - see Appendix E. Repair groups are keen to record this information already, as they can report on their own repair success to volunteers and funders. **Problem** ''''''''''' *Description:* A description of the problem identified with the device during the repair. *Use cases*: Common problems with devices can be identified, suggesting where design improvements could be made, or for which parts provision of spares is most required. *Ease of collection*: All partners currently record information on problems encountered during the repair attempt. This is currently in free text format, which makes it difficult to perform analysis at present. We intend to provide a list of fault types to select from in a future update to ORDS. **Repair barrier** '''''''''''''''''' *Description:* A value that can be ascribed when a repair status is designated as “End of life”. One of the following options - note that either the text or number code is acceptable: 1. Spare parts not available 2. Spare parts too expensive 3. No way to open the product 4. Repair information not available 5. Lack of equipment 6. Product too worn out *Use cases:* This information is important for policy discussions, as it gives an indication of the most common recurrent barriers encountered. It was identified in conversation with iFixit, based on European policy processes they’ve followed in recent years. *Ease of collection:* Some of the historic problem text may yield values and partners are adapting data collection to comply with this field from 2021. Session-related ^^^^^^^^^^^^^^^ **ID** '''''' *Description:* Unique record identifier *Use cases:* Essential for the ORDS aggregation process and essential in data analysis. *Ease of collection:* In most cases partners hold unique ids for their records although some data is provided with a timestamp as ID and this has been known to be non-unique in a small number of cases. An ID value separate from any date value is preferred. **Event Date** '''''''''''''' *Description:* Date on which the repair event took place. *Use cases:* Useful for analysing the trends of other fields over time. For example, the prevalence of certain product categories, or the repair success rate.. *Ease of collection:* In most cases partners keep a record of the dates of their repair events. **Country** ''''''''''' *Description:* This is the country where the repair event (and thus the repair attempt) took place. *Use cases:* The inclusion of this field allows for the breakdown and comparison of information by country. For example, does the repair success rate vary between countries? What are the relative occurrences of different barriers to repair per country? *Ease of collection:* Partners should find it easy to provide this information, if they are recording the group who undertook the fix, and know where the group is based. Ideally partners can include the country per row in their dataset if not already, based on the location of the group that completed the repair, in the form of a 3 letter ISO code, e.g. “DEU”, “AUT”. If provided in the original partner data it has been included as is. If it has not been provided, the country has been assumed to be the main country of the partner organisation. **Group identifier** '''''''''''''''''''' *Description:* Unique group identification name, number or code. *Use cases:* Can be useful in data analysis. *Ease of collection:* In most cases partners are able to identify particular groups responsible for clusters of data. Where a partner does not have subsidiary groups the partner name will be used unless otherwise specified. Group identifiers do not have to explicitly name a group, obfuscation such as a code or number is sufficient. Provider-related ^^^^^^^^^^^^^^^^ **Data provider** ''''''''''''''''' *Description:* Uniquely identifies the partner providing the data. *Use cases:* Allows for analysis of the data per provider. *Ease of collection:* Can in most cases be assumed but partners are welcome to specify the exact words, phrase, spelling, punctuation and casing as they see fit. **Record date** ''''''''''''''' *Description:* The date on which the record was last updated in the partner’s database. This is not necessarily the same as the date the repair attempt took place. The data may have been uploaded after the repair event. See also `Event date <#event-date>`__. *Use cases:* The inclusion of this field can help to simplify the aggregation process by flagging the data that has changed since the last aggregation process. *Ease of collection:* If using an electronic system, providers should be able to easily record a date when repair records are inserted or updated in their database. Field reference --------------- 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 or free text. | +---------------------+---------------------------------+------------------------+ | Product category | *product_category* | Option from | | | | `product category | | | | code | | | | list <#ords-product- | | | | category-values>`__. | +---------------------+---------------------------------+------------------------+ | Product category ID | *product_category_id* | Unique identifier | | | | associated with each | | | | *product_category*. | | | | See the | | | | `product category | | | | code | | | | list <#ords-product- | | | | category-values>`__. | +---------------------+---------------------------------+------------------------+ | Brand | *brand* | Free text. | +---------------------+---------------------------------+------------------------+ | Year of manufacture | *year_of_manufacture* | Year. YYYY format. | | | | Can be derived from | | | | *event_date* minus | | | | *product_age*. | +---------------------+---------------------------------+------------------------+ | Product age | *product_age* | Float (0 to 1 dec | | | | places, e.g. 1, | | | | 1.5). Can be derived | | | | from *event_date* | | | | minus | | | | *year_of_manufacture*. | +---------------------+---------------------------------+------------------------+ | Problem | *problem* | Free text. Personal | | | | data should be | | | | removed, e.g. email | | | | addresses,. | +---------------------+---------------------------------+------------------------+ | Repair status | *repair_status* | Option from | | | | `repair status | | | | codelist <#repai | | | | r-status-values>`__. | +---------------------+---------------------------------+------------------------+ | Repair barrier | *repair_barrier_if_end_of_life* | Option from | | | | `repair barrier | | | | codelist <#repair | | | | -barrier-values>`__. | | | | 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 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. | +---------------------+---------------------------------+------------------------+ .. _section-2: Product category values ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------+-------------------------------+-----------------------------------------+ | *ID* | *Product category* | *Notes* | +======+===============================+=========================================+ | 1 | Aircon/dehumidifier | Home/office appliance that | | | | adjusts ambient air quality. | +------+-------------------------------+-----------------------------------------+ | 2 | Battery/charger/adapter | e.g. mobile phone charger, | | | | portable battery. | +------+-------------------------------+-----------------------------------------+ | 3 | Decorative or safety lights | e.g. bike lights, fairy lights, | | | | Christmas lights. | +------+-------------------------------+-----------------------------------------+ | 4 | Desktop computer | e.g. tower, mini tower, midi tower, | | | | desktop. | +------+-------------------------------+-----------------------------------------+ | 5 | Digital compact camera | e.g. smaller electronic cameras. | +------+-------------------------------+-----------------------------------------+ | 6 | DSLR/video camera | e.g. larger electronic cameras. | +------+-------------------------------+-----------------------------------------+ | 7 | Fan | e.g. cooling fan, fan heater. | +------+-------------------------------+-----------------------------------------+ | 8 | Flat screen | TVs and monitors. | +------+-------------------------------+-----------------------------------------+ | 9 | Hair & beauty item | e.g. hair straightener, | | | | toothbrush, shaver. | +------+-------------------------------+-----------------------------------------+ | 10 | Handheld entertainment device | e.g. iPod, Walkman, Gameboy. | +------+-------------------------------+-----------------------------------------+ | 11 | Headphones | e.g. over-ear, earpods. | +------+-------------------------------+-----------------------------------------+ | 12 | Hi-Fi integrated | e.g. “Boombox”, stereo. | +------+-------------------------------+-----------------------------------------+ | 13 | Hi-Fi separates | e.g. amplifier, speaker, turntable. | +------+-------------------------------+-----------------------------------------+ | 14 | Kettle | Kitchen appliance for boiling water. | +------+-------------------------------+-----------------------------------------+ | 15 | Lamp | e.g. desk lamp, floor lamp. | +------+-------------------------------+-----------------------------------------+ | 16 | Laptop | Portable computer. | +------+-------------------------------+-----------------------------------------+ | 17 | Large home electrical | e.g lawnmower, fitness machine. | +------+-------------------------------+-----------------------------------------+ | 18 | Misc | Any electronic device that does not fit | | | | in another category. | +------+-------------------------------+-----------------------------------------+ | 19 | Mobile | Any hand-held smartphone or other | | | | telecommunications device. | +------+-------------------------------+-----------------------------------------+ | 20 | Musical instrument | Any powered instrument e.g. | | | | keyboard, guitar. | +------+-------------------------------+-----------------------------------------+ | 21 | Paper shredder | Home/office appliance for | | | | shredding documents. | +------+-------------------------------+-----------------------------------------+ | 22 | PC accessory | e.g. mouse, keyboard, webcam. | +------+-------------------------------+-----------------------------------------+ | 23 | Portable radio | e.g. radio alarm, transistor radio. | +------+-------------------------------+-----------------------------------------+ | 24 | Power tool | Any powered DIY or gardening | | | | tool, e.g. leaf blower, drill. | +------+-------------------------------+-----------------------------------------+ | 25 | Printer/scanner | Any inkjet, laserjet, scanner, copier | | | | or combination appliance. | +------+-------------------------------+-----------------------------------------+ | 26 | Projector | e.g. slide projector, video projector, | | | | digital projector. | +------+-------------------------------+-----------------------------------------+ | 27 | Sewing machine | Home appliance for stitching fabric. | +------+-------------------------------+-----------------------------------------+ | 28 | Small home electrical | e.g. baby monitor, doorbell, | | | | multimeter. | +------+-------------------------------+-----------------------------------------+ | 29 | Small kitchen item | e.g. breadmaker, rice cooker, | | | | popcorn machine. | +------+-------------------------------+-----------------------------------------+ | 30 | Tablet | e.g. Kindle, Fire, satnav. | +------+-------------------------------+-----------------------------------------+ | 31 | Toaster | Kitchen appliance for | | | | browning baked goods. | +------+-------------------------------+-----------------------------------------+ | 32 | Toy | Any mains or battery powered toy. | +------+-------------------------------+-----------------------------------------+ | 33 | TV and gaming-related | e.g. set-top box, DVD player, | | | accessories | games controller. | +------+-------------------------------+-----------------------------------------+ | 34 | Vacuum | Home appliance for sucking | | | | dust and dirt. | +------+-------------------------------+-----------------------------------------+ | 35 | Watch/clock | Any electronic time-keeping | | | | or fitness monitoring device. | +------+-------------------------------+-----------------------------------------+ | 36 | Coffee maker | e.g. Nespresso, electronic | | | | filter or espresso machine. | +------+-------------------------------+-----------------------------------------+ | 37 | Food processor | e.g. multi processor, blender, | | | | juicer, coffee grinder, | | | | stick blender, hand mixer. | +------+-------------------------------+-----------------------------------------+ | 38 | Games console | e.g. Playstation, XBox. Note | | | | that a small console may be | | | | classified as a “Hand-held | | | | entertainment device”. | +------+-------------------------------+-----------------------------------------+ | 39 | Hair dryer | Appliance for hair drying | | | | and styling with warm air. | +------+-------------------------------+-----------------------------------------+ | 40 | Iron | e.g. clothes iron, steam iron. | +------+-------------------------------+-----------------------------------------+ Repair status values ~~~~~~~~~~~~~~~~~~~~ ====== =========== *Code* *Text* ====== =========== 0 Unknown 1 Fixed 2 Repairable 3 End of life ====== =========== 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 ====== ================================ .. _section-3: 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 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 <#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 <#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 <#_weykv6bpw0xy>`__ 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 <#collected-data>`__ for details of the required input. See `Field names and data types <#field-names-and-data-types>`__ for a detailed field reference. The data definitions will undergo review as and when the standard evolves. 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. 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 `__. 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 files in CSV and JSON formats, along with a manifest file that describes the package contents including schema, provider details, licence and description. Data versioning ~~~~~~~~~~~~~~~ The `ORA repository `__ makes available all previous published datasets. Naming conventions are used in filenames to maintain version identification. 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. .. _section-4: