Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to add a few types and properties to express energy efficiency of products#2670

Closed
alex-jansen opened this issue Jul 24, 2020 · 6 comments
Assignees
Labels
schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area.

Comments

@alex-jansen
Copy link
Contributor

alex-jansen commented Jul 24, 2020

Context - This is a proposal from Google based on our experience consuming schema.org Product markup and working with similar data from online merchants. If it were accepted, it would make it easier for us and others to understand energy efficiency properties of products.

Introduction

Many products advertised or sold on the web consume energy and countries around the world have regulations related to labeling such products with energy efficiency information, both online and in stores. An example of such a regulation is EU directive 2017/1369, which covers energy labeling for various categories of products. Another example is the Energy labeling rule under the Energy Policy and Conservation Act (EPCA) in the US. In addition to these regulations, consumers in general are increasingly interested in the energy efficiency of products they are researching online.

The energy efficiency characteristics of a product are typically expressed through a combination of one or more of the following elements:

  • An energy efficiency rating, which could be:
    • A flag indicating that the product meets a particular energy efficiency standard (for example, the Energy Star rating in the US), or:
    • A value out of a range of energy efficiency classes (https://en.wikipedia.org/wiki/European_Union_energy_label) in the EU. Each such class indicates a different level of energy efficiency (high to low). Different products have a different range (spectrum) of classes, for example [A+++, …, D] for dishwashers or [A,...,G] for [A++,...,E] for lamps.
  • An energy efficiency label (image) in a standardized format. Examples: EU, NZ, US.
  • A datasheet (or "fiche"), specifying details such as energy consumption, water consumption, loudness, and many others. The required line items on such a datasheet are typically different for different types of products (see examples of EU fiche requirements for air conditioners and wine coolers) and must be supplied in a specific order.

Currently, Schema.org provides no explicit support for expressing energy efficiency properties of products. Although the /PropertyValue class could be used, we believe allowing an explicit and structured way of expressing energy consumption characteristics by adding a small amount of vocabulary would benefit the ecosystem.

Proposal

Our proposal is to add a new class, for example /EnergyConsumptionDetails, that would define the energy consumption characteristics of a product. This class would then be used by a new property /energyConsumptionDetails under /Product.

Properties under this new class could include, for example:

  • energyEfficiencyRating, a value from a new /EnergyEfficiencyRating enumeration type, containing values such as "EnergyStar", "A+++", "G", etc.
  • energyEfficiencyRatingRange, a value from a new class /EnergyEfficiencyRatingRangeSpecification to specify a range (from-to) of energy efficiency ratings.
  • energyLabelImage, a URL to an image of an energy efficiency label.
  • datasheet, for which we could consider using the existing /ItemList class to represent a list of line items on the datasheet, each item being a key-value pair which could be modeled using /PropertyValue.

Some Open Questions

  • We could consider adding an explicit regional or country identifier to identify the specific locale (EU, US, …) a particular /EnergyConsumptionDetails instance belongs to.
  • Adding more structure to the datasheet (as an alternative to using key-value pairs) can be considered but for the EU alone this would lead to a very large (over 200) number of specific properties for over 25 product groups that would need to be modeled explicitly.
@danbri
Copy link
Contributor

danbri commented Jul 24, 2020

Thanks for the great writeup :)

Somewhat relevant here - @lucy-kind recently led some cleanup of our structure around Enumerations and enumerated values, to make tidier use of a type hierarchy. We've applied that idea to national code lists too, e.g. take a look at
https://schema.org/NonprofitType and https://schema.org/NLNonprofitType in https://github.com/schemaorg/schemaorg/blob/main/data/ext/pending/issue-2543.ttl - in theory we can now collect such definitions from a variety of countries / territories / regions. There will doubtless be open questions on how exactly to handle this in markup but I think we have a stronger foundation for regionalized enumerations now (also thanks @rjw for the implementation).

@danbri danbri added schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area. labels Jul 24, 2020
@alex-jansen
Copy link
Contributor Author

It is an excellent idea to use country (or region) specific enum types for energy efficiency ratings, since for example the EU has a very different energy efficiency scale (A+++ - G, depending on the product category) than Korea or China (1-5).

We could introduce a new enumeration /EnergyEfficiencyClass with sub-enum types /EUEnergyEfficiencyClass, /KEAEnergyEfficiencyClass (for Korea, also used in other countries such as Cambodia), etc.

