imde.io - User contributions [en]

Material Platform - TX

2026-11-01T10:52:45Z

HansdG: HansdG moved page Material Platform - TX to Material System - TX: Term was already in use in Fashion Industry

#REDIRECT [[Material System - TX]]

Material System - TX

2026-11-01T10:52:45Z

HansdG: HansdG moved page Material Platform - TX to Material System - TX: Term was already in use in Fashion Industry

'''Material System''': a material or material construction that a supplier uses across a range of packaging components, and that carries one compliance profile. A Material System is often known in the market by a brand, range or technology name.

''This concept was first published as Material Platform. It was renamed because "material platform" is already an established term in fashion and apparel.''

== Full definition ==
* A Material System is the material base that packaging components are built on. It can be a single material or a construction of several: layers, coatings, print, technologies. Examples: a specific PET resin, a glass furnace profile, a board with a defined ink system, a laminate of up to seven layers, a coating for beverage cans.
* A Material System with only one material is still a Material System. "System" refers to the compliance boundary, not to the number of materials.
* Compliance is a property of the Material System, not of the individual packaging component. One furnace, one compliance profile. One resin, one compliance profile. Compliance questions arrive at component level, which is the wrong granularity.
* Material Systems already exist commercially and usually already have names, because suppliers market them as products (for example PrintKote, Stretotheen, Optilayer, Nitro Cans). Use the name the industry already uses.

== Prove without revealing ==
Everyone wants transparency, but nobody wants to be transparent. The Material System resolves this.
* The supplier shares the compliance profile of the Material System, not its composition.
* Example: a beverage can coating marketed as X73. The supplier is willing to share the PPWR compliance profile of X73, but not its exact material composition.
* Conformity is proven at Material System level. The recipe stays with the supplier.

== Identity ==
* One Material System ID
* One compliance data set
* One stable Digital Link resolving to it (GS1 Digital Link, ISO/IEC 18975)

== When is it a new Material System ==
* '''New Material System:''' a change in material construction, coating or ink system that changes the compliance profile.
* '''Same Material System:''' a change in format, dimension, cutter guide or print image.

== Position in the model ==
* '''Material System:''' material level. One compliance profile per material construction.
* '''Packaging Master:''' groups packaging components that share material composition, ink or coating system and geometry. A Packaging Master is built on one or more Material Systems.
* '''Packaging System:''' a unique combination of Packaging Masters. One dossier per Packaging System.

== What it is not ==
* Not a materials database.
* Not a raw material specification.
* Not a disclosure of composition.

== Example: the leverage ==
300 customers each order 30 printed boxes: 9,000 items and potentially 9,000 compliance questions. They all share the same board, ink system and compliance profile. Do not assess compliance 9,000 times. Assess the Material System once.

[[Category:Taxonomy]]

Material System - TX

2026-11-01T10:52:14Z

HansdG:

Packaging Digital Link - DT

2026-10-21T07:26:23Z

HansdG: /* Packaging dossier content */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-3YJHUG2A</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-3YJHUG2A</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/index.php?title=DataContainer_-_PackagingSystem</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema ([[DataContainer_-_PackagingSystem|Packaging System Datacontainer]]. It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-19T06:29:23Z

HansdG: /* imde:packagingInfo */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-3YJHUG2A</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-3YJHUG2A</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/index.php?title=DataContainer_-_PackagingSystem</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:06:43Z

HansdG: /* Identifier and link syntax */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-3YJHUG2A</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-3YJHUG2A</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:06:13Z

HansdG: /* Start from a GTIN */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-3YJHUG2A</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:06:03Z

HansdG: /* Request all links */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-3YJHUG2A</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:05:49Z

HansdG: /* Concepts */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-3YJHUG2A</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:05:26Z

HansdG: /* Request one link type */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-3YJHUG2A.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:04:55Z

HansdG: /* Request all links */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-3YJHUG2A.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:04:35Z

HansdG: /* Request one link type */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:04:07Z

HansdG: /* Identifier and link syntax */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:03:48Z

HansdG: /* Identifier and link syntax */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: <code>https://prodigi.link/31B/VTA-MPLA-PS-3YJHUG2A</code>

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T12:02:37Z

HansdG: /* Concepts */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigilink.com Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: <code>https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA</code>

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Category:Data Transport

2026-10-14T11:48:22Z

HansdG: Created blank page

Layer - Data Transport

2026-10-14T11:47:45Z

HansdG: /* Data Transport Technologies */

==What is the purpose of the Data Transport layer?==
The Data Transport layer makes it possible to design and control the flow of data between systems. Data Exchange can be internally or between parties in the value network. The industry currently recognizes three distinct models: federated, centralized, and hybrid.

===Federated Data Exchange===
Federated is a decentralized approach that emphasizes partial, controlled sharing among autonomous databases. Components (systems) of a federated architecture represent the various systems/machines. Each system controls its interactions with others by means with the support of Data Formats. The federated architecture provides a means to share data and transactions using messaging services, combining information from several components, and providing the coordination of data exchange among autonomous components.

[https://synf.co/dataportsintro DataPorts] is an example of Federated Data Exchange, where machines exchange data (push & pull) using IoT technologies.

===Centralized Data Exchange===
Centralized architecture emphasizes full control over data sharing through a centralized repository. Components in a centralized architecture refer to the central data repository. The repository authenticates the requester, authorizes the transaction, and records it for audit and reporting purposes.

DataPools like GS1-GDSN, EZBase, 2BA, InstallData and PS in Foodservice are based on centralized data exchange.

==Hybrid Data Exchange==
Hybrid is a combination of the two architecture types used to achieve the actual exchange of clinical data. For instance, trade conditions may occur through the use of a federated model, while public product data is shared through a centralized database.

==Data Transport Technologies==
* RestAPI
* SOAP API
* DataPorts (IOT based)
* Digital Links (based on GS1/ISO standards)
** [[Packaging_Digital_Link_-_DT|Packaging Digital Link]]
* FTP/sFTP/FTPs
* AS2
* Email
* Fileshare solutions like: Dropbox, Box.com and Sharepoint

[[Category:Layers]]

Packaging Digital Link - DT

2026-10-14T11:45:26Z

HansdG:

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. Any resolver that conforms to the GS1 Digital Link standard and ISO/IEC 18975 and meets the [[#Resolver requirements|resolver requirements]] can serve Packaging Digital Links, for example [https://prodigi.link Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver domain}/31B/{Packaging System identifier}
</pre>

Example with the resolver Prodigi.link: <code>https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA</code>

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://{resolver domain}</code>, for example <code>https://prodigi.link</code> || Domain of any conformant resolver
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolver requirements ==
A resolver that serves Packaging Digital Links must:
* Conform to the GS1 Digital Link standard and ISO/IEC 18975.
* Accept ANSI MH10.8.2 Data Identifiers (such as <code>31B</code>) as path segments, next to GS1 Application Identifiers (such as <code>01</code>).
* Recognise the <code>imde:</code> namespace (<code>https://imde.io/voc/</code>), so that <code>linkType=imde:packagingInfo</code> and the full URI are treated as the same link type.
* Return linksets as <code>application/linkset+json</code> (RFC 9264), with link types written as full URIs.
* Redirect with HTTP 307 to the target of the requested link type, and fall back to the default link for a request without a link type or with an unknown one.

== Resolving a Packaging Digital Link ==
The examples below use Prodigi.link as the resolver. With another conformant resolver, only the domain changes.

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Transport|Data Transport]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Transport]]

Packaging Digital Link - DT

2026-10-14T11:43:57Z

HansdG: /* Identifier and link syntax */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. For the Packaging Digital Link this is [https://prodigi.link Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver.ext}/31B/{Packaging System identifier}
</pre>

Example: <code>https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA</code>

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://prodigi.link</code> || Resolver domain
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolving a Packaging Digital Link ==

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Exchange|Data Exchange]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Exchange]]

Packaging Digital Link - DT

2026-10-14T11:43:42Z

HansdG: /* Identifier and link syntax */

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. For the Packaging Digital Link this is [https://prodigi.link Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://{resolver.url}/31B/{Packaging System identifier}
</pre>

Example: <code>https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA</code>

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://prodigi.link</code> || Resolver domain
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolving a Packaging Digital Link ==

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Exchange|Data Exchange]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Exchange]]

Packaging Digital Link - DT

2026-10-14T11:41:24Z

HansdG: Created page with "The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container. __TOC__ == Purpose == One Packaging System is often used by many sales units and transport units. In private label, these units are placed..."

The '''Packaging Digital Link''' is a web link that identifies one Packaging System and gives access to its packaging dossier: the EU Declarations of Conformity, the technical documentation and the packaging composition. It is built on ISO/IEC, ANSI and GS1 standards, and its content follows the IMDE Packaging System data container.

__TOC__

== Purpose ==
One Packaging System is often used by many sales units and transport units. In private label, these units are placed on the market by different Manufacturers, each of whom signs an EU Declaration of Conformity under the PPWR. The technical knowledge of the packaging, however, sits with the party that fills it.

The Packaging Digital Link separates the dossier from the signature:
* The party that knows the packaging keeps '''one dossier per Packaging System'''.
* Every party that needs the dossier stores '''one link''' instead of a copy of the files.
* A change is published once, at the link. All sales units and transport units that run on the Packaging System refer to the same, current dossier.

