Search:

 

Navigation

API Reference

Create or Find Page:

 

View Data Dictionary

Inventory Schema

This section describes the purpose of the various classes included in the Platform Data Dictionary schema.

Inventory Class

An Inventory object describes the inventory’s authorization and publication, defines the temporal, pollutant, sectoral, and/or organizational boundaries, and contains collections of EmissionMetric, ParameterValue, EmissionFactorValue, and ActivityDataValue objects representing the inventory’s reported data.

Each reported data object—EmissionMetric, ParameterValue, EmissionFactorValue, and ActivityDataValue—must have a parent Inventory.

Pollutant, SourceCategory, EstimationMethodology, Parameter, EmissionFactor, ActivityData, and Fuel Classes

The Pollutant, SourceCategory, EstimationMethodology, Parameter, EmissionFactor, ActivityData and Fuel classes are designed to represent static dimensions that do not change from inventory to inventory.  Emission metrics and other inventory-specific values are not properties of these unchanging objects.

  • A single Pollutant object will be defined for each pollutant or family of pollutants (PFCs, HFCs, VOx, NOx, SOx, etc) included in an inventory that is represented within the platform.  Note that within a single inventory, emissions may be represented as belonging to both a single chemical, and a family of pollutant.  For example, emissions may be represented as both C2F6 and HFC.
  • SourceCategory, EstimationMethodology, Parameter, EmissionFactor, and Fuel objects will be drawn directly from authoritative guidance documents used to inform the creation of inventories.  Where such a guidance document does not exist, the inventory itself (or a relevant appendix) may be treated as a guidance document.  Specific versions of guidance documents, such as the 1996 and 2006 IPCC Guidelines for Greenhouse Gas Inventories will be treated as separate and unique guidance documents.
  • Where ActivityData objects are defined by an authoritative guidance document, they will be drawn from the guidance document.  When inventories reference activity data that is not defined by authoritative source documentation, a generic ActivityData object will be used in its place.

The platform will provide users with three primary means of identifying similar SourceCategory, EstimationMethodology, Parameter, EmissionFactor, ActivityData and Fuel objects drawn from different guidance documents and/or used by different inventories:

  • by associating these objects via their shared relationships with EmissionMetric objects, as well as ParameterValue, EmissionFactorValue, and ActivityDataValue objects;
  • by representing authoritative efforts to “crosswalk” source categories, estimation methodologies, etc., defined by one guidance document with those defined in a second guidance document.  This is accomplished by including surrogate key properties in the SourceCategory, EstimationMethodology, and EmissionFactor classes; andby associating static objects with keywords, via the keywordList property.

Parameter, EmissionFactor, and ActivityData objects are used to represent the coefficients, variables, and constants included in emission estimation equations.  The Parameter class may be used to represent any coefficient, variable, or constant included in an emission estimation equation and is the parent or superclass of the EmissionFactor and ActivityData classes; EmissionFactor objects and ActivityData objects each make up a subset of all Parameter objects.  An EmissionFactor object represents an emission factor coefficient as defined by an authoritative guidance document; an ActivityData object represents a measure of emitting or removal activity.

EmissionMetric Class

The EmissionMetric class represents emission estimation metrics reported by inventories, and places those metrics in their proper context by associating them with ample amounts of structured metadata.  An EmissionMetric object reports the emission metric itself using the value, units, lowerBound, upperBound, andvalueCO2e properties.  It provides textual context with the description, uncertainty, and qualityControl properties.  Finally, it establishes the boundaries of the reported metric with the properties.

  • estimationMethodology (methodological boundary),
  • geographicCoverage, location (geographic boundary),
  • pollutant (pollutant boundary),
  • sourceCategory (sectoral boundary), and
  • timePeriod (temporal boundary)

In addition, the paramaterValueList, emissionFactorValueList, and activityDataValueList properties link the EmissionMetric to the specific parameters used in the emission estimation equation.

With its dual role as a “storage engine” for emission statistics and schematic hub associating static Pollutant, SourceCategory, EstimationMethodology, Parameter, EmissionFactor, and ActivityData objects with reported metrics and each other, the EmissionMetric object is the foundational class in the common air pollutant inventory framework.

ParameterValue, EmissionFactorValue, ActivityDataValue, and GwpValue Classes

