openEPD Interchange Format

The developing ecosystem of interoperable sustainability tools needs standard ways of exchanging EPD and LCA data, without constraining any particular implementation.

There exists a European standard for LCA (ILCD) which is very useful for documenting and transferring LCAs and processes, but was not intended as a medium for web services searching and exchanging EPDs. There is an extension, ILCD+EPD which is more tailored to EPDs, but which lacks key properties required for systems to interoperate successfully (for example, a way to uniquely identify an organization, person, address, or LCIA method)

openEPD is a digital interchange standard that builds on the ILCD thought process, applying OpenAPI design principles and a high degree of specificity. A detailed spec is available in this spreadsheet.

OpenAPI schema interactive try-it-out interface for openEPD REST API by BuildingTransparency is available.

Operating principles

The openEPD standard format is Open, Standardized, Interoperable, Agile, and Secure.

Open

• Free to read and to use. Participant(s) must disclose any IP rights (e.g. patents) required to implement the standard, and to license any such right(s) at no cost to other participant(s).
• Posted and Documented on GitHub
• BuildingTransparency provides key helper functions (e.g. unique ID code generation/check, checksum generation) as open-source reference code.

Standardized

• Compatible with ISO 14025, EN 15804, and major North American PCRs.
• Compliant to OpenAPI 3.0 standard
• Compatible with ILCD.
• Compatible with MasterFormat.

Interoperable

• Should follow software best practice regarding separation of concerns, platform independence, and error handling.
• Mandatory fields
• Must be present in every valid openEPD
• Have precise definitions
• Must be understood and processed by an openEPD compliant system.
• Optional fields
• May be present or not present in a valid openEPD
• Have precise definitions
• Must not be required by an openEPD compliant system.
• Should be stored (but not necessarily interpreted or used) by an openEPD compliant system.
• Standard testing interface(s) and examples to help organizations build interoperable solutions.
• Compatible with a wide variety of operating systems and database systems.
• Versioned, so future releases can be backwards-compatible.

Agile

Every sector is different, and the sophistication of LCA is always increasing. openEPD will need to grow and develop in ways we can’t always foresee, but do so in a way that doesn’t break compatibility.

• Standard extensions
• Defined by sector-specific groups (e.g. concrete, steel, carpet …) based on sector PCRs.- Properties can be Mandatory or Optional for that sector extension.
• Should be stored (but not necessarily interpreted or used) by openEPD compliant systems.
• Extensions can be sub-extended as desired (e.g. concrete.masonry.property_name)
• Custom extensions
• Useful for experimentation and for proprietary extensions,- Can be defined by anyone with any format.
• Should be transparently stored as JSON (but not necessarily interpreted or used) by openEPD compliant systems.

Secure

• oAuth 2.0 and API key authentication.
• Robust to code-injection and other standard vulnerabilities
• Optional Digital Signature
• Optional Data Integrity Field.

Mandatory fields

• Must be present in every valid openEPD, so that compliant systems know which properties they can count on.
• Have precise definitions, checkable using the reference system.
• Must be understood and processed by an openEPD compliant system.
• Examples for EPD:

• An extension (e.g. concrete) can define its own mandatory fields which are mandatory for that extension only, e.g. ‘concrete.compressive_strength_28d’

Optional fields

• May be present or not present in a valid openEPD
• Must not be required by an openEPD compliant system, i.e. a compliant system should work even if these values are missing.
• If these fields are present, they must be stored and returned (but not necessarily interpreted or used) by an openEPD compliant system. This requirement ensures that systems don’t alter EPDs when passing them around.
• Have precise definitions
• Examples for EPD:

• An extension (e.g. concrete) can define its own optional fields which are defined for that extension only, e.g. ‘concrete.compressive_strength_other_days’

Standardized object types

The main purpose of this standard is to permit interchange of Environmental Product Declarations (EPDs) and similar documents. In order to do this, however, it is helpful to define interoperable formats for describing Product Category Rules (PCRs) and the Organizations (Orgs) related to those EPDs.

Full schema specification is given in REST API schemas section. Below are some example object types which have defined schemas:

Text

• Strings, unicode formatted and with maximum length of 500 characters
• 500 chars in order to support ILCD String, Nullable String, and String MultiLang.
• Text fields, which will be unicode formatted and limited to 1 million characters.
• Supports ILCD FT, FTMultiLang, ST, STMultiLang

Measurements

• Absolute numbers must be expressed in the standard SI unit defined for that field, e.g.1 for 1 m2 of area.
• E.g. kgCO2e for global warming potential, kg for mass, m2 for area, etc.
• Supports ILCD Int1, Int5, Int6, and Real
• Wherever possible, measurements will be used instead.
• Measurements should be expressed as JSON objects of /measurement schema, for example {"mean": 24.5, "rsd":0.124,"unit":"kg",dist: "log-normal"} which means 24.5 kg ±12.4%, with a lognormal distribution [24.5,"kg",0.124,"log-normal"] which means 24.5 kg ±12.4% per the spec
• Measurement Format for openEPD .
• All JSON number formats should be accepted (e.g. 1.23e-3, 0.00123, 123000)

EPDs

• Uniquely identified by a registered ID, e.g. "ec3zsed8" in open-xpd-uuid format.- The combination of program_operator.website, program_operator_doc_id, name, and version fields must be unique.
• POSTing an EPD always returns a compact globally unique ID.

Uncertainty

• All measurements should carry a documented uncertainty; where one is not present it may be assumed to be large (e.g. less certain than 80% of available measurements)
• Should be based on the variability in the upstream dataset, where specific product EPDs for inputs and specific on-site measurements were not used. Best practice is to use teh BuildingTransparency uncertainty methodology.
• Should be declared as described in Measurement Format for openEPD.

Data Sourcing

An EPD needs to provide both its summary data (for use by downstream applications) and the sources of its data (so it can be checked, and so that the result can be adapted from the author’s methodology to a consumer’s methodology).

• Basic structure for documenting inputs (by guid) and quantities.
• Ideally should be sufficient to recreate the declared value(s)
• Should provide a persistent hyperlink to the relevant LCA study
• Stick as close to ILCD as reasonable

Sector-specific extensions

Every sector has different performance attributes, classifications, and methods. Sector specific extensions extend the base openEPD with those properties.

Sector-specific extensions will be carried in a named specs json property, the internal format of which is up to the group who define the extension. For example:

{
  "Concrete": {
    "strength_28d": "35.5 MPa",
    "strength_other": 25,
    "strength_other_d": 3,
    "ext_version": "1.0"
  }
}

Proprietary extensions should be placed in ext part of any openEPD schema. openEPD compatible systems should store and return these fields, but only interpret if they are specifically designed to do so. Example:

{
  "ext": {
    "my-company.com": {
      "vertexID": "12345-56780-999"
    }
  }
}

• Extensions may be nested inside other extensions.
• Extensions should follow all the same rules as the parent standard, for example with respect to versioning, naming, and compatibility.

Related standards

• European standard (ILCD) in XML
• ECOinvent’s LCI dataset input format ‘ECOspold’ . Has a dedicated editor " EcoEditor". https://www.ecoinvent.org/database/older-versions/ecoinvent-version-2/methodology-of-ecoinvent-2/ecospold1/ecospold1.html
• openLCA (json-LD)
• Bonsai.uno (github bonsamurais/bonsai)