A complete example for a /energyConsumptionDetails property under a /Product could then look as follows:


  "energyConsumptionDetails": {
    "@type": "EnergyConsumptionDetails",
    "energyClass": "https://schema.org/EUEnergyEfficiencyClassA1Plus",
    "energyScaleMin": "https://schema.org/EUEnergyEfficiencyClassD",
    "energyScaleMax": "https://schema.org/EUEnergyEfficiencyClassA1Plus",
    "energyLabelImage": "https://www.example.com/energy_label_12345.jpg",
    "datasheet": {
      "@type": "ItemList",
      "itemListOrder": "http://schema.org/ItemListOrderAscending",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "item": {
            "@type": "PropertyValue",
            "name": "supplier",
            "value": "my tv brand"
          }
        },
        {
          "@type": "ListItem",
          "position": 2,
          "item": {
            "@type": "PropertyValue",
            "name": "model",
            "value": "AA-12345Z"
          }
        },
        {
          "@type": "ListItem",
          "position": 3,
          "item": {
            "@type": "PropertyValue",
            "name": "energy efficiency class",
            "value": "A+"
          }
        },
        {
          "@type": "ListItem",
          "position": 4,
          "item": {
            "@type": "PropertyValue",
            "name": "visible screen diagonal",
            "value": "189 cm (75 inch)"
          }
        },
        {
          "@type": "ListItem",
          "position": 5,
          "item": {
            "@type": "PropertyValue",
            "name": "power consumption (in operation)",
            "value": "361 W"
          }
        },
        {
          "@type": "ListItem",
          "position": 6,
          "item": {
            "@type": "PropertyValue",
            "name": "energy consumption",
            "value": "543 kWh per year, based on the power consumption of the television operating 4 hours per day for 365 days. The actual energy consumption will depend on how the television is used."
          }
        },
        {
          "@type": "ListItem",
          "position": 7,
          "item": {
            "@type": "PropertyValue",
            "name": "standby/off power consumption",
            "value": "0,50 W"
          }
        },
        {
          "@type": "ListItem",
          "position": 8,
          "item": {
            "@type": "PropertyValue",
            "name": "screen resolution",
            "value": "7680 x 4210 pixels (H x V)"
          }
        }
      ]
    }
  

The above example defines the energy efficiency class in the EU ("A+" in this case, using a proposed enum value /EUenergyEfficiencyClassA1Plus) as well as the scale for the particular product category (A+ - D for televisions). The example also gives a link to an image of an energy efficiency label (example) as well as the product fiche (datasheet) following the EU regulation (link).

Another example, this time modeling the EnergyStar rating used in the US and many other countries could look as follows:

  "energyConsumptionDetails": {
    "@type": "EnergyConsumptionDetails",
    "energyClass": "https://schema.org/EnergyStarCompliant,
    "energyLabelImage": "https://www.example.com/energystar_label.jpg"
  }

A topic for further discussion could be to support multiple energy label images and product data sheets per /energyConsumptionDetails instance, with each image and data sheet tagged with the language and/or country it applies to:

  • Different countries may have different labeling requirements, even if using the same energy rating standard.
  • Multiple Product fiches (datasheets) in different languages are common in the EU

danbri added a commit that referenced this issue Aug 14, 2020
@danbri
Copy link
Contributor

danbri commented Aug 14, 2020

I've committed a design that @alex-jansen (from Google Shopping) and I have been working on.

It is fairly straightforward: a type representing EnergyConsumptionDetails, a property linking it from a Product, a property of the new type with enumerated values. Also an optional (EU-oriented) pair of properties of EnergyConsumptionDetails indicating maximum and minimum enumerated values. The enumerated structures make use of subtyping, so that there is a different Enumeration structure for Energy Star, and for EU's system. We have gone with Energy Star as an enumeration rather than a simple boolean, for consistency, since there are other systems (e.g. in China, Korea) that are also enumerated, and it seemed better to have a common pattern. The max/min construction is for use in the EU scheme, where it is often required to indicate the applicable range for a given product. For it to make sense, the enumeration needs to be understood as ordered; this is not currently explicit in schema.org's enumeration system can be concluded from reading the specific definitions that we give.

Background reading:

@danbri
Copy link
Contributor

danbri commented Aug 14, 2020

Draft staged: https://webschemas.org/EnergyConsumptionDetails

We should probably adopt @lucy-kind 's proposal and rename the enumeration to end in *Enumeration, but that leaves the question of whether to retain use of 'category' in hasEnergyEfficiencyCategory (the actual domain terminology seems to use 'class' heavily but that's a poor fit for us as 'class' at schema.org is the same thing as a type, i.e. a fundamental modeling primitive).

@alex-jansen
Copy link
Contributor Author

This was published in release #10.0 (https://www.schema.org/EnergyConsumptionDetails)

@DamonHD
Copy link

DamonHD commented Sep 22, 2022

For this to make sense for the EU labels at least don't we also need to know the year that the label was issued?

I had two new appliances that were simultaneously issued with A++ and D labels (or similar) because of the rebasing for those categories.

It might also make sense to have slots for at least the annual energy consumption and an optional URL for the full fiche/document?

Or do I need to read this thread from the top properly to find out why I'm wrong? B^>

Rgds

Damon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area.
Projects
None yet
Development

No branches or pull requests

3 participants