Skip to content

Commit

Permalink
Update DPP, DCC, DTE, and DFR to version 0.4.1 ready for pilot testin…
Browse files Browse the repository at this point in the history
…g. (#175)

Update DPP, DCC, DTE, and DFR to version 0.4.1 ready for pilot testing.
Add annotated visualisations. Closes #167, #149, #137, #164, #129, #117,
#68, #83, #69, #49, #24, #72, #73, #74
  • Loading branch information
onthebreeze authored Oct 1, 2024
2 parents d54bc5a + 1db5bf0 commit 02e46fc
Show file tree
Hide file tree
Showing 15 changed files with 539 additions and 112 deletions.
139 changes: 123 additions & 16 deletions website/docs/specification/ConformityCredential.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,17 +7,35 @@ import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

* **[Latest JSON-LD @context](https://test.uncefact.org/vocabulary/untp/dcc/0/untp-dcc-context-0.3.10.jsonld)**
* **[Latest JSON Schema](https://test.uncefact.org/vocabulary/untp/dcc/0/untp-dcc-schema-0.3.10.json)**
* **[Sample Instance](../../samples/untp-digital-conformity-credential-v0.3.10.json)**
Are maintained at https://test.uncefact.org/vocabulary/untp/dcc/0/about

## Versions
### Stable Releases For Implementation

Version 1.0 stable release for production implementation is due Jan 2025

### Release for Pilot Testing

Digital Conformity Credential version 0.4.1 release artifacts can be used for pilot testing.

* [JSON-LD @context](https://test.uncefact.org/vocabulary/untp/dcc/0.4.1/)
* [JSON Schema](https://test.uncefact.org/vocabulary/untp/dcc/untp-dcc-schema-0.4.1.json)
* [Sample Instance](https://test.uncefact.org/vocabulary/untp/dcc/untp-dcc-instance-0.4.1.json)

### Latest Development Version

Latest development versions are used to reflect lessons learned from pilots but should not be used for either pilot testing or production purposes.

### Version History

History of releases is available from the **[Version history](https://test.uncefact.org/vocabulary/untp/dcc/0/versions)** page.


### Visualization

A UNTP digital product passport may be rendered in any format desired by the issuer. However a default **[Visualization](../../samples/DigitalConformityCredentialRender.png)** is provided here and includes mapping of visual rendering elements to the [Logical Data Model](#logical-model).

|DPCC Version|Date|status|change log|JSON-LD Context|JSON Schema|
|--|--|--|--|--|--|
|0.3.0|01-07-2024|Raw |rebuilt on untp-core vocabulary| DPP context - TBA |DPP schema - TBA |
|0.3.10|28-08-2024|Draft| Resolved issues, aligned with untp core, ready for pilot testing|[context](https://test.uncefact.org/vocabulary/untp/dcc/0/untp-dcc-context-0.3.10.jsonld)|[schema](https://test.uncefact.org/vocabulary/untp/dcc/0/untp-dcc-schema-0.3.10.json)


## Overview
Expand Down Expand Up @@ -52,18 +70,18 @@ The Digital Conformity Credential is an assembly of re-usable components from th

### Core Vocabulary

The [UNTP core types vocabulary](https://jargon.sh/user/unece/untp-core/v/0.3.10/artefacts/readme/render) defines the uniquely identified Linked Data entities such as Product, Location, Facility, Party, Standard, Regulation, Criteria, Declaration, Attestation, Endorsement. These entities provide the building blocks for construction of Digital Product Passports and Digital Conformity Credentials.
The [UNTP core types vocabulary](https://jargon.sh/user/unece/untp-core/v/0.4.1/artefacts/readme/render) defines the uniquely identified Linked Data entities such as Product, Location, Facility, Party, Standard, Regulation, Criteria, Declaration, Attestation, Endorsement. These entities provide the building blocks for construction of Digital Product Passports and Digital Conformity Credentials.

### DCC Documentation

[DCC class & property definitions](https://jargon.sh/user/unece/ConformityCredential/v/0.3.10/artefacts/readme/render)
The [DCC class & property definitions](https://jargon.sh/user/unece/ConformityCredential/v/0.4.1/artefacts/readme/render) provide a technology-neutral definition of classes, properties and code lists in the DCC model.

## Implementation Guidance


### Verifiable Credential

Please refer to [DPP VC Guidance](DigitalProductPassport.md#verifiable-credential)
Digital Conformity Credentials are issued as Vierifiable credentials. Please refer to [DPP VC Guidance](DigitalProductPassport.md#verifiable-credential) for information about the use of the verifiaible credentials data model for UNTP.

### Conformity Attestation

Expand All @@ -73,11 +91,11 @@ The `ConformityAttestation` type is the root content of the `credentialSubject`
* the `id` MUST be a globally unique identifier (URI) for the attestation. Typically a certificate number with the CAB web domain as a prefix. `name` should contain a human readable text string that describes the attestation.
* `assessorLevel` (how assured is the party doing the assessment?), `assessmentLevel` (how assured is the subject product/facility being assessed?) and `attestationType` (is this a test report, a certificate, or some other type?) are coded values that help to classify the type and integrity of the attestation.
* `issueToParty` identifies the entity to who the conformity attestation is issued - usually the product manufacturer or facility operator.
* `authorisations` describes a list of accreditations that a competent authority (such as a government agency or a national accreditation authority or a trusted global standards body) has issued to the conformity assessment body that is issuing this attestation. It provides trust that the certifier is properly accredited to issue certificates.
* `authorisation` describes a list of accreditations that a competent authority (such as a government agency or a national accreditation authority or a trusted global standards body) has issued to the conformity assessment body that is issuing this attestation. It provides trust that the certifier is properly accredited to issue certificates.
* `conformityCertfificate` is a secure link to the full version (eg a PDF document) of this attestation.
* `auditableEvidence` is a secure link to an unstructured collection of files which provided the original evidence basis for the conformity assessments made by this DCC. The evidence files are usually commercially sensitive and encrypted but are an important information source for audits.
* `scope` defines the conformity scheme under which this attestation is issued. A scheme is a high level framework describing the context for the entire attestation. Each individual assessment included in this attestation will usually reference more fine grained criteria within any standards or regulations that are part of the scheme.
* `assessments` is an array of detailed conformity assessments made about an identified product or facility - against a specific criteria contained in a standard or regulation.
* `assessment` is an array of detailed conformity assessments made about an identified product or facility - against a specific criteria contained in a standard or regulation.


```json
Expand All @@ -90,11 +108,11 @@ The `ConformityAttestation` type is the root content of the `credentialSubject`
"attestationType": "certification",
"attestationDescription": "Assessment of battery products against the GHG Protocol.",
"issuedToParty": {..},
"authorisations": [{..}],
"authorisation": [{..}],
"conformityCertificate": {..},
"auditableEvidence": {..},
"scope": {..},
"assessments": [{..},{..}]
"assessment": [{..},{..}]
}
```

Expand All @@ -112,7 +130,7 @@ It should be noted that this `authorisations` structure is part of the attestati


```json
"authorisations": [
"authorisation": [
{
"type": [
"Endorsement"
Expand Down Expand Up @@ -217,6 +235,94 @@ The `conformityCertificate` and `auditableEvidence` objects are both the same `S

### Conformity Assessments

One conformity credential may include many assessments. Each assessment includes
* subjects of the assessment (ie what was assessed) which may reference one or more products, facilites, or organisaitons. For example a 300Ah Lithium battery.
* a reference standard and/or regulation against which the assessment was made. For example the global battery alliance rulebook.
* one or more specific critieria within the referenced standard or regulation which may include benchmark or threshold values. For example the industry bechmakr carbon intensity of lithium batteries
* one or more actual declared values. For example the actual carbon intensity of the assessed battery.
* an indicator of compliance against the regulation or standard. For example, the battery is compliant with the GBA rulebook.
* the ID and name of the auditor if different to the issuer of the conformity credential.

```json
"assessment": [
{
"type": [
"ConformityAssessment",
"Declaration"
],
"assessmentDate": "2024-03-15",
"id": "https://exampleCAB.com/38f73303-a39e-45a7-b8b7-e73517548f27/01",
"referenceStandard": {
"type": [
"Standard"
],
"id": "https://www.globalbattery.org/media/publications/gba-rulebook-v2.0-master.pdf",
"name": "GBA Battery Passport Greenhouse Gas Rulebook - V.2.0",
"issuingParty": {...},
"issueDate": "2023-12-05"
},
"referenceRegulation": {...},
"assessmentCriteria": [
{
"type": [
"Criterion"
],
"id": "https://www.globalbattery.org/media/publications/gba-rulebook-v2.0-master.pdf#BatteryAssembly",
"name": "GBA Battery rule book v2.0 battery assembly guidelines.",
"thresholdValues": [
{
"metricName": "GHG emissions intensity",
"metricValue": {
"value": 10,
"unit": "KGM"
},
"score": "BB",
"accuracy": 0.05
}
]
}
],
"declaredValue": [
{
"metricName": "GHG emissions intensity",
"metricValue": {
"value": 10,
"unit": "KGM"
},
"score": "BB",
"accuracy": 0.05
}
],
"compliance": true,
"conformityTopic": "environment.emissions",
"assessedProduct": [
{
"type": [
"Product"
],
"id": "https://id.gs1.org/01/09520123456788/21/12345",
"name": "EV battery 300Ah.",
"registeredId": "09520123456788.21.12345",
"idScheme": {
"type": [
"IdentifierScheme"
],
"id": "https://id.gs1.org/01/",
"name": "Global Trade Identification Number (GTIN)"
},
"serialNumber": "12345678",
"batchNumber": "6789",
"IDverifiedByCAB": true
}
],
"assessedFacility": [...],
"assessedOrganisation": {...},
"auditor": {...}
}
]
}
```

Conformity assessments are included in the DCC as an array of UNTP `Declaration` structures. The same structure is re-used for third party assessments in UNTP Digital Product Passport (DPP). Please refer to the [declarations structure](SustainabilityVocabularyCatalog.md#declarations-structure) for further information and examples.

To help understand the difference between a `Scheme` that defines the scope of the overall attestation and the `Criterion` that defines the rules for a specific conformity assessment, an example can help.
Expand All @@ -226,3 +332,4 @@ To help understand the difference between a `Scheme` that defines the scope of t

## Sample


2 changes: 1 addition & 1 deletion website/docs/specification/ConformityCredential.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 1 addition & 1 deletion website/docs/specification/DgitialFacilityRecord.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
144 changes: 131 additions & 13 deletions website/docs/specification/DigitalFacilityRecord.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,16 +7,34 @@ import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

* **[Latest JSON-LD @context](https://test.uncefact.org/vocabulary/untp/dfr/0/untp-dfr-context-0.3.10.jsonld)**
* **[Latest JSON schema](https://test.uncefact.org/vocabulary/untp/dfr/0/untp-dfr-schema-0.3.10.json)**
* **[Sample instance](../../samples/untp-digital-facility-record-v0.3.10.json)**
## Artifacts

## Versions
Are maintained at https://test.uncefact.org/vocabulary/untp/dfr/0/about

| DFR Version | Date | status | Change summary | JSON-LD Context | JSON Schema |
| ------ | ----- | ------ | ------ | ------| ---|
| 0.3.10 | 28-08-2024 | Draft |Initial model for facility data |[@context](https://test.uncefact.org/vocabulary/untp/dfr/0/untp-dfr-context-0.3.10.jsonld) |[schema](https://test.uncefact.org/vocabulary/untp/dfr/0/untp-dfr-schema-0.3.10.json) |
### Stable Releases For Implementation

Version 1.0 stable release for production implementation is due Jan 2025

### Release for Pilot Testing

Version 0.4.1 release artifacts can be used for pilot testing.

* [JSON-LD @context](https://test.uncefact.org/vocabulary/untp/dfr/0.4.1/)
* [JSON Schema](https://test.uncefact.org/vocabulary/untp/dfr/untp-dfr-schema-0.4.1.json)
* [Sample Instance](https://test.uncefact.org/vocabulary/untp/dfr/untp-dfr-instance-0.4.1.json)

### Latest Development Version

Latest development versions are used to reflect lessons learned from pilots but should not be used for either pilot testing or production purposes.

### Version History

History of releases is available from the **[Version history](https://test.uncefact.org/vocabulary/untp/dfr/0/versions)** page.


### Visualization

A UNTP digital traceability event may be rendered in any format desired by the issuer. However a default **[Visualization](../../samples/DigitalFacilityRecordRender.png)** is provided here and includes mapping of visual rendering elements to the [Logical Data Model](#logical-model).


## Overview
Expand Down Expand Up @@ -51,25 +69,125 @@ The Digital Facility Record is an assembly of re-usable components from the UNTP

### Core Vocabulary Documentation

The [UNTP core types vocabulary](https://jargon.sh/user/unece/untp-core/v/0.3.10/artefacts/readme/render) defines the uniquely identified Linked Data entities such as Product, Location, Facility, Party, Standard, Regulation, Criteria, Declaration, Attestation, Endorsement. These entities provide the building blocks for construction of the Digital Facility Record.
The [UNTP core types vocabulary](https://jargon.sh/user/unece/untp-core/v/0.4.1/artefacts/readme/render) defines the uniquely identified Linked Data entities such as Product, Location, Facility, Party, Standard, Regulation, Criteria, Declaration, Attestation, Endorsement. These entities provide the building blocks for construction of the Digital Facility Record.


### DFR Documentation

The [DFR documentation](https://jargon.sh/user/unece/DigitalFacilityRecord/v/0.3.10) provides a technology-neutral definition of classes, properties and code lists in the DFR model.
The [DFR documentation](https://jargon.sh/user/unece/DigitalFacilityRecord/v/0.4.1) provides a technology-neutral definition of classes, properties and code lists in the DFR model.

## Implementation Guidance

This section provides sample JSON-LD snippets for each DFR component.
This section provides sample JSON-LD snippets for each DFR component with guidance on their purpose and usage.

### Verifiable Credential

TBA
Digital Facility Records are issued as Vierifiable credentials. Please refer to [DPP VC Guidance](DigitalProductPassport.md#verifiable-credential) for information about the use of the verifiaible credentials data model for UNTP. THe issuing party for the VC should be the facility owner or operator.

### Facility

TBA
The facility object is the `credentialSubject`. It comprises

* An identifier for the facility. This could be a self-issued DID, or an ID managed by an industry association such as a member / facility register, or a global location scheme such as a GS1 GLN. Whatever the facility identifier scheme, facility IDs should be resolvable and verifiable.
* An industry process category, preferably using a global standard classificaiton scheme such as UN ISIC.
* The `operatedByParty` for the facility, typically identified using a national business register or a glbal business identifier scheme.
* The semi-strucutred address for the facility.
* The geolocation information for the facility (using PlusCodes adn GeoJSON - see below)
* The confirmity claims about the facility made by the facility owner or operator - following the same `Declaratoion` structure as used by the UNTP Digital Product Passport.

```json
"credentialSubject": {
"type": [
"Facility"
],
"id": "https://samplefacilityregister.org/1234567",
"registeredId": "1234567",
"description": "LiFePO4 Battery plant number 7",
"name": "Example facility 7",
"idScheme": {
"type": [
"IdentifierScheme"
],
"id": "https://samplefacilityregister.org",
"name": "A facility register"
},
"countryOfOperation": "AU",
"processCategory": [
{
"type": [
"Classification"
],
"id": "https://unstats.un.org/unsd/classifications/Econ/isic/2611",
"code": "2611",
"name": "Manufacture of solar cells, solar panels and photovol",
"schemeID": "https://unstats.un.org/unsd/classifications/Econ/isic",
"schemeName": "UN Standard Industry Classification"
},
{...}
],
"operatedByParty": {
"type": [
"Identifier"
],
"id": "https://abr.business.gov.au/ABN/View?abn=90664869327",
"name": "Sample Company Pty Ltd.",
"registeredId": "90664869327",
"idScheme": {
"type": [
"IdentifierScheme"
],
"id": "https://abr.business.gov.au",
"name": "Australian Business Number"
}
},
"otherIdentifier": [..],
"address": {
"streetAddress": "level 11, 15 London Circuit",
"postalCode": "2601",
"addressLocality": "Acton",
"addressRegion": "ACT",
"addressCountry": "AU"
},
"locationInformation": {..},
"conformityClaims": [..]
}
}
```

### Location

TBA
Facility location is a value object (ie it does not have a unique identifier). It's purpose it to locate the facility in a geographic area with whatever degree of resolution required. A location object must include at leaqst one of the following geolocation properties:

* An open location code (also know as [Plus Codes](https://maps.google.com/pluscodes/)). Plus codes are essentially a grid reference and can define an small area that is virtually a pin location (eg https://plus.codes/8CGRC78W+MM) or a much larger area (eg Roughly Madrid city - https://plus.codes/8CGRC700+) by removing digits after the "+" and replacing grid digits with an even number of trailing zeros.
* A geoLocation as a [GeoJSON Point](https://datatracker.ietf.org/doc/html/rfc7946#appendix-A.1) as a decimal lattitude / longditude pair.
* A geoBoundary as a [GeoJSON Polygon](https://datatracker.ietf.org/doc/html/rfc7946#appendix-A.3) that defines any closed boundary (or collection of closed boundaries) as a sequence of lat/long pairs where the first and last pair represent the same point.

```json

"locationInformation": {
"plusCode": "https://plus.codes/8CGRC78W+MM",
"geoLocation": {
"type": "Point",
"coordinates":[
40.416688,
-3.703313,
]
},
"geoBoundary": {
"type": "Polygon",
"coordinates": [
[100.0, 0.0],
[101.0, 0.0],
[101.0, 1.0],
[100.0, 1.0],
[100.0, 0.0]
]
}
```

### Confomrity Claims

Conformity information is included in the Digital Facility Record as an array of UNTP Declaration structures. The same structure is re-used for confomrity Information in Digital Product Passports nad for third party assessments in UNTP Digital Conformity Credentials (DCC). Please refer to the [Sustainability Vocabulary Page](SustainabilityVocabularyCatalog.md) for further information and examples.

## Samples

2 changes: 1 addition & 1 deletion website/docs/specification/DigitalFacilityRecord.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading

0 comments on commit 02e46fc

Please sign in to comment.