Like EmissionMetric, the ParameterValue, EmissionFactorValue, ActivityDataValue, and GwpValue classes report inventory specific metrics.  The ParameterValue, EmissionFactorValue, and ActivityDataValue classes represent specific values for variables used in emission estimation equations.  The ParameterValue class can represent any variable used in an emission estimation equation; EmissionFactorValue and ActivityDataValue extend ParameterValue, and can represent only emission factors or activity data.

The GwpValue class applies to GHG or BC inventories that use estimates of global warming potential to produce a metric for equivalent carbon dioxide emissions (the co2eValue property in the EmissionMetric class).

ScholarlyArticle and GuidanceDocument Classes

The ScholarlyArticle class, defined by Schema.org vocabulary, is used to represent scholarly articles used as data sources for source categories, estimation methodologies, and emission factors.  The SourceCategory, EstimationMethodology, and EmissionFactor classes each contain an articleList property used to represent citations of scholarly articles.

The GuidanceDocument class extends the ScholarlyArticle class and is used to represent an authoritative framework of source categories, estimation methodologies, emission factors, or fuels used to produce inventories.  By defining authoritative lists of source categories, estimation methodologies, emission factors, and fuels, a guidance document plays a unique and central role in inventory development, and serves a distinct purpose from that of a scholarly article cited as a data source.

Class Definitions Taken From Other Vocabularies

The schema relies heavily on class definitions taken from other structured vocabularies.  Four criteria were applied in selecting vocabularies to integrate with the Platform’s Data Dictionary:

  • the existence of an online data dictionary, or other documentation providing clear, human-readable class and property definitions (required);
  • the existence of an RDF vocabulary definition, expressed using RDF, RDFS, or OWL (required);
  • acceptance by government officials and other stakeholders who work closely with environmental datasets; and,
  • common usage on the internet, especially by search engines.

At the moment, the schema integrates class definitions from the Dublin Core and Schema.org vocabularies, two frameworks that maintain a human-readable data dictionary, a machine readable RDF vocabulary definition, and are commonly used on the internet.

From Dublin Core, the schema integrates:

From Schema.org, the schema integrates:

How To Read a Class Definition

Each class definition adheres to a standard format that provides class and property definitions, inheritance information, notes on important relationships with other classes, and answers to common questions.  Each section of a class definition is briefly described below.

Definition

A brief description of the object the class describes.

Inheritance

A breadcrumb-style list of the class’s parent, or superclass.  A child, or subclass, will inherit all of the properties of its parent class.  Therefore, a child class will represent a subset of the objects that may be represented by a parent class.  Consider the following example:

Animal < Dog < GoldenRetriever

In this example, the Animal class has a subclass Dog, which has a subclass GoldenRetriever.  Rex, the neighborhood golden retriever, may be represented by either an Animal, Dog, or GoldenRetriever object.  However, the GoldenRetriever object is likely to provide the best representation of Rex as it will contain properties specific to Rex’s species and breed.

Within the Platform’s schema, one example of class inheritance is:

Parameter < EmissionFactor

Here Parameter may represent any parameter—coefficient, variable, or constant—used in an emission estimation equation.  The subclass EmissionFactor may represent only emission factors.  Note that in the EmissionFactor class definition, properties inherited from Parameter are clearly segregated from the many additional properties specific to EmissionFactor.

Subclasses

A list of the subclasses which inherit the class’s properties.

Properties

A property is a field of data within a class.  Each property has a name, a type, and a definition.  A property’s type represents the type of object the property assumes, and is likely to include a link to the relevant class definition.

Within the schema, certain types of properties have special meanings users should be aware of.

  • Surrogate keys are used to represent unique identifier codes given by guidance documents to source categories, estimation methodologies, and emission factors.  Where a source category, estimation methodology, or emission factor has been “cross-walked,” or matched to a similar object defined by a different guidance document, surrogate key properties will represent the pairing.  The name of each surrogate key property adheres to a standard format, ending in the word “Code.”

  • {country code}{guidance document}Code

  • List properties are used to represent one-to-many relationships.  When a property be represented by more than one object, it is defined as a list property and the word “List” is appended to the property name.
  • The keywordList property links static objects such as SourceCategory objects or EstimationMethodology objects to a list of relevant keywords, which are used to link similar objects defined by different frameworks.
  •  

Key Relationships

Brief descriptions of the important relationships between the class and other classes.

Notes

Relevant notes and answers to frequently asked questions.

UML Class Diagram of Inventory Schema