== Concepts ==
{| class="wikitable"
! Term !! Definition
|-
| Packaging System || A unique combination of packaging components that together form the packaging of an item, from sales packaging up to transport packaging. One Packaging System has one dossier.
|-
| Packaging System identifier || A unique, opaque identifier for one Packaging System, for example <code>VTA-MPLA-PS-2YJNU8QA</code>. It carries no meaning and never changes.
|-
| Sales unit, transport unit || Trade items identified by a GTIN that run on a Packaging System. One Packaging System is linked to 1..N sales units and transport units.
|-
| Packaging dossier || The information served at the link: EU Declarations of Conformity, technical documentation and packaging composition.
|-
| Resolver || The web service that receives a request for a link and returns the right target. For the Packaging Digital Link this is [https://prodigi.link Prodigi.link].
|}

== Identifier and link syntax ==
A Packaging Digital Link is an HTTPS URI with this pattern:

<pre>
https://prodigi.link/31B/{Packaging System identifier}
</pre>

Example: <code>https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA</code>

{| class="wikitable"
! Part !! Value !! Standard
|-
| Scheme and host || <code>https://prodigi.link</code> || Resolver domain
|-
| Data Identifier || <code>31B</code> || ANSI MH10.8.2 Data Identifier, used here for the Packaging System
|-
| Identifier value || <code>VTA-MPLA-PS-2YJNU8QA</code> || Unique Packaging System identifier
|-
| URI structure || Data Identifier and value as path segments || ISO/IEC 18975 (encoding of identifiers on the web)
|-
| Data carrier || QR code containing the URI || ISO/IEC 18004
|}

The QR code can be opened by any scanner, browser or system. No proprietary app is needed.

=== Relation to GS1 Digital Link ===
The Packaging Digital Link does not replace the GS1 Digital Link of a trade item. The two are linked:
* The GS1 Digital Link of a sales unit or transport unit (<code>/01/{GTIN}</code>) can carry a link of type <code>imde:packagingInfo</code> that points to the Packaging Digital Link of the Packaging System it runs on.
* A GTIN that runs on more than one Packaging System carries one such link per Packaging System.

== Link types ==
The resolver serves information through link types. Conformant resolvers recognise all link types in the <code>gs1:</code> namespace and may add their own namespaces. The Packaging Digital Link uses the IMDE namespace <code>imde:</code> = <code>https://imde.io/voc/</code> next to the GS1 Web Vocabulary.

{| class="wikitable"
! Link type !! Full URI !! Target
|-
| <code>imde:packagingInfo</code> || <code>https://imde.io/voc/packagingInfo</code> || The packaging dossier as JSON (IMDE Packaging System data container)
|-
| <code>gs1:defaultLink</code> || <code>https://gs1.org/voc/defaultLink</code> || A human-readable page of the Packaging System, if available
|-
| <code>linkset</code> || not applicable || The full set of links for the identifier (RFC 9264)
|}

=== imde:packagingInfo ===
{| class="wikitable"
! Property !! Value
|-
| URI || <code>https://imde.io/voc/packagingInfo</code>
|-
| Label || Packaging information
|-
| Definition || A link to structured, machine-readable information about the Packaging System of an item: the EU Declarations of Conformity, the technical documentation with its evidence files, and the packaging composition (packaging elements, materials and composite materials with their form-related and material-related attributes, such as recycled content). Intended for business-to-business use in PPWR compliance and EPR reporting.
|-
| Target media type || <code>application/json</code>
|-
| Target profile || <code>https://imde.io/schema/packaging-system</code>
|-
| Can start from || A Packaging System identifier (<code>/31B/</code>) or a GTIN (<code>/01/</code>)
|-
| Machine-readable definition || [https://imde.io/voc/packagingInfo https://imde.io/voc/packagingInfo] (HTML, or JSON-LD with <code>Accept: application/ld+json</code>)
|}

Related GS1 link types and when to use them instead:
* <code>gs1:sustainabilityInfo</code> for consumer-facing sorting and recycling information.
* <code>gs1:masterData</code> for general product master data.
* <code>gs1:certificationInfo</code> for a single certificate.

The compact form <code>imde:packagingInfo</code> is used in the <code>linkType</code> query parameter. In linksets and HTTP headers the full URI is used. If GS1 publishes an equivalent link type, <code>imde:packagingInfo</code> will be declared equivalent to it and will keep resolving.

== Resolving a Packaging Digital Link ==

=== Request one link type ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json
</pre>

=== Request all links ===
<pre>
GET https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=linkset
Accept: application/linkset+json
</pre>

<pre>
{
"linkset": [{
"anchor": "https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA",
"https://imde.io/voc/packagingInfo": [{
"href": "https://{dossier host}/packaging-system/VTA-MPLA-PS-2YJNU8QA.json",
"type": "application/json",
"profile": "https://imde.io/schema/packaging-system",
"title": "Packaging System dossier"
}]
}]
}
</pre>

=== Start from a GTIN ===
<pre>
GET https://prodigi.link/01/{GTIN}?linkType=imde:packagingInfo

HTTP/1.1 307 Temporary Redirect
Location: https://prodigi.link/31B/VTA-MPLA-PS-2YJNU8QA?linkType=imde:packagingInfo
</pre>

The GTIN link points to the Packaging Digital Link, not to the dossier file. When the dossier moves, only the link of the Packaging System changes.

=== Behaviour of a request without a link type ===
* A browser, or any request without <code>linkType</code>, is redirected to the default link.
* An unknown link type falls back to the default link.

== Packaging dossier content ==
The target of <code>imde:packagingInfo</code> is one JSON document that follows the IMDE '''Packaging System data container''', an open, published JSON Schema (<code>https://imde.io/schema/packaging-system</code>). It describes a Packaging System and its dossier in the same way for every party.

{| class="wikitable"
! Data topic !! Content
|-
| EU Declaration of Conformity || One declaration per Manufacturer, for the Packaging System and the sales units and transport units that run on it.
|-
| Technical documentation || The proof of conformity, with its evidence files, such as test reports, supplier declarations and calculations.
|-
| Packaging composition || Packaging elements, materials and composite materials, with form-related attributes (such as packaging type, dimensions and weight) and material-related attributes (such as material type and recycled content). Used for PPWR compliance and for EPR reporting and fee modulation.
|}

Packaging is described with the PPWR packaging categories: sales packaging, grouped packaging, transport packaging and e-commerce packaging. Identifiers and code list values always state first which identifier type or code list is used, then the value.

== Change management ==
* The Packaging Digital Link never changes. The dossier behind it is updated.
* A change to a Packaging System, such as a new coating or a new requirement under a delegated act, is published once at the link.
* Each party that stores the link sees which of its sales units and transport units the change affects, and can check and accept it in its own system.

== Position in the IMDE framework ==
{| class="wikitable"
! IMDE layer !! Role in the Packaging Digital Link
|-
| [[Layer - Identifiers|Identifiers]] || Packaging System identifier with ANSI Data Identifier 31B; GTIN for sales units and transport units
|-
| [[Layer - Code Lists|Code Lists]] || IMDE code lists for packaging type, material and other attributes in the dossier
|-
| [[Layer - Data Schema|Data Schema]] || Packaging System data container (JSON Schema)
|-
| [[Layer - Data Exchange|Data Exchange]] || Digital Link resolution with link type <code>imde:packagingInfo</code>
|}

== Standards and references ==
* ISO/IEC 18975: encoding and resolving identifiers over HTTP
* ISO/IEC 18004: QR code bar code symbology
* ANSI MH10.8.2: Data Identifier and Application Identifier Standard (Data Identifier 31B)
* [https://ref.gs1.org/standards/digital-link/ GS1 Digital Link standard] and [https://ref.gs1.org/voc/ GS1 Web Vocabulary]
* RFC 9264: Linkset, media types and a link relation type for link sets
* Regulation (EU) 2025/40 on packaging and packaging waste (PPWR)
* [https://imde.io/voc/packagingInfo imde:packagingInfo] link type definition
* [https://imde.io/schema/packaging-system IMDE Packaging System data container] (JSON Schema)

[[Category:Layers]]
[[Category:Data Exchange]]

Main Page

2026-10-14T11:40:37Z

HansdG:

==What is IMDE?==
Interoperable Modular Data Exchange (IMDE) is a framework that will enable machine-2-machine exchange of data across the entire value network. Minimizing the cost for collecting, using and distributing data. IMDE can overcome a number of the challenges faced by organizations, [[Solution_Providers|solution providers]] and data processors like [[DataPools_and_Data_Networks|datapools]] in terms of improving simplification of data exchange while at the same time improving data quality (consistency, relevance, completeness, accuracy and timeliness). The biggest benefits are in exchanging data with both upstream and downstream business partners. The beneficiaries are machines!, so not humans. The whole framework is designed for fully autonomous communication between machines.

==Why Interoperable and Modular?==
Many of the initiatives in the past focussed on creating standards for specific use cases, or in specific industries. These standards often covered all six layers of data exchange:

{| class="wikitable" style="width: 100%;"
|+ IMDE - 6 Layer Framework for Interoperable Modular Data Exchange

|-
! style="color:white; background-color:#273247; border:solid 1px white; padding: 10px; vertical-align:top;" | L1
| style="color:#273247; background-color:#39b8bb; border:solid 1px white; padding: 10px; font-weight:bold; vertical-align:top;" | TX
| style="color:#273247; background-color:#97dbdd; border:solid 1px white; padding: 10px; width: 200px; text-align:left; font-weight:bold; vertical-align:top;" | Taxonomy
| style="color:#273247; background-color:#f3f3f3; border:solid 1px white; padding: 10px; font-weight:normal; text-align:left; vertical-align:top;" | Establishes a unified communication language to ensure consistent terminology and understanding across different systems and platforms.
| style="color:white; background-color:white; border:solid 1px white; padding: 10px; vertical-align:top;" | [[ :Category:Taxonomy| Link]]
|-
! style="color:white; background-color:#273247; border:solid 1px white; padding: 10px; vertical-align:top;" | L2
| style="color:#273247; background-color:#39b8bb; border:solid 1px white; padding: 10px; font-weight:bold; vertical-align:top;" | IM
| style="color:#273247; background-color:#97dbdd; border:solid 1px white; padding: 10px; width: 200px; text-align:left; font-weight:bold; vertical-align:top;" | Information Model
| style="color:#273247; background-color:#f3f3f3; border:solid 1px white; padding: 10px; font-weight:normal; text-align:left; vertical-align:top;" |Information model is a technology neutral, structured representation of the real world in a given domain, defining the key concepts, their properties, relationships, and rules in a consistent way.
| style="color:white; background-color:white; border:solid 1px white; padding: 10px; vertical-align:top;"| [[ :Category:Information_Model| Link]]
|-
! style="color:white; background-color:#273247; border:solid 1px white; padding: 10px; vertical-align:top;" |L3
| style="color:#273247; background-color:#39b8bb; border:solid 1px white; padding: 10px; font-weight:bold; vertical-align:top;" | ID
| style="color:#273247; background-color:#97dbdd; border:solid 1px white; padding: 10px; width: 200px; text-align:left; font-weight:bold; vertical-align:top;" | Identifiers
| style="color:#273247; background-color:#f3f3f3; border:solid 1px white; padding: 10px; font-weight:normal; text-align:left; vertical-align:top;" | Supports various standards for uniquely identifying entities such as locations, products, brands and organizations.
| style="color:white; background-color:white; border:solid 1px white; padding: 10px; vertical-align:top;" | [[ID_-_Identifier_Types|Link]]
|-
! style="color:white; background-color:#273247; border:solid 1px white; padding: 10px; vertical-align:top;" | L4
| style="color:#273247; background-color:#39b8bb; border:solid 1px white; padding: 10px; font-weight:bold; vertical-align:top;" | CL
| style="color:#273247; background-color:#97dbdd; border:solid 1px white; padding: 10px; width: 200px; text-align:left; font-weight:bold; vertical-align:top;" | Code Lists
| style="color:#273247; background-color:#f3f3f3; border:solid 1px white; padding: 10px; font-weight:normal; text-align:left; vertical-align:top;" | Standardizes sets of codes used to represent specific data elements, ensuring consistency and interoperability across different datasets and platforms. Example: Unit of Measure
| style="color:white; background-color:white; border:solid 1px white; padding: 10px; vertical-align:top;" | [[ :Category:Code_List| Link]]
|-
! style="color:white; background-color:#273247; border:solid 1px white; padding: 10px; vertical-align:top;" |L5
| style="color:#273247; background-color:#39b8bb; border:solid 1px white; padding: 10px; font-weight:bold; vertical-align:top;" | DS
| style="color:#273247; background-color:#97dbdd; border:solid 1px white; padding: 10px; width: 200px; text-align:left; font-weight:bold; vertical-align:top;" | Data Schema
| style="color:#273247; background-color:#f3f3f3; border:solid 1px white; padding: 10px; font-weight:normal; text-align:left; vertical-align:top;" | Accommodates multiple data formatting standards in formats like JSON, XML, or spreadsheet templates, with clear declarations for each data container to facilitate seamless data exchange.
| style="color:white; background-color:white; border:solid 1px white; padding: 10px; vertical-align:top;" | [[Layer_-_Data_Schema|Link]]
|-
! style="color:white; background-color:#273247; border:solid 1px white; padding: 10px; vertical-align:top;" | L6
| style="color:#273247; background-color:#39b8bb; border:solid 1px white; padding: 10px; font-weight:bold; vertical-align:top;" | DT
| style="color:#273247; background-color:#97dbdd; border:solid 1px white; padding: 10px; width: 200px; text-align:left; font-weight:bold; vertical-align:top;" | Data Transport
| style="color:#273247; background-color:#f3f3f3; border:solid 1px white; padding: 10px; font-weight:normal; text-align:left; vertical-align:top;" | Defines the protocols and methods for securely and efficiently transferring data between systems, ensuring compatibility and effective communication across diverse platforms.
| style="color:white; background-color:white; border:solid 1px white; padding: 10px; vertical-align:top;" |[[Layer_-_Data Transport|Link]]
|}

The challenge in this approach is that the world is big, so there are many standards, for different territories, industries and use cases. Which has resulted in the fact that data exchange is still a technical and organizational nightmare. Example: A Food manufacturer sourcing raw materials and components from multiple suppliers and selling both A-Brand and Private Label products can be dealing with dozens of different ways to exchange origin and allergen data. While the type of data is 100% the same in all situations: Allergens information has the same data points for raw materials, production materials, semifinished goods and finished goods, and allergen data is not different for A-Brands or Private label brands. But still, from a technical standpoint, organizations need to deal with many ways to export or import allergen related data.

The solution is to move away from all-in-one standards, where all standards had the strategy to become THE standard. And where every standard covers all 6 layers: the dictionary, the information model, the message structure, the exchange technology, the [[ID_-_Identifier_Types|identifiers]] and the code lists. This new approach is based on the idea of allowing modular standards with independent solutions for all 6 layers. Also supporting/allowing multiple standard per layer. For example:
* Support data exchange using either an Excel file or an XML message.
* Transport technology: Indirect via and or more data pools or direct via a RestAPI.

The key principle is to model for multiple interoperable modular standards in any part of the framework. In this way, industries, organizations and solutions providers can choose the standard per part of the data exchange that suits best.

Layer - Data Transport

2026-10-14T11:40:09Z

HansdG: HansdG moved page Layer - Data Exchange to Layer - Data Transport without leaving a redirect

==What is the purpose of the Data Transport layer?==
The Data Transport layer makes it possible to design and control the flow of data between systems. Data Exchange can be internally or between parties in the value network. The industry currently recognizes three distinct models: federated, centralized, and hybrid.

===Federated Data Exchange===
Federated is a decentralized approach that emphasizes partial, controlled sharing among autonomous databases. Components (systems) of a federated architecture represent the various systems/machines. Each system controls its interactions with others by means with the support of Data Formats. The federated architecture provides a means to share data and transactions using messaging services, combining information from several components, and providing the coordination of data exchange among autonomous components.

[https://synf.co/dataportsintro DataPorts] is an example of Federated Data Exchange, where machines exchange data (push & pull) using IoT technologies.

===Centralized Data Exchange===
Centralized architecture emphasizes full control over data sharing through a centralized repository. Components in a centralized architecture refer to the central data repository. The repository authenticates the requester, authorizes the transaction, and records it for audit and reporting purposes.

DataPools like GS1-GDSN, EZBase, 2BA, InstallData and PS in Foodservice are based on centralized data exchange.

==Hybrid Data Exchange==
Hybrid is a combination of the two architecture types used to achieve the actual exchange of clinical data. For instance, trade conditions may occur through the use of a federated model, while public product data is shared through a centralized database.

==Data Transport Technologies==
* RestAPI
* SOAP API
* DataPorts (IOT based)
* Digital Links (based on GS1/ISO standards)
** Packaging Digital Link
* FTP/sFTP/FTPs
* AS2
* Email
* Fileshare solutions like: Dropbox, Box.com and Sharepoint

[[Category:Layers]]

Layer - Data Transport

2026-10-14T11:16:00Z

HansdG:

==What is the purpose of the Data Transport layer?==
The Data Transport layer makes it possible to design and control the flow of data between systems. Data Exchange can be internally or between parties in the value network. The industry currently recognizes three distinct models: federated, centralized, and hybrid.

===Federated Data Exchange===
Federated is a decentralized approach that emphasizes partial, controlled sharing among autonomous databases. Components (systems) of a federated architecture represent the various systems/machines. Each system controls its interactions with others by means with the support of Data Formats. The federated architecture provides a means to share data and transactions using messaging services, combining information from several components, and providing the coordination of data exchange among autonomous components.

[https://synf.co/dataportsintro DataPorts] is an example of Federated Data Exchange, where machines exchange data (push & pull) using IoT technologies.

===Centralized Data Exchange===
Centralized architecture emphasizes full control over data sharing through a centralized repository. Components in a centralized architecture refer to the central data repository. The repository authenticates the requester, authorizes the transaction, and records it for audit and reporting purposes.

DataPools like GS1-GDSN, EZBase, 2BA, InstallData and PS in Foodservice are based on centralized data exchange.

==Hybrid Data Exchange==
Hybrid is a combination of the two architecture types used to achieve the actual exchange of clinical data. For instance, trade conditions may occur through the use of a federated model, while public product data is shared through a centralized database.

==Data Transport Technologies==
* RestAPI
* SOAP API
* DataPorts (IOT based)
* Digital Links (based on GS1/ISO standards)
** Packaging Digital Link
* FTP/sFTP/FTPs
* AS2
* Email
* Fileshare solutions like: Dropbox, Box.com and Sharepoint

[[Category:Layers]]

Layer - Data Transport

2026-10-14T11:12:44Z

HansdG: /* Data Exchange Technologies */

==What is the purpose of the Data Exchange layer?==
The Data Exchange layer makes it possible to design and control the flow of data between systems. Data Exchange can be internally or between parties in the value network. The industry currently recognizes three distinct models: federated, centralized, and hybrid.

===Federated Data Exchange===
Federated is a decentralized approach that emphasizes partial, controlled sharing among autonomous databases. Components (systems) of a federated architecture represent the various systems/machines. Each system controls its interactions with others by means with the support of Data Formats. The federated architecture provides a means to share data and transactions using messaging services, combining information from several components, and providing the coordination of data exchange among autonomous components.

[https://synf.co/dataportsintro DataPorts] is an example of Federated Data Exchange, where machines exchange data (push & pull) using IoT technologies.

===Centralized Data Exchange===
Centralized architecture emphasizes full control over data sharing through a centralized repository. Components in a centralized architecture refer to the central data repository. The repository authenticates the requester, authorizes the transaction, and records it for audit and reporting purposes.

DataPools like GS1-GDSN, EZBase, 2BA, InstallData and PS in Foodservice are based on centralized data exchange.

==Hybrid Data Exchange==
Hybrid is a combination of the two architecture types used to achieve the actual exchange of clinical data. For instance, trade conditions may occur through the use of a federated model, while public product data is shared through a centralized database.

==Data Exchange Technologies==
* RestAPI
* SOAP API
* DataPorts (IOT based)
* Digital Links (based on GS1/ISO standards)
** Packaging Digital Link
* FTP/sFTP/FTPs
* AS2
* Email
* Fileshare solutions like: Dropbox, Box.com and Sharepoint

[[Category:Layers]]

Layer - Data Transport

2026-10-14T11:07:38Z

HansdG: /* Data Exchange Technologies */

==What is the purpose of the Data Exchange layer?==
The Data Exchange layer makes it possible to design and control the flow of data between systems. Data Exchange can be internally or between parties in the value network. The industry currently recognizes three distinct models: federated, centralized, and hybrid.

===Federated Data Exchange===
Federated is a decentralized approach that emphasizes partial, controlled sharing among autonomous databases. Components (systems) of a federated architecture represent the various systems/machines. Each system controls its interactions with others by means with the support of Data Formats. The federated architecture provides a means to share data and transactions using messaging services, combining information from several components, and providing the coordination of data exchange among autonomous components.

[https://synf.co/dataportsintro DataPorts] is an example of Federated Data Exchange, where machines exchange data (push & pull) using IoT technologies.

===Centralized Data Exchange===
Centralized architecture emphasizes full control over data sharing through a centralized repository. Components in a centralized architecture refer to the central data repository. The repository authenticates the requester, authorizes the transaction, and records it for audit and reporting purposes.

DataPools like GS1-GDSN, EZBase, 2BA, InstallData and PS in Foodservice are based on centralized data exchange.

==Hybrid Data Exchange==
Hybrid is a combination of the two architecture types used to achieve the actual exchange of clinical data. For instance, trade conditions may occur through the use of a federated model, while public product data is shared through a centralized database.

==Data Exchange Technologies==
* RestAPI
* SOAP API
* DataPorts (IOT based)
* Digital Links (based on GS1/ISO standards)
* FTP/sFTP/FTPs
* AS2
* Email
* Fileshare solutions like: Dropbox, Box.com and Sharepoint

[[Category:Layers]]

Layer - Data Schema

2026-10-09T09:33:48Z

HansdG: /* Data Schema and Data Containers */

== IMDE Data Schemas==
IMDE goal is to support multiple versioned DataSchemas (backwards and forwards compatible) for all data points relevant to manufacture, distribute, commercialize and re-cycle discrete products (e.g. food, beverages, fashion, electronics, power tools, adhesives, pet food, personal care, home care, et cetera).

The IMDE DataSchema layer is implementation agnostic so that the defined DataSchemas can be implemented in DataPools, Data Networks or Digital Catalog standards (like [https://fabdis.fr/ FABDIS] or [https://www.bme.de/ BMECAT]).

==Data Schema and Data Containers==

IMDE supports the exchange of data related to the following entities via so called DataContainers. A data container contains a message or file related to one or more entities of the same type.

* '''[[DataContainer_-_Item|Item/Object]]''': Use to exchange data related to physical items. Items can be transported by car, truck, plane or boat. There are multiple types of items:
** ''Handling unit'' (e.g. a physical package or container that is used to transport, store or handle goods. It could be a pallet, a box, a crate or a bundle, and it is often used to group items together to facilitate handling, storage and transport. A cases, cartons, display)
** ''Finished goods'' (e.g. TV, mobile phone, bottle of shampoo, ready to eat salad, smoothie in plastic bottle)
** Parts/Components
*** ''Semi-finished good / Sub-assemblies'' (e.g. bottled beer without labels, frozen fries not yet packaged), usually produced by the brandowner/product manufacturer).
*** ''Components'' (e.g packaging components like foil & cans and food components like herb-mixes or electronic components)
*** ''Raw material'' (e.g. eggs, raw milk, salt, oil, tree trunk, grain, iron)
* '''[[DataContainer_-_Bill_of_materials|Bill of materials]]''': Hierarchies of physical items, for example full trade hierarchy (Pallet, case, finished good) or manufacturing BOMs (Finished Good, Components/Parts, Raw Materials)
* '''[[DataContainer_-_PackagingSystem|Packaging System]]''': Packaging System (compliance object for PPWR and Packaging EPR)
* '''[[Trade_hierarchies|Trade hierarchies]]''': In the IMDE format, trade hierarchies are modelled as part of the Bill of materials
* '''Party/Legal Entity''': Organizations and corporations like Manufacturers, Retailers, NGOs and government bodies. Easy check: Legal entities can be sued in court
* '''Location''': Any place on earth where activities take place, like farms, forests, production facilities, distribution centers and retail stores). Easy check: Locations can be found on Google Maps.
* '''Brand''': Covers both product and organizational brands.
* '''Person''': Individuals/humans like employees and consumers)
* '''[[Transactions]]''': Production Runs, Orders, Shipments
*

Every entity will have a defined '''DataContainer''' within IMDE framework to exchange data related to this entity (e.g. product information for materials). Every DataContainer will have a header which includes an [[Layer_-_Identifiers|identifier]] which will enable machines to process the data in a fully automatic way.

===One or more Data Topics per container===
The core principles of the IMDE framework are interoperable and modular. That also applies to data schemas (data message formats and spreadsheet templates). Within the IMDE framework industry groups will work on defining DataTopics. A DataTopic will contain all datapoints covering a specific topic. Examples are: Packaging Materials, Allergens, Marks or Claims. Any data message or template can contain one or more DataTopics, depending on the needs in that part of the supply chain. For example
* A Packaging Component Supplier will include the Packaging Material Datatopic in a data message that is send to a CPG brand owner.
* A Herb Mix Supplier will include all Food recipe related DataTopics like Allergens, Ingredients and Nutrients
* A Adhesive supplier will include all Formula related DataTopics like Reach
* A CPG/FMCG in Food will data related to the "consumer product" which will Food and Packaging related DataTopics in the data message that is sent to heir business partners (retailers, wholesales, logistic service providers)

This covers the modular part, the framework becomes interoperable by allowing multiple schemas per DataTopic, with defined transformations between the schemas. This allows every party (both data senders and receivers) to work in the schema they prefer (no longer deliver multiple formats to all different data receivers).

The IMDE framework will support multiple DataSchemas per '''DataTopic''' (e.g allergens) and related data points, making sure all industries and all territories can join IMDE. IMDE will also support multiple DataSchemas per Data topic. Example: allergen exchange Excel template and Allergen Exchange XSD/XML. IMDE will also support existing information & taxonomy standards, like for example:
* [https://www.etim-international.com/ ETIM], the international classification standard for technical products
* [https://www.fao.org/ FAO] for Fish farming and Fishery related information standards
* [https://www.iso.org/ ISO] (e.g. for languages, countries and units)

[[Category:Layers]]

DataContainer - PackagingSystem

2026-10-09T09:33:14Z

HansdG: HansdG moved page DataContainer -PackagingSystemMaster to DataContainer - PackagingSystem

===General DataTopics===

{| class="wikitable"
|+
|-
! DataTopic Code !! DataTopic
|-
| '''[[DataTopic_PackagingSystemMasterKeyInfo|PackagingSystemMasterKeyInfo]]'''|| Identifiers
|-
| '''[[DataTopic_DeclarationOfConformity|DeclarationOfConformity]]'''|| Key info and urls
|-
| '''[[DataTopic_TechnicalDossiers|TechnicalDossiers]]''' || Evidence
|}

Layer - Data Schema

2026-10-09T09:31:26Z

HansdG: /* Data Schema and Data Containers */

== IMDE Data Schemas==
IMDE goal is to support multiple versioned DataSchemas (backwards and forwards compatible) for all data points relevant to manufacture, distribute, commercialize and re-cycle discrete products (e.g. food, beverages, fashion, electronics, power tools, adhesives, pet food, personal care, home care, et cetera).

The IMDE DataSchema layer is implementation agnostic so that the defined DataSchemas can be implemented in DataPools, Data Networks or Digital Catalog standards (like [https://fabdis.fr/ FABDIS] or [https://www.bme.de/ BMECAT]).

==Data Schema and Data Containers==

IMDE supports the exchange of data related to the following entities via so called DataContainers. A data container contains a message or file related to one or more entities of the same type.

* '''[[DataContainer_-_Item|Item/Object]]''': Use to exchange data related to physical items. Items can be transported by car, truck, plane or boat. There are multiple types of items:
** ''Handling unit'' (e.g. a physical package or container that is used to transport, store or handle goods. It could be a pallet, a box, a crate or a bundle, and it is often used to group items together to facilitate handling, storage and transport. A cases, cartons, display)
** ''Finished goods'' (e.g. TV, mobile phone, bottle of shampoo, ready to eat salad, smoothie in plastic bottle)
** Parts/Components
*** ''Semi-finished good / Sub-assemblies'' (e.g. bottled beer without labels, frozen fries not yet packaged), usually produced by the brandowner/product manufacturer).
*** ''Components'' (e.g packaging components like foil & cans and food components like herb-mixes or electronic components)
*** ''Raw material'' (e.g. eggs, raw milk, salt, oil, tree trunk, grain, iron)
* '''[[DataContainer_-_Bill_of_materials|Bill of materials]]''': Hierarchies of physical items, for example full trade hierarchy (Pallet, case, finished good) or manufacturing BOMs (Finished Good, Components/Parts, Raw Materials)
* '''[[DataContainer_-PackagingSystem|Packaging System]]''': Packaging System (compliance object for PPWR and Packaging EPR)
* '''[[Trade_hierarchies|Trade hierarchies]]''': In the IMDE format, trade hierarchies are modelled as part of the Bill of materials
* '''Party/Legal Entity''': Organizations and corporations like Manufacturers, Retailers, NGOs and government bodies. Easy check: Legal entities can be sued in court
* '''Location''': Any place on earth where activities take place, like farms, forests, production facilities, distribution centers and retail stores). Easy check: Locations can be found on Google Maps.
* '''Brand''': Covers both product and organizational brands.
* '''Person''': Individuals/humans like employees and consumers)
* '''[[Transactions]]''': Production Runs, Orders, Shipments
*

Every entity will have a defined '''DataContainer''' within IMDE framework to exchange data related to this entity (e.g. product information for materials). Every DataContainer will have a header which includes an [[Layer_-_Identifiers|identifier]] which will enable machines to process the data in a fully automatic way.

===One or more Data Topics per container===
The core principles of the IMDE framework are interoperable and modular. That also applies to data schemas (data message formats and spreadsheet templates). Within the IMDE framework industry groups will work on defining DataTopics. A DataTopic will contain all datapoints covering a specific topic. Examples are: Packaging Materials, Allergens, Marks or Claims. Any data message or template can contain one or more DataTopics, depending on the needs in that part of the supply chain. For example
* A Packaging Component Supplier will include the Packaging Material Datatopic in a data message that is send to a CPG brand owner.
* A Herb Mix Supplier will include all Food recipe related DataTopics like Allergens, Ingredients and Nutrients
* A Adhesive supplier will include all Formula related DataTopics like Reach
* A CPG/FMCG in Food will data related to the "consumer product" which will Food and Packaging related DataTopics in the data message that is sent to heir business partners (retailers, wholesales, logistic service providers)

This covers the modular part, the framework becomes interoperable by allowing multiple schemas per DataTopic, with defined transformations between the schemas. This allows every party (both data senders and receivers) to work in the schema they prefer (no longer deliver multiple formats to all different data receivers).

The IMDE framework will support multiple DataSchemas per '''DataTopic''' (e.g allergens) and related data points, making sure all industries and all territories can join IMDE. IMDE will also support multiple DataSchemas per Data topic. Example: allergen exchange Excel template and Allergen Exchange XSD/XML. IMDE will also support existing information & taxonomy standards, like for example:
* [https://www.etim-international.com/ ETIM], the international classification standard for technical products
* [https://www.fao.org/ FAO] for Fish farming and Fishery related information standards
* [https://www.iso.org/ ISO] (e.g. for languages, countries and units)

[[Category:Layers]]

Layer - Data Schema

2026-10-09T09:31:12Z

HansdG: /* Data Schema and Data Containers */

== IMDE Data Schemas==
IMDE goal is to support multiple versioned DataSchemas (backwards and forwards compatible) for all data points relevant to manufacture, distribute, commercialize and re-cycle discrete products (e.g. food, beverages, fashion, electronics, power tools, adhesives, pet food, personal care, home care, et cetera).

The IMDE DataSchema layer is implementation agnostic so that the defined DataSchemas can be implemented in DataPools, Data Networks or Digital Catalog standards (like [https://fabdis.fr/ FABDIS] or [https://www.bme.de/ BMECAT]).

==Data Schema and Data Containers==

IMDE supports the exchange of data related to the following entities via so called DataContainers. A data container contains a message or file related to one or more entities of the same type.

* '''[[DataContainer_-_Item|Item/Object]]''': Use to exchange data related to physical items. Items can be transported by car, truck, plane or boat. There are multiple types of items:
** ''Handling unit'' (e.g. a physical package or container that is used to transport, store or handle goods. It could be a pallet, a box, a crate or a bundle, and it is often used to group items together to facilitate handling, storage and transport. A cases, cartons, display)
** ''Finished goods'' (e.g. TV, mobile phone, bottle of shampoo, ready to eat salad, smoothie in plastic bottle)
** Parts/Components
*** ''Semi-finished good / Sub-assemblies'' (e.g. bottled beer without labels, frozen fries not yet packaged), usually produced by the brandowner/product manufacturer).
*** ''Components'' (e.g packaging components like foil & cans and food components like herb-mixes or electronic components)
*** ''Raw material'' (e.g. eggs, raw milk, salt, oil, tree trunk, grain, iron)
* '''[[DataContainer_-_Bill_of_materials|Bill of materials]]''': Hierarchies of physical items, for example full trade hierarchy (Pallet, case, finished good) or manufacturing BOMs (Finished Good, Components/Parts, Raw Materials)
* '''[[DataContainer_-PackagingSystem|Packaging System]''': Packaging System (compliance object for PPWR and Packaging EPR)
* '''[[Trade_hierarchies|Trade hierarchies]]''': In the IMDE format, trade hierarchies are modelled as part of the Bill of materials
* '''Party/Legal Entity''': Organizations and corporations like Manufacturers, Retailers, NGOs and government bodies. Easy check: Legal entities can be sued in court
* '''Location''': Any place on earth where activities take place, like farms, forests, production facilities, distribution centers and retail stores). Easy check: Locations can be found on Google Maps.
* '''Brand''': Covers both product and organizational brands.
* '''Person''': Individuals/humans like employees and consumers)
* '''[[Transactions]]''': Production Runs, Orders, Shipments
*

Every entity will have a defined '''DataContainer''' within IMDE framework to exchange data related to this entity (e.g. product information for materials). Every DataContainer will have a header which includes an [[Layer_-_Identifiers|identifier]] which will enable machines to process the data in a fully automatic way.

===One or more Data Topics per container===
The core principles of the IMDE framework are interoperable and modular. That also applies to data schemas (data message formats and spreadsheet templates). Within the IMDE framework industry groups will work on defining DataTopics. A DataTopic will contain all datapoints covering a specific topic. Examples are: Packaging Materials, Allergens, Marks or Claims. Any data message or template can contain one or more DataTopics, depending on the needs in that part of the supply chain. For example
* A Packaging Component Supplier will include the Packaging Material Datatopic in a data message that is send to a CPG brand owner.
* A Herb Mix Supplier will include all Food recipe related DataTopics like Allergens, Ingredients and Nutrients
* A Adhesive supplier will include all Formula related DataTopics like Reach
* A CPG/FMCG in Food will data related to the "consumer product" which will Food and Packaging related DataTopics in the data message that is sent to heir business partners (retailers, wholesales, logistic service providers)

This covers the modular part, the framework becomes interoperable by allowing multiple schemas per DataTopic, with defined transformations between the schemas. This allows every party (both data senders and receivers) to work in the schema they prefer (no longer deliver multiple formats to all different data receivers).

The IMDE framework will support multiple DataSchemas per '''DataTopic''' (e.g allergens) and related data points, making sure all industries and all territories can join IMDE. IMDE will also support multiple DataSchemas per Data topic. Example: allergen exchange Excel template and Allergen Exchange XSD/XML. IMDE will also support existing information & taxonomy standards, like for example:
* [https://www.etim-international.com/ ETIM], the international classification standard for technical products
* [https://www.fao.org/ FAO] for Fish farming and Fishery related information standards
* [https://www.iso.org/ ISO] (e.g. for languages, countries and units)

[[Category:Layers]]

Reserved Code List Values: UNSPECIFIED and NOT APPLICABLE - TX

2026-10-01T13:38:07Z

HansdG: Created page with "== Purpose and scope == Every code list attribute in an exchange file (XML or JSON) can carry two reserved values, <code>UNSPECIFIED</code> and <code>NOT_APPLICABLE</code>, on top of its own business values. These two values let a sender say ''why'' a business value is missing, rather than leaving a gap the receiver has to guess at. This matters most for regulatory data (PPWR, ESPR/DPP), where "no", "we don't know yet" and "this question doesn't apply" lead to different..."

== Purpose and scope ==
Every code list attribute in an exchange file (XML or JSON) can carry two reserved values, <code>UNSPECIFIED</code> and <code>NOT_APPLICABLE</code>, on top of its own business values. These two values let a sender say ''why'' a business value is missing, rather than leaving a gap the receiver has to guess at.

This matters most for regulatory data (PPWR, ESPR/DPP), where "no", "we don't know yet" and "this question doesn't apply" lead to different compliance outcomes.

'''Scope:''' all code-list-typed attributes in exchange files, including yes/no attributes modelled as a code list. Free text, numeric, date and measurement attributes are out of scope for this page.

== The principle ==
<blockquote>
'''Every code list attribute MAY carry one of two reserved system values, <code>UNSPECIFIED</code> or <code>NOT_APPLICABLE</code>, in place of a business value. These values are defined once, at the standard level. They belong to no individual code list and MUST NOT be redefined by one.'''
</blockquote>

In this page, MUST, MUST NOT, SHOULD and MAY are used as in [https://www.rfc-editor.org/rfc/rfc2119 RFC 2119].

== Definitions ==
;UNSPECIFIED
:The attribute applies to this item, but the sender cannot give its value yet. It is a known gap: someone should be able to answer, and nobody has so far.
:''Example: a supplier has not yet confirmed whether a film layer is in direct contact with food.''

;NOT_APPLICABLE
:The attribute does not apply to this item, so no business value can ever be correct. The sender has checked this, and it is a complete answer.
:''Example: "Food contact" on packaging for a power drill.''

;Absent attribute
:The attribute is not in the message at all. It carries no meaning about the item: the sender either does not support the attribute or chose not to send it. In a delta update, absent means "no change".

;Business value
:Any value defined in the attribute's own code list, such as <code>FOOD</code> or <code>TRUE</code>.

{| class="wikitable"
! Situation !! Value to send !! Is the answer complete?
|-
| Value is known || A business value || Yes
|-
| Question does not apply to this item || <code>NOT_APPLICABLE</code> || Yes
|-
| Question applies, answer not yet known || <code>UNSPECIFIED</code> || No: a known gap
|-
| Sender does not hold or send this attribute || Leave the attribute out || No information
|}

== Rules ==
# '''Reserved at standard level.''' The two values are system values. They are available on every code list attribute automatically and are not maintained inside individual code lists.
# '''No look-alike business values.''' A code list MUST NOT contain values such as <code>UNKNOWN</code>, <code>N/A</code>, <code>NONE_SPECIFIED</code> or <code>OTHER_UNKNOWN</code> that duplicate either meaning. Existing look-alikes SHOULD be deprecated and mapped to the reserved value.
# '''Fixed notation.''' Exchange files MUST use exactly <code>UNSPECIFIED</code> and <code>NOT_APPLICABLE</code>: upper case, underscore, never translated. User interfaces show localised labels (NL: ''Niet gespecificeerd'', ''Niet van toepassing'').
# '''No substitutes.''' Empty strings, <code>null</code>, <code>-</code>, <code>0</code> or free-text "n/a" MUST NOT be used to mean either value. To send nothing, leave the attribute out.
# '''Exclusive in multi-value attributes.''' A reserved value MUST be the only value of the attribute. <code>["FOOD", "UNSPECIFIED"]</code> is invalid.
# '''Attribute may restrict them.''' An attribute definition MAY disallow <code>NOT_APPLICABLE</code> when it always applies (for example ''Packaging material'' on a packaging component). Disallowing <code>UNSPECIFIED</code> is not recommended: it pushes senders to guess.
# '''Never resolved by the receiver.''' A receiver MUST NOT turn <code>UNSPECIFIED</code> into a default business value (such as <code>FALSE</code>). It stays a gap until the sender sends a business value.
# '''How the system fills them.''' <code>NOT_APPLICABLE</code> can be set by a user or derived from an applicability rule (for example, ''Food contact'' does not apply to non-food categories). <code>UNSPECIFIED</code> is set by a user or supplier who confirms the gap. The system SHOULD NOT write <code>UNSPECIFIED</code> just because a field is empty: an empty field is left out of the file.
# '''Delta updates.''' Replacing a business value with a reserved value, or the other way round, is a normal update. Leaving the attribute out of a delta keeps the stored value.

== Examples ==
=== XML Schema: one reusable type, combined with each code list ===
<syntaxhighlight lang="xml">

<xs:simpleType name="ReservedCodeValue">
<xs:restriction base="xs:token">
<xs:enumeration value="UNSPECIFIED"/>
<xs:enumeration value="NOT_APPLICABLE"/>
</xs:restriction>
</xs:simpleType>


<xs:simpleType name="ContactSensitiveProductCategoryList">
<xs:restriction base="xs:token">
<xs:enumeration value="FOOD"/>
<xs:enumeration value="COSMETIC"/>
<xs:enumeration value="MEDICAL_DEVICE"/>
<xs:enumeration value="NOT_CONTACT_SENSITIVE"/>
</xs:restriction>
</xs:simpleType>


<xs:simpleType name="ContactSensitiveProductCategoryCode">
<xs:union memberTypes="ContactSensitiveProductCategoryList ReservedCodeValue"/>
</xs:simpleType>
</syntaxhighlight>

=== XML instances ===
<syntaxhighlight lang="xml">
<salesUnit gtin="08712345000017">

<contactSensitiveProductCategory>FOOD</contactSensitiveProductCategory>

<packagingComponent id="PC-01">

<isFoodContact>TRUE</isFoodContact>
</packagingComponent>

<packagingComponent id="PC-02">

<isFoodContact>UNSPECIFIED</isFoodContact>
</packagingComponent>
</salesUnit>

<salesUnit gtin="08712345000024"> 
<contactSensitiveProductCategory>NOT_CONTACT_SENSITIVE</contactSensitiveProductCategory>
<packagingComponent id="PC-03">
<isFoodContact>NOT_APPLICABLE</isFoodContact>

</packagingComponent>
</salesUnit>
</syntaxhighlight>

=== JSON instances ===
<syntaxhighlight lang="json">
{
"salesUnit": {
"gtin": "08712345000017",
"contactSensitiveProductCategory": "FOOD",
"packagingComponents": [
{ "id": "PC-01", "isFoodContact": "TRUE",
"materialTypes": ["PET", "PE"] },
{ "id": "PC-02", "isFoodContact": "UNSPECIFIED",
"materialTypes": ["UNSPECIFIED"] },
{ "id": "PC-03", "isFoodContact": "NOT_APPLICABLE" }
]
}
}
</syntaxhighlight>

=== Invalid examples ===
<syntaxhighlight lang="javascript">
{ "isFoodContact": null } // use: leave the key out
{ "isFoodContact": "" } // use: leave the key out
{ "isFoodContact": "N/A" } // use: "NOT_APPLICABLE"
{ "materialTypes": ["PET", "UNSPECIFIED"] } // reserved value must be alone
{ "contactSensitiveProductCategory": "Unknown" } // use: "UNSPECIFIED"
</syntaxhighlight>

== Validation and completeness ==
Receivers and data-quality checks SHOULD score the values as below. The key difference: <code>NOT_APPLICABLE</code> closes the question, <code>UNSPECIFIED</code> keeps it open.

{| class="wikitable"
! Value in file !! Schema-valid? !! Counts as complete? !! Typical follow-up
|-
| Business value || Yes || Yes || None
|-
| <code>NOT_APPLICABLE</code> || Yes, unless the attribute disallows it || Yes || Check it against applicability rules
|-
| <code>UNSPECIFIED</code> || Yes || No || Task to the supplier or data owner
|-
| Attribute absent, optional || Yes || Not scored || None
|-
| Attribute absent, mandatory || No || No || Message rejected or flagged
|-
| <code>null</code>, empty, <code>N/A</code> || No || No || Message rejected
|}

== Mapping to other standards ==
The two values were chosen to map one-to-one onto GS1 GDSN, so most exports to GDSN need no conversion.

{| class="wikitable"
! This standard !! GS1 GDSN (NonBinaryLogicEnumeration) !! HL7 nullFlavor !! Plain xs:boolean / JSON boolean
|-
| Business value <code>TRUE</code> / <code>FALSE</code> || <code>TRUE</code> / <code>FALSE</code> || Value present || <code>true</code> / <code>false</code>
|-
| <code>UNSPECIFIED</code> || <code>UNSPECIFIED</code> || <code>UNK</code> (unknown) or <code>ASKU</code> (asked, unknown) || Cannot be expressed: leave out and flag
|-
| <code>NOT_APPLICABLE</code> || <code>NOT_APPLICABLE</code> || <code>NA</code> || Cannot be expressed: leave out
|-
| Attribute absent || Attribute absent || <code>NI</code> (no information) || Attribute absent
|}

''Open question: confirm the GDSN code list names against the current GS1 GDSN code list release before publishing this page externally.''

[[Category:Taxonomy definitions]]
[[Category:Code lists]]
```

This is the source text, not a rendered preview. To see how the page will actually look, paste it into your wiki's edit window and click "Show preview".

Packaging System - TX

2026-09-09T11:47:24Z

HansdG:

Definition: The Packaging System is the complete, hierarchical collection of all Packaging Masters used together to contain, protect, handle, deliver, and present a product, from the factory to the end-user.

Most common example: Full Pallet Configuration (One Transport Stock Unit with is Transport Packaging), consisting of multiple outercartons (TSUs with it Transport Packaging), with per outercarton multiple Individual Sales Units (with is Sales Packaging).

[[Category:Taxonomy]]

Facility - TX

2026-09-09T11:45:30Z

HansdG: /* See also */

'''Facility''' is a place where one or more defined activities are carried out, operated by a legal entity, and situated at a [[Location]].

A Facility answers two questions that a Location cannot: ''what happens here'', and ''who runs it''. It is the operational object that compliance statements, certificates, accreditations and evidence attach to.

== Facility Functions ==

A Facility does not have a type. It has one or more '''Functions'''.

This is a deliberate modelling choice. A single type per facility has never held up against the real world, because real sites do several things at once: a plant that produces and warehouses, a site that farms and sells at the gate, an office that does marketing and customer service, a copacker that fills and stores. Forcing one label per site means the model is wrong for most of the estate on day one, and it stays wrong.

A Function is an activity. Because a Facility carries a set of Functions rather than a single label, the model follows reality instead of flattening it, and a site that adds or drops an activity keeps its identity and its history.

=== Function list ===

{| class="wikitable"
! Code !! Function !! Group !! Activity carried out
|-
| FARM || '''Farming''' || Sourcing
| Agricultural activity, where raw materials such as crops or livestock are produced.
|-
| FISH || '''Fishing & Aquaculture''' || Sourcing
| Catching wild fish and shellfish, and rearing aquatic species in controlled water environments.
|-
| FRST || '''Forestry''' || Sourcing
| Growing and harvesting timber and other forest materials from managed or natural woodland.
|-
| MINE || '''Mining''' || Sourcing
| Extraction of natural resources such as minerals, metals or fossil fuels from the Earth.
|-
| EXTR || '''Extraction''' || Sourcing
| Extraction of crude oil from underground reservoirs or from beneath the ocean floor, extraction of natural gas, often found in conjunction with oil extraction, and extraction of sedimentary materials such as sand, gravel or clay, often used in construction or other industrial applications.
|-
| PROC || '''Processing''' || Transformation
| Transformation of raw or recovered materials into intermediate materials. Refining, smelting, pulping, papermaking, glass melting and polymerisation.
|-
| CONV || '''Converting''' || Transformation
| Transformation of intermediate materials into components. Printing, laminating, coating, forming, moulding and cutting. This is where a [[Material Platform - TX|Material Platform]] becomes a packaging component.
|-
| PROD || '''Production''' || Transformation
| Transformation of raw materials into finished goods through manufacturing processes.
|-
| PACK || '''Packaging & Filling''' || Transformation
| Filling products into packaging and assembling the packed unit, whether performed by the brand owner or by a contract manufacturer or copacker.
|-
| WHSE || '''Warehousing''' || Logistics
| Storage of goods, often serving as a hub for inventory management and distribution.
|-
| DIST || '''Distribution''' || Logistics
| Logistics and transportation of goods from production sites or warehouses to other locations, such as retail outlets or end customers.
|-
| SALE || '''Sales''' || Commercial
| Selling products or services directly to consumers or other businesses. Includes retail stores, dealerships and e-commerce distribution points.
|-
| MKTG || '''Marketing''' || Commercial
| Promotion and advertisement of products or services. Includes corporate offices, agencies and regional marketing centres.
|-
| CSVC || '''Customer Service''' || Commercial
| Support and assistance to customers, including handling inquiries, resolving issues and ensuring customer satisfaction.
|-
| RSDV || '''Research & Development (R&D)''' || Support
| Innovation, product development and the testing of new ideas or products. Crucial for sustaining competitive advantage and driving future growth.
|-
| LABO || '''Laboratory & Testing''' || Support
| Analysis and testing of materials, components or products, including the issuing of test reports under an accreditation.
|-
| INSP || '''Inspection & Certification''' || Support
| Auditing, inspection and the issuing of certificates against a scheme or standard.
|-
| ADMN || '''Administration''' || Support
| Corporate and back office activity such as finance, legal, human resources and general management.
|-
| REPR || '''Repair & Reconditioning''' || Circularity
| Repair, refurbishment, cleaning and reconditioning of goods or packaging so they can be used again, including washing lines in reuse systems.
|-
| COLL || '''Collection''' || Circularity
| Gathering used products, packaging or waste from consumers, businesses or public collection points.
|-
| SORT || '''Sorting''' || Circularity
| Separation of collected materials into streams by material, format or quality, preparing them for recycling or recovery.
|-
| RECY || '''Recycling''' || Circularity
| Reprocessing of collected materials into secondary raw materials fit for use in new products or packaging.
|-
| RCVR || '''Recovery & Disposal''' || Circularity
| Energy recovery, treatment and final disposal of materials that are not recycled.
|}

=== Applying functions ===

* A Facility has '''one or more''' Functions. There is no primary Function and no ranking.
* Functions can be added or removed over the life of a Facility '''without''' creating a new Facility. The identity is the operated site, not the activity mix.
* Evidence attaches to the Function that produced it. A test report comes from the Laboratory & Testing Function, a harvest declaration from the Farming Function, a recycled content claim from the Recycling Function.
* The Group column is for navigation and reporting only. It carries no rules and a Facility is never assigned a Group.

== Operator ==

A Facility is always operated by a legal entity, and that operator is what makes the Facility accountable. Site certifications, audit outcomes, permits, accreditations and site level profiles such as an allergen profile are properties of the Facility, not of the Location.

A company can operate facilities at many locations, and can sell or transfer a facility without the location changing at all.

== One facility or several? ==

A Location can host more than one Facility. Use these rules to decide.

* Same operator, one accountable site, several activities: '''one Facility with several Functions'''.
* Different operators on the same Location: '''separate Facilities''', one per operator.
* Same operator but separately certified, audited or permitted as distinct sites: '''separate Facilities''', because the evidence attaches separately.

== Difference between location & facility ==

{| class="wikitable"
! !! Location !! Facility
|-
! Question
| Where || What happens there, and who runs it
|-
! Identity
| GLN, plus extension component for internal locations || Its own identifier, referencing a Location and an operator
|-
! Forms
| Address, point, polygon || One or more Functions
|-
! Carries
| Geography only || Certificates, accreditations, permits, site profiles
|-
! Cardinality
| One Location, many Facilities || One Facility, one Location
|}

The separation earns its keep the moment evidence has to be traced. A harvest happens at a plot with no facility on it. A test report is issued by a laboratory and its accreditation belongs to that laboratory, not to the address. A packaging component is produced at a Facility whose location may be commercially confidential while its country still has to be declared.

== What a Facility is not ==

* '''Not the legal entity that operates it.''' The operator is a separate object with its own identifier.
* '''Not the place it sits on.''' The Location is a separate object and can outlive any Facility on it.
* '''Not a type.''' See [[#Facility Functions]].

== See also ==

* [[Location - TX]]
* [[Material Platform - TX]]
* [[Packaging System - TX]]

[[Category:Taxonomy]]

Facility - TX

2026-09-09T11:45:07Z

HansdG: /* Function list */

'''Facility''' is a place where one or more defined activities are carried out, operated by a legal entity, and situated at a [[Location]].

A Facility answers two questions that a Location cannot: ''what happens here'', and ''who runs it''. It is the operational object that compliance statements, certificates, accreditations and evidence attach to.

== Facility Functions ==

A Facility does not have a type. It has one or more '''Functions'''.

This is a deliberate modelling choice. A single type per facility has never held up against the real world, because real sites do several things at once: a plant that produces and warehouses, a site that farms and sells at the gate, an office that does marketing and customer service, a copacker that fills and stores. Forcing one label per site means the model is wrong for most of the estate on day one, and it stays wrong.

A Function is an activity. Because a Facility carries a set of Functions rather than a single label, the model follows reality instead of flattening it, and a site that adds or drops an activity keeps its identity and its history.

=== Function list ===

{| class="wikitable"
! Code !! Function !! Group !! Activity carried out
|-
| FARM || '''Farming''' || Sourcing
| Agricultural activity, where raw materials such as crops or livestock are produced.
|-
| FISH || '''Fishing & Aquaculture''' || Sourcing
| Catching wild fish and shellfish, and rearing aquatic species in controlled water environments.
|-
| FRST || '''Forestry''' || Sourcing
| Growing and harvesting timber and other forest materials from managed or natural woodland.
|-
| MINE || '''Mining''' || Sourcing
| Extraction of natural resources such as minerals, metals or fossil fuels from the Earth.
|-
| EXTR || '''Extraction''' || Sourcing
| Extraction of crude oil from underground reservoirs or from beneath the ocean floor, extraction of natural gas, often found in conjunction with oil extraction, and extraction of sedimentary materials such as sand, gravel or clay, often used in construction or other industrial applications.
|-
| PROC || '''Processing''' || Transformation
| Transformation of raw or recovered materials into intermediate materials. Refining, smelting, pulping, papermaking, glass melting and polymerisation.
|-
| CONV || '''Converting''' || Transformation
| Transformation of intermediate materials into components. Printing, laminating, coating, forming, moulding and cutting. This is where a [[Material Platform - TX|Material Platform]] becomes a packaging component.
|-
| PROD || '''Production''' || Transformation
| Transformation of raw materials into finished goods through manufacturing processes.
|-
| PACK || '''Packaging & Filling''' || Transformation
| Filling products into packaging and assembling the packed unit, whether performed by the brand owner or by a contract manufacturer or copacker.
|-
| WHSE || '''Warehousing''' || Logistics
| Storage of goods, often serving as a hub for inventory management and distribution.
|-
| DIST || '''Distribution''' || Logistics
| Logistics and transportation of goods from production sites or warehouses to other locations, such as retail outlets or end customers.
|-
| SALE || '''Sales''' || Commercial
| Selling products or services directly to consumers or other businesses. Includes retail stores, dealerships and e-commerce distribution points.
|-
| MKTG || '''Marketing''' || Commercial
| Promotion and advertisement of products or services. Includes corporate offices, agencies and regional marketing centres.
|-
| CSVC || '''Customer Service''' || Commercial
| Support and assistance to customers, including handling inquiries, resolving issues and ensuring customer satisfaction.
|-
| RSDV || '''Research & Development (R&D)''' || Support
| Innovation, product development and the testing of new ideas or products. Crucial for sustaining competitive advantage and driving future growth.
|-
| LABO || '''Laboratory & Testing''' || Support
| Analysis and testing of materials, components or products, including the issuing of test reports under an accreditation.
|-
| INSP || '''Inspection & Certification''' || Support
| Auditing, inspection and the issuing of certificates against a scheme or standard.
|-
| ADMN || '''Administration''' || Support
| Corporate and back office activity such as finance, legal, human resources and general management.
|-
| REPR || '''Repair & Reconditioning''' || Circularity
| Repair, refurbishment, cleaning and reconditioning of goods or packaging so they can be used again, including washing lines in reuse systems.
|-
| COLL || '''Collection''' || Circularity
| Gathering used products, packaging or waste from consumers, businesses or public collection points.
|-
| SORT || '''Sorting''' || Circularity
| Separation of collected materials into streams by material, format or quality, preparing them for recycling or recovery.
|-
| RECY || '''Recycling''' || Circularity
| Reprocessing of collected materials into secondary raw materials fit for use in new products or packaging.
|-
| RCVR || '''Recovery & Disposal''' || Circularity
| Energy recovery, treatment and final disposal of materials that are not recycled.
|}

=== Applying functions ===

* A Facility has '''one or more''' Functions. There is no primary Function and no ranking.
* Functions can be added or removed over the life of a Facility '''without''' creating a new Facility. The identity is the operated site, not the activity mix.
* Evidence attaches to the Function that produced it. A test report comes from the Laboratory & Testing Function, a harvest declaration from the Farming Function, a recycled content claim from the Recycling Function.
* The Group column is for navigation and reporting only. It carries no rules and a Facility is never assigned a Group.

== Operator ==

A Facility is always operated by a legal entity, and that operator is what makes the Facility accountable. Site certifications, audit outcomes, permits, accreditations and site level profiles such as an allergen profile are properties of the Facility, not of the Location.

A company can operate facilities at many locations, and can sell or transfer a facility without the location changing at all.

== One facility or several? ==

A Location can host more than one Facility. Use these rules to decide.

* Same operator, one accountable site, several activities: '''one Facility with several Functions'''.
* Different operators on the same Location: '''separate Facilities''', one per operator.
* Same operator but separately certified, audited or permitted as distinct sites: '''separate Facilities''', because the evidence attaches separately.

== Difference between location & facility ==

{| class="wikitable"
! !! Location !! Facility
|-
! Question
| Where || What happens there, and who runs it
|-
! Identity
| GLN, plus extension component for internal locations || Its own identifier, referencing a Location and an operator
|-
! Forms
| Address, point, polygon || One or more Functions
|-
! Carries
| Geography only || Certificates, accreditations, permits, site profiles
|-
! Cardinality
| One Location, many Facilities || One Facility, one Location
|}

The separation earns its keep the moment evidence has to be traced. A harvest happens at a plot with no facility on it. A test report is issued by a laboratory and its accreditation belongs to that laboratory, not to the address. A packaging component is produced at a Facility whose location may be commercially confidential while its country still has to be declared.

== What a Facility is not ==

* '''Not the legal entity that operates it.''' The operator is a separate object with its own identifier.
* '''Not the place it sits on.''' The Location is a separate object and can outlive any Facility on it.
* '''Not a type.''' See [[#Facility Functions]].

== See also ==

* [[Location - TX]]
* [[Material Platform -TX]]
* [[Packaging System] - TX]

[[Category:Taxonomy]]

Location - TX

2026-09-09T11:44:27Z

HansdG:

'''Location''' is a place on Earth that can be pointed at on a map, expressed as an address, a coordinate or a bounded area, independent of what happens there or who owns it.

A Location answers one question only: ''where''. It carries no assumption about activity, ownership or legal responsibility. If it can be found on a map, it is a Location. What happens at that place is modelled separately, as a [[Facility - TX|Facility]].

== Forms ==

A Location is expressed in one of three forms. The form follows the precision the use case needs.

; Address
: A postal address in the national addressing format, resolvable to a country and a region.

; Point
: Latitude and longitude in a stated reference system (WGS84), optionally with altitude, or an equivalent point encoding such as What3Words or a Plus Code.

; Area
: A bounded polygon, used where a point is not enough. Agricultural and forestry plots are the standard case: a field, an orchard block, a forest parcel. Deforestation-free sourcing evidence is the clearest driver, where plots above a size threshold have to be given as a polygon rather than a point.

== Identification ==

The identifier for a Location is the '''GLN''' (Global Location Number). Where several distinct places sit inside one GLN, the '''GLN extension component''' identifies the internal location.

A GLN is also used in practice to identify a party. That overlap is precisely why a Location and a legal entity are kept as separate objects in the model. See [[#What a Location is not]].

== Difference between location & facility ==

{| class="wikitable"
! !! Location !! Facility
|-
! Question
| Where || What happens there, and who runs it
|-
! Identity
| GLN, plus extension component for internal locations || Its own identifier, referencing a Location and an operator
|-
! Forms
| Address, point, polygon || Typed activity site
|-
! Carries
| Geography only || Certificates, accreditations, permits, site profiles
|-
! Cardinality
| One Location, many Facilities || One Facility, one Location
|}

The separation earns its keep the moment evidence has to be traced. A harvest happens at a plot with no facility on it. A test report is issued by a laboratory, which is a Facility, and its accreditation belongs to that laboratory and not to the address. A packaging component is produced at a production Facility whose location may be commercially confidential while its country still has to be declared.

Collapsing the two forces a choice, per case, about which meaning the field carries. That choice is exactly what breaks when the data crosses a company boundary.

== What a Location is not ==

* '''Not a company.''' A legal entity is a separate object with its own identifier.
* '''Not an activity.''' A Location with nothing happening on it is still a valid Location: a harvested plot, a mine, a landfill, a collection point.

== Examples ==

* The postal address of a production site.
* The coordinates of a collection point.
* The polygon of a coffee plot delivered as deforestation-free sourcing evidence.
* A warehouse dock identified by a GLN extension component under the site GLN.

== See also ==

* [[Facility]]
* [[Material Platform]]
* [[Packaging System]]
* [[IMDE]]

[[Category:Data model]]
[[Category:Identifiers]]

== Definition ==
A Location is a specific place on Earth that serves as a critical element in the supply chain and business operations. In the context of the IMDE (Interoperable Multi-Dimensional Exchange) framework, a location typically refers to a supply location, which plays a vital role in various stages of the production and distribution process.

== Core Concept ==
Locations are not just geographical points; they are strategic assets that support various functions within an organization. Each location is defined by its physical presence, identification, and associated functions, which can include but are not limited to farming, mining, production, warehousing, distribution, sales, marketing, and research & development.

== Key Attributes ==
*'''Location IDs''': Unique identifiers that provide precise and standardized location information, facilitating interoperability and data exchange. Common methods include:
**What3Words: A geocoding system that divides the world into a grid of 3m x 3m squares, each identified by a unique combination of three words. This method allows for easy communication and pinpointing of exact locations.
**Global Location Number (GLN): A globally recognized identifier used in supply chain management to uniquely identify locations. A GLN can represent any physical location involved in business transactions, such as production sites, warehouses, or retail outlets.
**Geographical Coordinates: The exact latitude and longitude that pinpoint the location on Earth.
*'''Address''': A human-readable description of the location, including street address, city, state/province, and country.

== Usage Context ==
In the IMDE framework, locations are integral to the interoperability of data across different layers. Accurate and consistent location data, including standardized identification methods such as What3Words or GLNs, enables seamless integration and exchange of information related to supply chain management, resource allocation, and strategic planning. Locations can be linked to various entities, such as facilities, suppliers, customers, or internal departments, to provide a holistic view of the business operations across multiple geographies.

==Related==
* [[Geolocation_-_IM|GEO Location]]
* [[LCAterms_-_TX|LCAterms]]
* [[ID_-_Identifier_Types|Identifier Types]]

[[Category: Taxonomy]]

Facility - TX

2026-09-09T11:43:52Z

HansdG: /* See also */

'''Facility''' is a place where one or more defined activities are carried out, operated by a legal entity, and situated at a [[Location]].

A Facility answers two questions that a Location cannot: ''what happens here'', and ''who runs it''. It is the operational object that compliance statements, certificates, accreditations and evidence attach to.

== Facility Functions ==

A Facility does not have a type. It has one or more '''Functions'''.

This is a deliberate modelling choice. A single type per facility has never held up against the real world, because real sites do several things at once: a plant that produces and warehouses, a site that farms and sells at the gate, an office that does marketing and customer service, a copacker that fills and stores. Forcing one label per site means the model is wrong for most of the estate on day one, and it stays wrong.

A Function is an activity. Because a Facility carries a set of Functions rather than a single label, the model follows reality instead of flattening it, and a site that adds or drops an activity keeps its identity and its history.

=== Function list ===

{| class="wikitable"
! Code !! Function !! Group !! Activity carried out
|-
| FARM || '''Farming''' || Sourcing
| Agricultural activity, where raw materials such as crops or livestock are produced.
|-
| FISH || '''Fishing & Aquaculture''' || Sourcing
| Catching wild fish and shellfish, and rearing aquatic species in controlled water environments.
|-
| FRST || '''Forestry''' || Sourcing
| Growing and harvesting timber and other forest materials from managed or natural woodland.
|-
| MINE || '''Mining''' || Sourcing
| Extraction of natural resources such as minerals, metals or fossil fuels from the Earth.
|-
| EXTR || '''Extraction''' || Sourcing
| Extraction of crude oil from underground reservoirs or from beneath the ocean floor, extraction of natural gas, often found in conjunction with oil extraction, and extraction of sedimentary materials such as sand, gravel or clay, often used in construction or other industrial applications.
|-
| PROC || '''Processing''' || Transformation
| Transformation of raw or recovered materials into intermediate materials. Refining, smelting, pulping, papermaking, glass melting and polymerisation.
|-
| CONV || '''Converting''' || Transformation
| Transformation of intermediate materials into components. Printing, laminating, coating, forming, moulding and cutting. This is where a [[Material Platform]] becomes a packaging component.
|-
| PROD || '''Production''' || Transformation
| Transformation of raw materials into finished goods through manufacturing processes.
|-
| PACK || '''Packaging & Filling''' || Transformation
| Filling products into packaging and assembling the packed unit, whether performed by the brand owner or by a contract manufacturer or copacker.
|-
| WHSE || '''Warehousing''' || Logistics
| Storage of goods, often serving as a hub for inventory management and distribution.
|-
| DIST || '''Distribution''' || Logistics
| Logistics and transportation of goods from production sites or warehouses to other locations, such as retail outlets or end customers.
|-
| SALE || '''Sales''' || Commercial
| Selling products or services directly to consumers or other businesses. Includes retail stores, dealerships and e-commerce distribution points.
|-
| MKTG || '''Marketing''' || Commercial
| Promotion and advertisement of products or services. Includes corporate offices, agencies and regional marketing centres.
|-
| CSVC || '''Customer Service''' || Commercial
| Support and assistance to customers, including handling inquiries, resolving issues and ensuring customer satisfaction.
|-
| RSDV || '''Research & Development (R&D)''' || Support
| Innovation, product development and the testing of new ideas or products. Crucial for sustaining competitive advantage and driving future growth.
|-
| LABO || '''Laboratory & Testing''' || Support
| Analysis and testing of materials, components or products, including the issuing of test reports under an accreditation.
|-
| INSP || '''Inspection & Certification''' || Support
| Auditing, inspection and the issuing of certificates against a scheme or standard.
|-
| ADMN || '''Administration''' || Support
| Corporate and back office activity such as finance, legal, human resources and general management.
|-
| REPR || '''Repair & Reconditioning''' || Circularity
| Repair, refurbishment, cleaning and reconditioning of goods or packaging so they can be used again, including washing lines in reuse systems.
|-
| COLL || '''Collection''' || Circularity
| Gathering used products, packaging or waste from consumers, businesses or public collection points.
|-
| SORT || '''Sorting''' || Circularity
| Separation of collected materials into streams by material, format or quality, preparing them for recycling or recovery.
|-
| RECY || '''Recycling''' || Circularity
| Reprocessing of collected materials into secondary raw materials fit for use in new products or packaging.
|-
| RCVR || '''Recovery & Disposal''' || Circularity
| Energy recovery, treatment and final disposal of materials that are not recycled.
|}

=== Applying functions ===

* A Facility has '''one or more''' Functions. There is no primary Function and no ranking.
* Functions can be added or removed over the life of a Facility '''without''' creating a new Facility. The identity is the operated site, not the activity mix.
* Evidence attaches to the Function that produced it. A test report comes from the Laboratory & Testing Function, a harvest declaration from the Farming Function, a recycled content claim from the Recycling Function.
* The Group column is for navigation and reporting only. It carries no rules and a Facility is never assigned a Group.

== Operator ==

A Facility is always operated by a legal entity, and that operator is what makes the Facility accountable. Site certifications, audit outcomes, permits, accreditations and site level profiles such as an allergen profile are properties of the Facility, not of the Location.

A company can operate facilities at many locations, and can sell or transfer a facility without the location changing at all.

== One facility or several? ==

A Location can host more than one Facility. Use these rules to decide.

* Same operator, one accountable site, several activities: '''one Facility with several Functions'''.
* Different operators on the same Location: '''separate Facilities''', one per operator.
* Same operator but separately certified, audited or permitted as distinct sites: '''separate Facilities''', because the evidence attaches separately.

== Difference between location & facility ==

{| class="wikitable"
! !! Location !! Facility
|-
! Question
| Where || What happens there, and who runs it
|-
! Identity
| GLN, plus extension component for internal locations || Its own identifier, referencing a Location and an operator
|-
! Forms
| Address, point, polygon || One or more Functions
|-
! Carries
| Geography only || Certificates, accreditations, permits, site profiles
|-
! Cardinality
| One Location, many Facilities || One Facility, one Location
|}

The separation earns its keep the moment evidence has to be traced. A harvest happens at a plot with no facility on it. A test report is issued by a laboratory and its accreditation belongs to that laboratory, not to the address. A packaging component is produced at a Facility whose location may be commercially confidential while its country still has to be declared.

== What a Facility is not ==

* '''Not the legal entity that operates it.''' The operator is a separate object with its own identifier.
* '''Not the place it sits on.''' The Location is a separate object and can outlive any Facility on it.
* '''Not a type.''' See [[#Facility Functions]].

== See also ==

* [[Location - TX]]
* [[Material Platform -TX]]
* [[Packaging System] - TX]

[[Category:Taxonomy]]

Facility - TX

2026-09-09T11:43:25Z

HansdG: Created page with "'''Facility''' is a place where one or more defined activities are carried out, operated by a legal entity, and situated at a Location. A Facility answers two questions that a Location cannot: ''what happens here'', and ''who runs it''. It is the operational object that compliance statements, certificates, accreditations and evidence attach to. == Facility Functions == A Facility does not have a type. It has one or more '''Functions'''. This is a deliberate model..."

'''Facility''' is a place where one or more defined activities are carried out, operated by a legal entity, and situated at a [[Location]].

A Facility answers two questions that a Location cannot: ''what happens here'', and ''who runs it''. It is the operational object that compliance statements, certificates, accreditations and evidence attach to.

== Facility Functions ==

A Facility does not have a type. It has one or more '''Functions'''.

This is a deliberate modelling choice. A single type per facility has never held up against the real world, because real sites do several things at once: a plant that produces and warehouses, a site that farms and sells at the gate, an office that does marketing and customer service, a copacker that fills and stores. Forcing one label per site means the model is wrong for most of the estate on day one, and it stays wrong.

A Function is an activity. Because a Facility carries a set of Functions rather than a single label, the model follows reality instead of flattening it, and a site that adds or drops an activity keeps its identity and its history.

=== Function list ===

{| class="wikitable"
! Code !! Function !! Group !! Activity carried out
|-
| FARM || '''Farming''' || Sourcing
| Agricultural activity, where raw materials such as crops or livestock are produced.
|-
| FISH || '''Fishing & Aquaculture''' || Sourcing
| Catching wild fish and shellfish, and rearing aquatic species in controlled water environments.
|-
| FRST || '''Forestry''' || Sourcing
| Growing and harvesting timber and other forest materials from managed or natural woodland.
|-
| MINE || '''Mining''' || Sourcing
| Extraction of natural resources such as minerals, metals or fossil fuels from the Earth.
|-
| EXTR || '''Extraction''' || Sourcing
| Extraction of crude oil from underground reservoirs or from beneath the ocean floor, extraction of natural gas, often found in conjunction with oil extraction, and extraction of sedimentary materials such as sand, gravel or clay, often used in construction or other industrial applications.
|-
| PROC || '''Processing''' || Transformation
| Transformation of raw or recovered materials into intermediate materials. Refining, smelting, pulping, papermaking, glass melting and polymerisation.
|-
| CONV || '''Converting''' || Transformation
| Transformation of intermediate materials into components. Printing, laminating, coating, forming, moulding and cutting. This is where a [[Material Platform]] becomes a packaging component.
|-
| PROD || '''Production''' || Transformation
| Transformation of raw materials into finished goods through manufacturing processes.
|-
| PACK || '''Packaging & Filling''' || Transformation
| Filling products into packaging and assembling the packed unit, whether performed by the brand owner or by a contract manufacturer or copacker.
|-
| WHSE || '''Warehousing''' || Logistics
| Storage of goods, often serving as a hub for inventory management and distribution.
|-
| DIST || '''Distribution''' || Logistics
| Logistics and transportation of goods from production sites or warehouses to other locations, such as retail outlets or end customers.
|-
| SALE || '''Sales''' || Commercial
| Selling products or services directly to consumers or other businesses. Includes retail stores, dealerships and e-commerce distribution points.
|-
| MKTG || '''Marketing''' || Commercial
| Promotion and advertisement of products or services. Includes corporate offices, agencies and regional marketing centres.
|-
| CSVC || '''Customer Service''' || Commercial
| Support and assistance to customers, including handling inquiries, resolving issues and ensuring customer satisfaction.
|-
| RSDV || '''Research & Development (R&D)''' || Support
| Innovation, product development and the testing of new ideas or products. Crucial for sustaining competitive advantage and driving future growth.
|-
| LABO || '''Laboratory & Testing''' || Support
| Analysis and testing of materials, components or products, including the issuing of test reports under an accreditation.
|-
| INSP || '''Inspection & Certification''' || Support
| Auditing, inspection and the issuing of certificates against a scheme or standard.
|-
| ADMN || '''Administration''' || Support
| Corporate and back office activity such as finance, legal, human resources and general management.
|-
| REPR || '''Repair & Reconditioning''' || Circularity
| Repair, refurbishment, cleaning and reconditioning of goods or packaging so they can be used again, including washing lines in reuse systems.
|-
| COLL || '''Collection''' || Circularity
| Gathering used products, packaging or waste from consumers, businesses or public collection points.
|-
| SORT || '''Sorting''' || Circularity
| Separation of collected materials into streams by material, format or quality, preparing them for recycling or recovery.
|-
| RECY || '''Recycling''' || Circularity
| Reprocessing of collected materials into secondary raw materials fit for use in new products or packaging.
|-
| RCVR || '''Recovery & Disposal''' || Circularity
| Energy recovery, treatment and final disposal of materials that are not recycled.
|}

=== Applying functions ===

* A Facility has '''one or more''' Functions. There is no primary Function and no ranking.
* Functions can be added or removed over the life of a Facility '''without''' creating a new Facility. The identity is the operated site, not the activity mix.
* Evidence attaches to the Function that produced it. A test report comes from the Laboratory & Testing Function, a harvest declaration from the Farming Function, a recycled content claim from the Recycling Function.
* The Group column is for navigation and reporting only. It carries no rules and a Facility is never assigned a Group.

== Operator ==

A Facility is always operated by a legal entity, and that operator is what makes the Facility accountable. Site certifications, audit outcomes, permits, accreditations and site level profiles such as an allergen profile are properties of the Facility, not of the Location.

A company can operate facilities at many locations, and can sell or transfer a facility without the location changing at all.

== One facility or several? ==

A Location can host more than one Facility. Use these rules to decide.

* Same operator, one accountable site, several activities: '''one Facility with several Functions'''.
* Different operators on the same Location: '''separate Facilities''', one per operator.
* Same operator but separately certified, audited or permitted as distinct sites: '''separate Facilities''', because the evidence attaches separately.

== Difference between location & facility ==

{| class="wikitable"
! !! Location !! Facility
|-
! Question
| Where || What happens there, and who runs it
|-
! Identity
| GLN, plus extension component for internal locations || Its own identifier, referencing a Location and an operator
|-
! Forms
| Address, point, polygon || One or more Functions
|-
! Carries
| Geography only || Certificates, accreditations, permits, site profiles
|-
! Cardinality
| One Location, many Facilities || One Facility, one Location
|}

The separation earns its keep the moment evidence has to be traced. A harvest happens at a plot with no facility on it. A test report is issued by a laboratory and its accreditation belongs to that laboratory, not to the address. A packaging component is produced at a Facility whose location may be commercially confidential while its country still has to be declared.

== What a Facility is not ==

* '''Not the legal entity that operates it.''' The operator is a separate object with its own identifier.
* '''Not the place it sits on.''' The Location is a separate object and can outlive any Facility on it.
* '''Not a type.''' See [[#Facility Functions]].

== See also ==

* [[Location - TX]]
* [[Material Platform -TX]]
* [[Packaging System] - TX]

[[Category:Data model]]
[[Category:Identifiers]]

Location - TX

2026-09-09T11:38:24Z

HansdG:

'''Location''' is a place on Earth that can be pointed at on a map, expressed as an address, a coordinate or a bounded area, independent of what happens there or who owns it.

A Location answers one question only: ''where''. It carries no assumption about activity, ownership or legal responsibility. If it can be found on a map, it is a Location. What happens at that place is modelled separately, as a [[Facility]].

== Forms ==

A Location is expressed in one of three forms. The form follows the precision the use case needs.

; Address
: A postal address in the national addressing format, resolvable to a country and a region.

; Point
: Latitude and longitude in a stated reference system (WGS84), optionally with altitude, or an equivalent point encoding such as What3Words or a Plus Code.

; Area
: A bounded polygon, used where a point is not enough. Agricultural and forestry plots are the standard case: a field, an orchard block, a forest parcel. Deforestation-free sourcing evidence is the clearest driver, where plots above a size threshold have to be given as a polygon rather than a point.

== Identification ==

The identifier for a Location is the '''GLN''' (Global Location Number). Where several distinct places sit inside one GLN, the '''GLN extension component''' identifies the internal location.

A GLN is also used in practice to identify a party. That overlap is precisely why a Location and a legal entity are kept as separate objects in the model. See [[#What a Location is not]].

== Difference between location & facility ==

{| class="wikitable"
! !! Location !! Facility
|-
! Question
| Where || What happens there, and who runs it
|-
! Identity
| GLN, plus extension component for internal locations || Its own identifier, referencing a Location and an operator
|-
! Forms
| Address, point, polygon || Typed activity site
|-
! Carries
| Geography only || Certificates, accreditations, permits, site profiles
|-
! Cardinality
| One Location, many Facilities || One Facility, one Location
|}

The separation earns its keep the moment evidence has to be traced. A harvest happens at a plot with no facility on it. A test report is issued by a laboratory, which is a Facility, and its accreditation belongs to that laboratory and not to the address. A packaging component is produced at a production Facility whose location may be commercially confidential while its country still has to be declared.

Collapsing the two forces a choice, per case, about which meaning the field carries. That choice is exactly what breaks when the data crosses a company boundary.

== What a Location is not ==

* '''Not a company.''' A legal entity is a separate object with its own identifier.
* '''Not an activity.''' A Location with nothing happening on it is still a valid Location: a harvested plot, a mine, a landfill, a collection point.

== Examples ==

* The postal address of a production site.
* The coordinates of a collection point.
* The polygon of a coffee plot delivered as deforestation-free sourcing evidence.
* A warehouse dock identified by a GLN extension component under the site GLN.

== See also ==

* [[Facility]]
* [[Material Platform]]
* [[Packaging System]]
* [[IMDE]]

[[Category:Data model]]
[[Category:Identifiers]]

== Definition ==
A Location is a specific place on Earth that serves as a critical element in the supply chain and business operations. In the context of the IMDE (Interoperable Multi-Dimensional Exchange) framework, a location typically refers to a supply location, which plays a vital role in various stages of the production and distribution process.

== Core Concept ==
Locations are not just geographical points; they are strategic assets that support various functions within an organization. Each location is defined by its physical presence, identification, and associated functions, which can include but are not limited to farming, mining, production, warehousing, distribution, sales, marketing, and research & development.

== Key Attributes ==
*'''Location IDs''': Unique identifiers that provide precise and standardized location information, facilitating interoperability and data exchange. Common methods include:
**What3Words: A geocoding system that divides the world into a grid of 3m x 3m squares, each identified by a unique combination of three words. This method allows for easy communication and pinpointing of exact locations.
**Global Location Number (GLN): A globally recognized identifier used in supply chain management to uniquely identify locations. A GLN can represent any physical location involved in business transactions, such as production sites, warehouses, or retail outlets.
**Geographical Coordinates: The exact latitude and longitude that pinpoint the location on Earth.
*'''Address''': A human-readable description of the location, including street address, city, state/province, and country.

== Usage Context ==
In the IMDE framework, locations are integral to the interoperability of data across different layers. Accurate and consistent location data, including standardized identification methods such as What3Words or GLNs, enables seamless integration and exchange of information related to supply chain management, resource allocation, and strategic planning. Locations can be linked to various entities, such as facilities, suppliers, customers, or internal departments, to provide a holistic view of the business operations across multiple geographies.

==Related==
* [[Geolocation_-_IM|GEO Location]]
* [[LCAterms_-_TX|LCAterms]]
* [[ID_-_Identifier_Types|Identifier Types]]

[[Category: Taxonomy]]

Location - TX

2026-09-09T11:37:49Z

HansdG:

== Definition ==
A Location is a specific place on Earth that serves as a critical element in the supply chain and business operations. In the context of the IMDE (Interoperable Multi-Dimensional Exchange) framework, a location typically refers to a supply location, which plays a vital role in various stages of the production and distribution process.

== Core Concept ==
Locations are not just geographical points; they are strategic assets that support various functions within an organization. Each location is defined by its physical presence, identification, and associated functions, which can include but are not limited to farming, mining, production, warehousing, distribution, sales, marketing, and research & development.

== Key Attributes ==
*'''Location IDs''': Unique identifiers that provide precise and standardized location information, facilitating interoperability and data exchange. Common methods include:
**What3Words: A geocoding system that divides the world into a grid of 3m x 3m squares, each identified by a unique combination of three words. This method allows for easy communication and pinpointing of exact locations.
**Global Location Number (GLN): A globally recognized identifier used in supply chain management to uniquely identify locations. A GLN can represent any physical location involved in business transactions, such as production sites, warehouses, or retail outlets.
**Geographical Coordinates: The exact latitude and longitude that pinpoint the location on Earth.
*'''Address''': A human-readable description of the location, including street address, city, state/province, and country.

== Usage Context ==
In the IMDE framework, locations are integral to the interoperability of data across different layers. Accurate and consistent location data, including standardized identification methods such as What3Words or GLNs, enables seamless integration and exchange of information related to supply chain management, resource allocation, and strategic planning. Locations can be linked to various entities, such as facilities, suppliers, customers, or internal departments, to provide a holistic view of the business operations across multiple geographies.

==Related==
* [[Geolocation_-_IM|GEO Location]]
* [[LCAterms_-_TX|LCAterms]]
* [[ID_-_Identifier_Types|Identifier Types]]

[[Category: Taxonomy]]

Material System - TX

2026-09-09T11:32:55Z

HansdG:

'''Material Platform:''' a commercial material construction that a supplier uses across a whole range of packaging components, and that carries one compliance profile. It is usually already known in the market under a brand, range or technology name.

=== Full definition ===

A Material Platform is a commercial or functional material family that packaging components are built on. It can be a single material or a construction of several (layers, coatings, print, technologies). Examples are a specific PET resin, a glass furnace profile, a board with a defined ink system, a laminate of up to seven layers.

The defining property is that compliance is a property of the material construction, not of the individual component. One furnace produces thousands of bottles and jars, one resin produces hundreds of bottle formats, one board plus ink system produces thousands of printed boxes. In each case the components differ in size, shape, cutter guide and print image, and the compliance profile behind them is one and the same. That is why compliance is in many cases defined at Material Platform level, while the requests arrive at component level.

Material Platforms are not an abstraction invented for compliance. They already exist and they already have names, because suppliers market them as products: PrintKote, Stretotheen, Optilayer, Nitro Cans. The name the industry already uses is the name of the platform.

In data terms each Material Platform gets one identity: one Material Platform ID, one compliance data set and one stable Digital Link that resolves to that data set. What is exchanged is the compliance profile, not the composition, so a supplier can prove conformity without revealing the recipe.

What makes it a separate platform: a change in material construction or ink system that changes the compliance profile. Format, dimension, cutter guide and print image do not create a new Material Platform.

What it is not: not a materials database and not a raw-material specification. The compliance profile is the point, and the identity is what makes it shareable across companies.

The number that carries it: 300 customers times 30 printed boxes is 9,000 packaging items and potentially 9,000 compliance questions. If they run on the same board, ink system and compliance profile, that is one Material Platform and one compliance answer. Do not assess compliance 9,000 times, assess the Material Platform once.

[[Category: Taxonomy]]

Material System - TX

2026-09-09T11:26:07Z

HansdG: Created page with "Material Platform A Material Platform is the unit of identity for a packaging material, one level below the Packaging Master. It is where everything that is true about the material itself is recorded and maintained once: composition, substances of concern, test reports, recyclability inputs, recycled content and its chain of custody, each carrying its method, version and date. A Packaging Master references the Material Platform instead of copying its data. What is spec..."

Material Platform

A Material Platform is the unit of identity for a packaging material, one level below the Packaging Master. It is where everything that is true about the material itself is recorded and maintained once: composition, substances of concern, test reports, recyclability inputs, recycled content and its chain of custody, each carrying its method, version and date.

A Packaging Master references the Material Platform instead of copying its data. What is specific to the master, such as geometry, ink system and weight per component, stays on the master. What is true about the material, regardless of who buys it or what it ends up in, lives on the platform.

The design is deliberately shared rather than customer specific. The same film, the same board grade or the same closure is currently assessed and documented hundreds of times over across the market. A shared Material Platform turns that into work done once, with a single traceable source of evidence.

'''What it is not:''' not a materials database and not a supplier portal. The difference is identity. A database stores records about materials; a Material Platform gives the material an identity that dossiers, declarations and assessments can point at, and that stays valid across company boundaries.

[[Category: Taxonomy]]

Category:Code List

2026-08-16T15:34:31Z

HansdG:

We started an online code list viewer which you can find at [https://metadata.imde.io/codelists IMDE Online code list viewer]

On this page you can
* See all code lists in 4 languages (English, German, French Dutch)
* Download all codelists in Excel (or copy to Excel)
* Subscribe to updates (per mailinglist)
* Request new list values.

Category:Code List

2026-08-16T15:33:47Z

HansdG:

We started an online code list viewer which you can find at [https://metadata.imde.io/codelists|https://metadata.imde.io/codelists]

On this page you can
* See all code lists in 4 languages (English, German, French Dutch)
* Download all codelists in Excel (or copy to Excel)
* Subscribe to updates (per mailinglist)
* Request new list values.

Category:Code List

2026-08-16T15:33:13Z

HansdG:

We started an online code list viewer which you can find at [[https://metadata.imde.io/codelists|https://metadata.imde.io/codelists]]

On this page you can
* See all code lists in 4 languages (English, German, French Dutch)
* Download all codelists in Excel (or copy to Excel)
* Subscribe to updates (per mailinglist)
* Request new list values.

Category:Code List

2026-08-16T15:32:56Z

HansdG:

We started an online code list viewer which you can find at [[https://metadata.imde.io/codelists]]

On this page you can
* See all code lists in 4 languages (English, German, French Dutch)
* Download all codelists in Excel (or copy to Excel)
* Subscribe to updates (per mailinglist)
* Request new list values.

Category:Code List

2026-08-16T15:32:28Z

HansdG:

We started an online code list viewer which you can find at http://https://metadata.imde.io/codelists

On this page you can
* See all code lists in 4 languages (English, German, French Dutch)
* Download all codelists in Excel (or copy to Excel)
* Subscribe to updates (per mailinglist)
* Request new list values.

DataTopic Measurements

2026-06-21T11:53:22Z

HansdG:

==Version 2 (Proposed)==
[[DataContainer - Item|Part of DataContainer: Item]] and, from version 2.0, reusable across other containers (see [[DataContainers and DataTopics - DS]]).

'''Measurements''' covers Trade Item measurements (the smallest rectangular box fitting around the item, plus gross weight), Product measurements (net weight, content, drained weight and product states such as out of pack or in use), and Packaging measurements (shape aware dimensions, packaging weight, nominal capacity and material thickness). The information model is described on [[Measurements - IM]].

From version 2.0 the topic is included per container and selected by a '''Profile''', so the same schema is reused on a Sales Unit, a Packaging Assembly Unit, an Element, a Material or a Composite Material. See the [[#Changes from version 1.1|migration notes]] below before upgrading.

== Structure ==

The topic is a set of optional '''blocks'''. A Profile states which blocks apply for a given container.

{| class="wikitable"
! Block !! Contents
|-
| BaseUnitOfMeasure || Base unit for the block (IMDE Unit of Measure code list)
|-
| Outershape || Packaging shape that drives the dimension fields (Box, Cylinder, Sheet / Film / Band, Cord, Sphere)
|-
| Dimensions || Length, Width, Height, Depth, Diameter
|-
| Weights || GrossWeight, NetWeight, TareWeight, DrainedWeight, PackagingWeight
|-
| NettoContents || One or more NettoContent values
|-
| Capacity || NominalCapacity (Rigid Containers family only)
|-
| Thickness || Nominal, Minimum, Maximum (material and composite layer)
|-
| AlternativeMeasurements || Product states, each tagged with a Product Measurement Type
|}

== Profiles ==

{| class="wikitable"
! Profile !! Container Type !! Blocks
|-
| TradeItem || Item (Sales, Grouped, Transport Unit) || Dimensions, Weights (gross)
|-
| Product || Item (Product) || Weights (net, drained), NettoContents, AlternativeMeasurements
|-
| Packaging || Packaging Assembly Unit, Packaging Element || Outershape, Dimensions, Weights (packaging), Capacity
|-
| MaterialThickness || Packaging Material, Composite Material || Thickness
|}

The XSD validates structure; the Schematron profile rules enforce which blocks each Profile requires or forbids.

== Sample XML ==

A single Packaging Assembly Unit (a bottle from a supplier), reusing the topic at object level (Packaging) and material level (MaterialThickness).

<syntaxhighlight lang="xml">
<PackagingAssemblyUnit Type="PackagingAssemblyUnit" GTIN="08712345555014"
PackagingTypeFamily="RIGID_CONTAINER"
xmlns="https://imde.io/schema/azlon/2.0/item"
xmlns:m="https://imde.io/schema/azlon/2.0/measurements">
<m:Measurements Profile="Packaging">
<m:BaseUnitOfMeasure Type="IMDE">MMT</m:BaseUnitOfMeasure>
<m:Outershape>Cylinder</m:Outershape>
<m:Dimensions>
<m:Diameter Value="65"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Diameter>
<m:Height Value="223"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Height>
</m:Dimensions>
<m:Weights>
<m:PackagingWeight Value="22"><m:Units><m:Unit Type="DataReceiver">Gr</m:Unit></m:Units></m:PackagingWeight>
</m:Weights>
<m:Capacity>
<m:NominalCapacity Value="500"><m:Units><m:Unit Type="DataReceiver">Ml</m:Unit></m:Units></m:NominalCapacity>
</m:Capacity>
</m:Measurements>
<PackagingElement>
<PackagingMaterial MaterialType="rPET">
<m:Measurements Profile="MaterialThickness">
<m:Thickness>
<m:Nominal Value="0.30"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Nominal>
</m:Thickness>
</m:Measurements>
</PackagingMaterial>
</PackagingElement>
</PackagingAssemblyUnit>
</syntaxhighlight>

A second sample (a television in a box) shows the topic reused across nested containers: Sales Unit, Product, and three Packaging Assembly Units down to composite material layers.

== Downloads ==

* Measurements topic XSD, version 2.0: https://imde.io/schema/azlon/2.0/measurements.xsd
* Container XSD, version 2.0: https://imde.io/schema/azlon/2.0/item.xsd
* Profile rules (Schematron): https://imde.io/schema/azlon/2.0/measurements-profiles.sch
* Sample XML, bottle Packaging Assembly Unit, version 2.0
* Sample XML, television in a box, version 2.0
* Code lists: IMDE_UnitofMeasureCode, ProductMeasurementType, ShapeType, ContainerType, PackagingTypeFamily

Old versions:

* XSD version 1.1: https://imde.io/schema/azlon/1.1/measurements.xsd
* XSD version 1.0: https://imde.io/schema/azlon/1.0/measurements.xsd

== Changes from version 1.1 ==

Version 1.1 is live. Version 2.0 keeps all version 1.1 content valid but introduces a new namespace, so every consumer must update the schema reference. Please plan the change with your trading partners.

=== Namespace and schema location ===

{| class="wikitable"
! !! Version 1.1 !! Version 2.0
|-
| Topic namespace || https://imde.io/schema/azlon/1.1/measurements || https://imde.io/schema/azlon/2.0/measurements
|-
| Container schema || (Measurements included in Item) || https://imde.io/schema/azlon/2.0/item
|}

=== What is new (additive, non breaking) ===

* The topic is reused across containers (Item, Packaging Assembly Unit, Packaging Element, Packaging Material, Composite Material), not only Item.
* New '''Profile''' attribute on Measurements: TradeItem, Product, Packaging, MaterialThickness. Profile is optional; if it is absent, treat the block as a legacy flat Measurements (Trade Item plus Product).
* New '''Outershape''' element for packaging.
* New blocks: '''Capacity''' (NominalCapacity), '''Thickness''' (Nominal, Minimum, Maximum) and '''AlternativeMeasurements''' (each tagged with a Product Measurement Type).
* New '''Weights''' members: NetWeight, TareWeight, PackagingWeight. GrossWeight and DrainedWeight are unchanged.
* New '''Dimensions''' members: Length and Diameter. Height, Width and Depth are unchanged.

=== Naming and deprecation ===

* Version 1.1 '''NettoWeight''' is retained as a deprecated alias of '''NetWeight'''. Senders should move to NetWeight; receivers should accept both during the transition.
* NettoContents and NettoContent are unchanged.

=== Element mapping ===

{| class="wikitable"
! Version 1.1 !! Version 2.0 !! Note
|-
| NettoWeight || NetWeight || NettoWeight kept as a deprecated alias
|-
| Dimensions: Depth, Height, Width || same || unchanged
|-
| GrossWeight, DrainedWeight || same || unchanged
|-
| NettoContents, NettoContent || same || unchanged
|-
| (none) || Outershape, Capacity, Thickness, AlternativeMeasurements || new blocks
|-
| (none) || NetWeight, TareWeight, PackagingWeight, Length, Diameter || new members
|-
| Measurements under Item only || Measurements under any container, with Profile || new reuse model
|}

=== Action for the ecosystem ===

* Point messages and validators at the version 2.0 namespace and XSD. A version 1.1 message converts by changing the namespace and, where used, renaming NettoWeight to NetWeight.
* Version 1.1 endpoints remain available during the transition period. New blocks and measurements at packaging, material or composite level require version 2.0.
* Weight identity to be aware of: GrossWeight (Trade Item) = NetWeight (Product) + TareWeight, where TareWeight is the sum of PackagingWeight across the packaging.

[[Category:Data Schema]]

==Version 1 (Current version)==
[[DataContainer_-_Item|Part of DataContainer: Item]]

Measurements covers both trade item measurements (defined as the smallest rectangular fitting around an item) and additional product measurements related to the product out of pack, installed or in use.

BaseUnitOfMeasure is added in version 1.1.

<pre>
<Measurements xmlns="https://imde.io/schema/azlon/1.1/measurements" xsi:schemaLocation="https://imde.io/schema/azlon/1.1/measurements https://imde.io/schema/azlon/1.1/measurements.xsd">

<BaseUnitOfMeasure Type="IMDE">MMT</BaseUnitOfMeasure>
<Dimensions>
<Depth Value="105.8">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Depth>
<Depth Value="105.8">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Depth>
<Height Value="108.7">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Height>
<Width Value="105.8">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Width>
</Dimensions>
<Weights>
<GrossWeight Value="665.3">
<Units>
<Unit Type="DataReceiver">Gr</Unit>
</Units>
</GrossWeight>
<NettoWeight Value="650">
<Units>
<Unit Type="DataReceiver">Gr</Unit>
</Units>
</NettoWeight>
<DrainedWeight Value="645">
<Units>
<Unit Type="DataReceiver">Gr</Unit>
</Units>
</DrainedWeight>
</Weights>
<NettoContents>
<NettoContent Value="6">
<Units>
<Unit Type="DataReceiver">Pce</Unit>
</Units>
</NettoContent>
<NettoContent Value="1550">
<Units>
<Unit Type="DataReceiver">Ml</Unit>
</Units>
</NettoContent>
</NettoContents>
</Measurements>
</pre>

===Downloads===
* [https://imde.io/schema/Sample%20XML%20message%20DataTopic%20Measurements.xml Sample XML] version 1.1
* [https://imde.io/schema/azlon/1.1/measurements.xsd XSD] version 1.1
* [https://imde.io/schema/codelists/IMDE_UnitofMeasureCode.xml Codelist IMDE_UnitofMeasureCode]
* [https://imde.io/schema/azlon/1.0/codelists/unitType.xsd Codelist unitType]

Old versions:
* [https://imde.io/schema/azlon/1.0/measurements.xsd XSD] version 1.0

Category:Data Schema

2026-06-21T10:23:31Z

HansdG: Created blank page

DataContainers and DataTopics - DS

2026-06-21T10:22:48Z

HansdG: Created page with "This page explains the key structure of IMDE data schemas: how reusable '''DataTopics''' are included into '''DataContainers''' and constrained by '''Profiles''', so that the same schema can be reused at every level of the trade and packaging hierarchy and across the supply chain. The Measurements topic is used as the worked example throughout. == Key concepts == {| class="wikitable" ! Term !! Meaning !! Status |- | DataContainer || The entity or..."

This page explains the key structure of IMDE data schemas: how reusable '''DataTopics''' are included into '''DataContainers''' and constrained by '''Profiles''', so that the same schema can be reused at every level of the trade and packaging hierarchy and across the supply chain. The [[Measurements - IM|Measurements]] topic is used as the worked example throughout.

== Key concepts ==

{| class="wikitable"
! Term !! Meaning !! Status
|-
| DataContainer || The entity or host that includes DataTopics and carries identity and role. || exists (extend)
|-
| Container Type || What the container is: Item (Trade Item / Product), Packaging Assembly Unit, Packaging Element, Packaging Material, Composite Material, Party, Person. || new code list
|-
| DataTopic Measurements || The single reusable measurement topic, included per container. || exists (extend)
|-
| Measurement Block || The includable parts inside the topic: Dimensions, Weights, Contents, Capacity, Thickness, AlternativeMeasurements. || partly exists
|-
| Measurement (atomic type) || A value plus a unit, reused everywhere. || exists
|-
| Profile || The rule set saying which blocks are valid or required for a given Container Type and supply chain position. || new
|-
| Object level vs component level || Measurement on the container itself versus on its child containers. || terminology
|}

== DataContainer ==

A '''DataContainer''' is the entity or host that includes one or more DataTopics. It carries identity, such as a GTIN, and a role. A DataContainer can contain child DataContainers, which forms both the trade item hierarchy (for example a case that contains bottles) and the packaging decomposition (a Packaging Assembly Unit that contains Packaging Elements, Materials and Composite Materials).

The '''Container Type''' states what the container is. It is a new code list (CONTAINER_TYPE).

{| class="wikitable"
! Container Type !! Typical role
|-
| Item || Trade Item (Sales, Grouped or Transport Unit) or Product
|-
| Packaging Assembly Unit || A physical packaging component or SKU item in a Bill of Materials
|-
| Packaging Element || Lowest functional packaging part
|-
| Packaging Material || One or more materials that make up an element
|-
| Composite Material || An individual layer within a composite material
|-
| Party || An organisation (uncommon for measurements, supported for reuse)
|-
| Person || An individual (uncommon for measurements, supported for reuse)
|}

A single physical object can appear as more than one container depending on its role in the supply chain. An empty bottle is a Packaging Assembly Unit inside a filled product, and at the same time a Trade Item when the bottle supplier sells it. It is one object that is described by two container roles, reusing the same topic.

== DataTopic ==

A '''DataTopic''' is a modular, reusable block of structure that is modelled once and expressed across the IMDE layers. A topic is included per container. Depending on the position in the supply chain, topics are included or excluded, and the same topic can be reused across different Container Types. Measurements is one DataTopic; other topics (for example composition or compliance) are included alongside it on the same container.

== Measurement Block ==

Within a topic, '''blocks''' are the includable parts. For Measurements the blocks are Dimensions, Weights, Contents, Capacity, Thickness and AlternativeMeasurements. All blocks are optional in the base schema. A Profile decides which blocks apply for a given container.

== Measurement (atomic type) ==

The atomic '''Measurement''' is a value plus a unit of measure, drawn from the Unit of Measure code list. Every block reuses this one type, which keeps Trade Item, Product, Packaging and Material Thickness measurements consistent and makes schema generation in XLS, XML and JSON straightforward.

== Profile ==

A '''Profile''' is the rule set that says which blocks are valid or required for a given Container Type and supply chain position. The base schema stays permissive so one schema validates everywhere; the Profile enforces what is allowed and required.

{| class="wikitable"
! Profile !! Container Type !! Blocks typically populated
|-
| TradeItem || Item (Sales / Grouped / Transport Unit) || Dimensions, Weights (gross)
|-
| Product || Item (Product) || Weights (net, drained), Contents, AlternativeMeasurements
|-
| Packaging || Packaging Assembly Unit, Packaging Element || Dimensions (shape aware), Weights (packaging), Capacity
|-
| MaterialThickness || Packaging Material, Composite Material || Thickness
|}

== Object level and component level ==

'''Object level''' is a measurement on the container itself. '''Component level''' is a measurement on its child containers. A Packaging Assembly Unit carries object level packaging measurements (shape, dimensions, packaging weight, and capacity for rigid containers), and component level measurements on its Packaging Elements, Packaging Materials and Composite Materials, where material thickness lives.

== Reuse across the supply chain ==

Because topics are included or excluded per container, the position in the supply chain decides what travels in a message. The structure does not change; only the included topics and populated blocks change.

{| class="wikitable"
! Position !! Container in focus !! Measurements included
|-
| Primary material or converter || Packaging Material, Composite Material || MaterialThickness; packaging weight
|-
| Component supplier (SIM intake) || Packaging Assembly Unit || Packaging at object level plus the decomposition to material thickness
|-
| Brand owner (PIM) || Sales, Grouped and Transport Units || Trade Item and Product; Packaging via the Bill of Materials
|-
| Retailer (PPWR manufacturer, EPR producer) || Sales Unit || Trade Item and Product
|}

== Examples ==

The two examples below reuse the same Measurements topic. Namespaces are illustrative.

=== Television in a box (nested containers) ===

One Sales Unit (Item) holds the Trade Item measurements, a Product (the television) in the Bill of Materials, and a Packaging Unit with three Packaging Assembly Units. The outer box is decomposed down to composite material layers.

<syntaxhighlight lang="xml">
<Item Type="Item" Role="TradeItem" GTIN="08712345000018">
<m:Measurements Profile="TradeItem"></m:Measurements>
<BillOfMaterials>
<Product Type="Item" Role="Product" GTIN="08712345111016">
<m:Measurements Profile="Product">


</m:Measurements>
</Product>
<PackagingUnit>
<PackagingAssemblyUnit PackagingTypeFamily="RIGID_BOX">
<m:Measurements Profile="Packaging"></m:Measurements>
<PackagingElement>
<PackagingMaterial MaterialType="CorrugatedBoard" Composite="true">
<m:Measurements Profile="MaterialThickness"></m:Measurements>
<CompositeMaterial Layer="OuterLiner">
<m:Measurements Profile="MaterialThickness"></m:Measurements>
</CompositeMaterial>

</PackagingMaterial>
</PackagingElement>
</PackagingAssemblyUnit>
<PackagingAssemblyUnit PackagingTypeFamily="MOULDED_FIBRE"></PackagingAssemblyUnit>
<PackagingAssemblyUnit PackagingTypeFamily="FLEXIBLE"></PackagingAssemblyUnit>
</PackagingUnit>
</BillOfMaterials>
</Item>
</syntaxhighlight>

=== Bottle as a standalone Packaging Assembly Unit ===

The same topic, on a different root container, as received from a bottle supplier. No Sales Unit and no Bill of Materials. A bottle is a Rigid Containers family, so the object level carries Nominal Capacity.

<syntaxhighlight lang="xml">
<PackagingAssemblyUnit Type="PackagingAssemblyUnit" GTIN="08712345555014"
PackagingTypeFamily="RIGID_CONTAINER">
<m:Measurements Profile="Packaging">
<m:Outershape>Cylinder</m:Outershape>
<m:Dimensions>
<m:Diameter Value="65"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Diameter>
<m:Height Value="223"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Height>
</m:Dimensions>
<m:Weights>
<m:PackagingWeight Value="22"><m:Units><m:Unit Type="DataReceiver">Gr</m:Unit></m:Units></m:PackagingWeight>
</m:Weights>
<m:Capacity>
<m:NominalCapacity Value="500"><m:Units><m:Unit Type="DataReceiver">Ml</m:Unit></m:Units></m:NominalCapacity>
</m:Capacity>
</m:Measurements>
<PackagingElement>
<PackagingMaterial MaterialType="rPET">
<m:Measurements Profile="MaterialThickness">
<m:Thickness>
<m:Nominal Value="0.30"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Nominal>
</m:Thickness>
</m:Measurements>
</PackagingMaterial>
</PackagingElement>
</PackagingAssemblyUnit>
</syntaxhighlight>

The empty bottle, when sold by the supplier, is also a Trade Item, so the same container can include the Measurements topic a second time with the TradeItem profile. This is the reuse principle: one topic, many containers, selected by Profile and by supply chain position.

[[Category:Data Schema]]

Layer - Data Schema

2026-06-21T09:55:45Z

HansdG: /* Data Schema and Data Containers */

== IMDE Data Schemas==
IMDE goal is to support multiple versioned DataSchemas (backwards and forwards compatible) for all data points relevant to manufacture, distribute, commercialize and re-cycle discrete products (e.g. food, beverages, fashion, electronics, power tools, adhesives, pet food, personal care, home care, et cetera).

The IMDE DataSchema layer is implementation agnostic so that the defined DataSchemas can be implemented in DataPools, Data Networks or Digital Catalog standards (like [https://fabdis.fr/ FABDIS] or [https://www.bme.de/ BMECAT]).

==Data Schema and Data Containers==

IMDE supports the exchange of data related to the following entities via so called DataContainers. A data container contains a message or file related to one or more entities of the same type.

* '''[[DataContainer_-_Item|Item/Object]]''': Use to exchange data related to physical items. Items can be transported by car, truck, plane or boat. There are multiple types of items:
** ''Handling unit'' (e.g. a physical package or container that is used to transport, store or handle goods. It could be a pallet, a box, a crate or a bundle, and it is often used to group items together to facilitate handling, storage and transport. A cases, cartons, display)
** ''Finished goods'' (e.g. TV, mobile phone, bottle of shampoo, ready to eat salad, smoothie in plastic bottle)
** Parts/Components
*** ''Semi-finished good / Sub-assemblies'' (e.g. bottled beer without labels, frozen fries not yet packaged), usually produced by the brandowner/product manufacturer).
*** ''Components'' (e.g packaging components like foil & cans and food components like herb-mixes or electronic components)
*** ''Raw material'' (e.g. eggs, raw milk, salt, oil, tree trunk, grain, iron)
* '''[[DataContainer_-_Bill_of_materials|Bill of materials]]''': Hierarchies of physical items, for example full trade hierarchy (Pallet, case, finished good) or manufacturing BOMs (Finished Good, Components/Parts, Raw Materials)
* '''[[Trade_hierarchies|Trade hierarchies]]''': In the IMDE format, trade hierarchies are modelled as part of the Bill of materials
* '''Party/Legal Entity''': Organizations and corporations like Manufacturers, Retailers, NGOs and government bodies. Easy check: Legal entities can be sued in court
* '''Location''': Any place on earth where activities take place, like farms, forests, production facilities, distribution centers and retail stores). Easy check: Locations can be found on Google Maps.
* '''Brand''': Covers both product and organizational brands.
* '''Person''': Individuals/humans like employees and consumers)
* '''[[Transactions]]''': Production Runs, Orders, Shipments
*

Every entity will have a defined '''DataContainer''' within IMDE framework to exchange data related to this entity (e.g. product information for materials). Every DataContainer will have a header which includes an [[Layer_-_Identifiers|identifier]] which will enable machines to process the data in a fully automatic way.

===One or more Data Topics per container===
The core principles of the IMDE framework are interoperable and modular. That also applies to data schemas (data message formats and spreadsheet templates). Within the IMDE framework industry groups will work on defining DataTopics. A DataTopic will contain all datapoints covering a specific topic. Examples are: Packaging Materials, Allergens, Marks or Claims. Any data message or template can contain one or more DataTopics, depending on the needs in that part of the supply chain. For example
* A Packaging Component Supplier will include the Packaging Material Datatopic in a data message that is send to a CPG brand owner.
* A Herb Mix Supplier will include all Food recipe related DataTopics like Allergens, Ingredients and Nutrients
* A Adhesive supplier will include all Formula related DataTopics like Reach
* A CPG/FMCG in Food will data related to the "consumer product" which will Food and Packaging related DataTopics in the data message that is sent to heir business partners (retailers, wholesales, logistic service providers)

This covers the modular part, the framework becomes interoperable by allowing multiple schemas per DataTopic, with defined transformations between the schemas. This allows every party (both data senders and receivers) to work in the schema they prefer (no longer deliver multiple formats to all different data receivers).

The IMDE framework will support multiple DataSchemas per '''DataTopic''' (e.g allergens) and related data points, making sure all industries and all territories can join IMDE. IMDE will also support multiple DataSchemas per Data topic. Example: allergen exchange Excel template and Allergen Exchange XSD/XML. IMDE will also support existing information & taxonomy standards, like for example:
* [https://www.etim-international.com/ ETIM], the international classification standard for technical products
* [https://www.fao.org/ FAO] for Fish farming and Fishery related information standards
* [https://www.iso.org/ ISO] (e.g. for languages, countries and units)

[[Category:Layers]]