CIRC4Life ICT Platform Software Data Models

General

This document includes the description of the data structures used for storing and exchanging information between software components and services.

Data Persistence Layer

The persistent storage of the ICT Platform consists mainly of a list of MongoDB databases, containing “unstructured”/dynamic data in JSON representation. On these schema-less databases, the linked relationships between them and external sources is designed with the W3C recommendation, JSON-LD. JSON-LD is a Linked Data format initiative, aiming towards the transformation of WWW to the Semantic Web. The major characteristic is the creation of links between information and the standardization of common properties using shared vocabularies/ontologies like Schema.org, openLCA and GS1 Vocabulary from GS1 SmartSearch.

The JSON-LD Schema defines all possible properties, types and values that is possible to use in a JSON-LD document.

Databases

The ICT Platform Core system contains the following databases in a MongoDB server instance:

  • 1.1.1.1 Products Master Data: In JSON-LD format, a product or material entity can be represented by the Product and IndividualProduct classes. IndividualProduct can be used in cases of a uniquely identifiable item, e.g. a tablet with a specific serial number. Product describes a more general item, e.g. a laptop model of a brand. Several properties of the product can be referenced instead of include in each JSON document to avoid duplication (e.g. manufacturer or material). A list of manufacturers should be kept once and have unique entries and material are simply other products that can be used as components of another product.
  • 1.1.1.2 User Eco-Account: In JSON-LD format, the Eco-account is actually a https://schema.org/Person linked with his Eco-balance or any other properties we may require. You can easily extend it with any other properties from https://schema.org/ or other related to business needs.

The JSON representation of MongoDB records is suitable for applying the JSON-LD linked data design to the unstructured nature of MongoDB. The data can be linked into node graphs (friend of a friend), end to end relationships (individual product to materials) and use a common metadata model: a Resource Description Framework (RDF).

See the section Data Models below for a detailed description on the modeling of database records and exchanged data structures.

External Databases

These databases are not part of the ICT Platform system, the data is imported from them:

  • 2.2.1 Intermediate Products Data: This database contains the data records that stakeholders input with the 2.1 Data Entry Tool For Stakeholders (ENV). In JSON-LD format, the Product Data Entry is actually an instance of the class https://schema.org/Product,IndividualProduct that covers the product information (properties of Schema.org Product classes), indexing (unique IDs serialNumber, productID, gtin8,12,13,14), linking with related entities (brand, manufacturer, material), and categorization (category). The Life-Cycle data (methods like ReCiPe, PEF and EcoPoints, EcoCredits, impact, etc.), traceability and certification of the whole structure record should be added. See the section Data Models/2.2.1 Intermediate Product Data record below for a detailed description of the data model.

Data Models

In the following sections each data model used in the persistence layer or exchanged between system modules is described in detail. Each data model is accompanied with its JSON-LD and JSON Schema, where those apply.

Check here for a complete directory of all the files described below. The datamodels/json-ld folder contains the JSON-LD representation of a data model, while datamodels/json-schema contain the JSON schemas. The latter are generated from the former with extra manual editing.

"@id": "<See file Brand.json>" is used by ICCS in order to avoid duplication of a full JSON-LD document inside the value of a property. For instance a JSON-LD document with this property:

"brand": {
		"@type": "Brand",
		"@id": "<See file Brand.json>"
	}

is actually expanded to:

"brand": {
	"@context": "http://schema.org",
	"@type": [
		"Brand",
		"Organization"
	],
	"@id": "<IRI of owner of this product, ideally in JSON-LD same as http://schema.org/Brand or http://schema.org/Organization.>",
	"name": "<Brand name>",
	"logo": "<An associated logo, URL or https://schema.org/ImageObject>",
	"slogan": "<A slogan or motto associated with the item.>"
}

"@id": "IRI reference to a node" is the method to refer to another node’s Linked Data JSON-LD document using an Internationalized Resource Identifier.

NOTE: All JSON-LD objects below are validated with Google’s Structured Data Testing Tool. The main vocabulary used is Schema.org so each time you read below "@type": "Typename", you should visit the URL https://schema.org/Typename for a detailed description of the class type and all of its properties.

