Compliance in the plastics industry is becoming more complex. Companies must follow several regulations, which often ask for detailed information about materials, substances, and safe use. A common example is REACH[1], which requires companies to report certain harmful substances in plastic products. This information must be shared across the supply chain and kept available for possible audits later.
In practice, this is difficult and costly. It can also be a serious risk for manufacturers. If they do not comply, they may no longer be allowed to sell their products on the European market.
| Teams often read legal text and ask: What do we need to do?What data do we need to provide?Where do we even start? |
This is where the challenge starts. Regulations are written in legal language, but companies need to translate them into practical digital systems. These systems need data that is either standardized or clearly explained and linked to a source. This creates a bridge between what the law says and what manufacturers need to build into their systems.
The data models[2] used to create compliance data can be stored in different ways. Some are kept in simple places, such as a text file on someone’s computer. Others are managed in more advanced tools, such as a vocabulary hub. A vocabulary hub helps users describe data in a clear and shared way. It can also create technical documents automatically, such as API specifications.
CircPlastX builds on this idea by using Semantic Treehouse. Semantic Treehouse is a vocabulary hub that helps manufacturers store and reuse standardized data models. It also helps them create technical artefacts, so compliance work can become faster, cheaper, and more digital.
Example: a company places a (plastics) product on the EU market
To show how this works, we use a simple example of a company that places a plastic product on the EU market.
Article 33(1) of REACH says that a supplier must give the recipient of an article enough information to use it safely. At a minimum, the supplier must share the name of the substance involved.
Sounds simple — but in practice, this leads to many questions:
- What article are we talking about? The product itself or the component?
- Which substances are inside?
- What is the concentration?
- What information must be shared to be deemed sufficient?
- With whom?
This shows how one legal article can lead to many small data needs. The challenge becomes even bigger because plastic products are often used as parts of other products. As a result, manufacturers may need to follow several regulations at the same time. To reduce this work, it helps to reuse a data model created by a regulator or an industry association. Such a model can bring different requirements together in one structure.
Digital Product Passports
Digital Product Passports (DPPs) can support this. A DPP brings together the relevant data about a product in a standard format, so the information can be shared across sectors. However, each manufacturer still needs to fill the DPP with real product data. That is why we also use DPP templates: they identify which information must be collected before the passport can be filled with real product data. So how does a company move from legal text to a usable DPP template?
| How does a company move from legal text to a usable DPP template? |
This challenge can be addressed with Semantic Lineage. Semantic Lineage means that the link between a data model and the legal text behind it is kept clear. This makes it easier to find, use, reuse, and check the data model later. It also helps users understand where each requirement comes from.
From legal text to a usable DPP: a six step approach
The step-by-step approach below is based on the paper “Facilitating Semantic Lineage in Data Spaces: The Digital Product Passport Use Case” by Jesper Kuiper and Jelte Bootsma.3 It is introduced in Figure 1 and explained in the next sections.
Figure 1 – Route from legal text to a usable Digital Product Passport
Step 1: Turn legal text into clear data requirements
The first step is to break the legal text into small, clear requirements.
Each requirement should:
- Describe one clear obligation.
- Be easy to understand.
- Link back to the legal text.
For example: identify the product; identify the substance; check if it is on the Candidate List; record the concentration; provide safe-use information
These requirements are then uploaded to Semantic Treehouse. There, they are shown in a tree-like structure. This makes it easier to see the different parts of the legal text and later link them to data models. A snapshot example of points 1.1 and 1.2 of REACH Annex II is showcased in the image below.
Figure 2 – A snapshot of points 1.1 and 1.2 of REACH Annex II
Step 2: Convert data requirements into DPP templates
The next step is to link the requirements to a structured Digital Product Passport (DPP) template. A DPP template describes which information is needed about a product. Users with legal and IT knowledge can connect each requirement to the right part of the template. This creates a visual mapping that can be reused and shared.
When creating a mapping the user:
- Reviews previous mapping(s) to not create a duplicate mapping.
- Selects the legal requirement.
- Selects its relevant data element.
- Drags and drops the requirement on top of the data element.
Figure 3 – Using Semantic Treehouse to map regulatory requirements to a DPP template
Step 3: Make the DPP template ready for IT systems
Once the template and its links to the requirements are clear, the template can be turned into a format that IT systems can use. These formats are often called machine-readable schemas. They help companies use the template for compliance reporting in their own systems.
In Semantic Treehouse, this is done by exporting the template to formats such as JSON, XML, RDF, or OpenAPI. This step helps to ensure that:
- Data structures can be implemented in IT systems.
- Information can be exchanged between systems.
- Validation rules can be applied automatically by checking systems.
The template is now in a format that developers and IT systems can use. In the image below, the option of exporting the visual message model to OpenAPI is shown.
Figure 4 – Exporting the visual message model to OpenAPI
Step 4: Create DPPs for real products
Once the template is ready for IT systems, organizations can use it to create DPPs for real products.
Each DPP then:
- Describes one specific product.
- Follows the structure of the DPP template.
- Contains real product data.
Figure 5 – Creating DPP for real products
Step 5: Check the DPP template against the requirements
Before using the templates, it is important to verify that they fully cover the legal requirements.
This involves:
- Linking template elements back to the original requirements.
- Checking completeness and consistency.
- Ensuring that all obligations are addressed.
This step helps to make sure that the template is compliant by design. Because the links between the template and the legal requirements are shown visually in Semantic Treehouse, an expert can review them in one place. This reduces the need for separate tools.
Figure 6 – Linking the DPP template and the legal requirements using Sematic Treehouse
Step 6: Check the final DPP
The final step is to check the completed DPP before it is used or shared.
This check helps confirm that:
- The data is complete and uses the right format.
- The values follow the rules of the template.
- The DPP still matches the template and the legal requirements behind it.
This turns the DPP from a planned structure into information that can be checked and trusted in practice.
Compliance becomes easier when legal requirements, data models, and product information are connected in a clear way. The six steps above show how companies can move from legal text to a DPP that can be checked and reused. This means they can:
- Turn legal obligations into clear requirements.
- Link these requirements to DPP templates.
- Create reporting data for real products.
- (Double)Check that the data still matches the legal requirements.
Tools like Semantic Treehouse can make this process visible and easier to manage. They help legal experts, data experts, and manufacturers work from the same source of information. This supports a more practical way to create DPPs and prepare for compliance checks.
Want to explore what this could mean for your own DPP work? You can contact Theodor Chirvasuta (theodor.chirvasuta@tno.nl) or Kelly van den Elzen (kelly.vandenelzen@tno.nl) at TNO to learn more about using Semantic Treehouse in practice.
Authors:
Theodor Chirvasuta (TNO)
Kelly van den Elzen (TNO)
References
1 REACH is the EU regulation for chemical safety. It applies to companies that make, import, or use chemical substances or products in the EU. This also includes plastic products.
[1] REACH is the EU regulation for chemical safety. It applies to companies that make, import, or use chemical substances or products in the EU. This also includes plastic products
[2] A data model is a simple structure that shows which information is needed, how it is described, and how different pieces of data relate to each other.