All JSON Schemas referenced below are generated from their corresponding JSON-LD with the help of JSON Schema Tool. The initial tool output is modified is modified manually to create references between schemas. This avoids the source code generation of multiple incompatible versions of the same JSON Schema.

The JSON Schemas can be used to generate source code for various programming languages with the help of various tools: quicktype, jsonschema2pojo. Integrating these tools in your build system allows the automatic generation of source code changes after any Data model change. The generated source code encapsulates the properties of the documents and provides automatic validation of data passed to them.

The example documents referenced below contain example information wrapped with < and >. The property values that are not wrapped, are constants required by the JSON-LD schema, like "@type": "Person".

1.1.1.1 Product Master Data models

In JSON-LD format, a product data model encapsulates all information that uniquely identifies a single market product using the class type http://schema.org/Product and also custom classes for describing the life-cycle and Eco-accounting properties related to a product. The data model consists of the following main components:

  • MasterData including the product’s general and life-cycle properties.
  • MasterData.ProductData these are non-volatile data properties that should come from an authoritative service. This is the read-only part of a product record: no ICT platform processing should result in changes inside this part of the record after the its creation. Only external authorities on products should allow this. These properties come from the 2.1 Data Entry Tool For Stakeholders (ENV) and the GS1 Cloud.
  • MasterData.LifeCycle These properties come from the 2.1 Data Entry Tool For Stakeholders (ENV)
  • MasterData.LifeCycle.Impact Assessment Methods Product Impact Assessment Methods and their corresponding properties. This is a work in progress component and the responsibility of NTU, as they are the Life-Cycle Assessment specialists of the CIRC4Life project.
  • MasterData.LifeCycle.Resources Product Life-cycle resources properties, including product type standardized key codes, detailed materials list and recyclability properties.
  • MasterData.LifeCycle.Comments Free text associated with this product record.
  • EcoAccounting including the product’s Eco-points and Eco-credits. This is the volatile part of a product Master Data record. Updates from outside service to the MasterData component properties should result in a re-calculation of the Eco-accounting values for each modified product.
  • EcoAccounting.EcoPoints is a cumulative value accounting for an aggregate of the ecological impacts throughout product life cycle.
  • EcoAccounting.EcoCredits value aim to provide incentive for an adequate disposal of the products after their end-of-life.

JSON-LD

Complete documents with example data:

JSON Schema

Corresponding schemas for the documents above:

1.1.1.2 User Eco-account models

In JSON-LD format, the Eco-account is actually a https://schema.org/Person linked together with his Eco-balance or any other properties we wish. You can easily extend it with any other properties from https://schema.org/. The data model is broken into 2 main parts:

  • EcoAccount uniquely identifies the person this account belongs to. This is the part of the structure that directly maps to https://schema.org/Person.

  • EcoBalance contains the account’s Environmental Footprint properties. According to Deliverable 1.3, the main properties of the EcoBalance are the EcoCredit and EcoDebit values, calculated from a single EcoPoint value of a specific product. The EcoPoint value is calculated with the ReCiPe LCIA method, by summing-up its three end-point values of damages to human health, ecosystem and resources diversity. Also contained within EcoBalance is the history of the user’s purchased and recycled products.

JSON-LD

Complete documents with example data:

JSON Schema

Corresponding schemas for the documents above:

2.2.1 Intermediate Product Data record

This data model defines the export data schema of the ENV Data Export Service service. It contains the following hierarchy:

  • Product_Base_Data: Base product data, in the format of an array of Product JSON-LD objects.
  • Product_Parameters: Array of product parameters, e.g. Eco-points.
  • Product_LCA_Data_Entries: Array of product life cycle assessment, e.g. materials.
  • Product_LCA_Result_Aggregates: Array of product life cycle assessment aggregates.
  • Product_LCA_Results_Indicators: Array of product life cycle assessment indicators.
  • Product_EPCIS_Entries: Array of product GS1 EPCIS entries.
  • Product_Support_Resources: Array of product support resources, e.g. images and URLs.

Resources

JSON

Schemas