Take-back and remanufacture
(D) End-of-life: remanufacturing (construction case)
Follow a take-back case: floor tiles returned to manufacturer via data and logistics, enabling predictable remanufacturing and securing future feedstock.
End-of-life doesn’t end the value story. This example illustrates for remanufacturing how the Onto-DESIDE tools and solutions make sense. Guide 1 Value chain design, development & innovation maps incentives and flows so take-back aligns across owners, contractors, and OEMs, turning tiles into dependable remanufacturing feedstock. Guide 2 Decentralised data & information sharing shows how decentralised pods, chain-of-custody credentials, and federated queries make eligibility, logistics, and pricing transparent—without exposing sensitive details. CEON and OCP refer to Onto-DESIDE’s Circular Economy Ontology Network and the Open Circularity Platform.
What: Take-back of the floor tiles by the manufacturer for remanufacturing.
Why: Enabling manufacturers to take-back their products, ensuring access to future feedstock.
At the end-of-life stage of a building, a building owner initiates a demolition plan and assesses reuse and recovery options for installed components. Among these, the acoustic floor tiles—originally made with recycled feedstock from apparel waste—are identified as having high reuse potential, but not in their current condition.
The owner contacts the original tile manufacturer, who offers a take-back program. Through a data exchange platform—facilitated by an intermediary—the manufacturer provides pricing and logistics information for reclaiming the tiles. The tiles are returned, inspected, and remanufactured into new flooring systems, integrating both recovered and new materials. This process reduces raw material demand and preserves embedded value.
Step 1: Current undermining tensions and desired patterns using the Multi-Flow Method
Individual vs. Collective interest (Take-back): At end-of-life, owners and demolition crews optimise for speed and lowest cost, while the OEM needs predictable, quality-controlled returns to plan remanufacturing. Crucial evidence—lot IDs, composition/binder, contamination risk, install zones, uninstall technician, custody—sits in PDFs or isn’t captured. With incentives split and proof missing, tiles are cherry-picked or downcycled, and OEMs can’t secure stable and reliable feedstock for remanufacturing.
Improvement opportunity for data flows: Use governed, selective disclosure. Issue machine-readable passports with lot/composition/binder/condition; attach verifiable credentials for “fit-for-return” and chain-of-custody. Publish reverse-logistics slots and price bands via decentralized pods (with commercials only to authorised parties). Predefined queries in planning tools auto-route eligible tiles to the OEM, aligning incentives and making take-back predictable and scalable. Enabling these solutions is what the next steps are about.
Step 2 & 3—Requirements & Data Inventory
First, the OEM consults owners, collectors and representatives of the demolition sector to map data needs for automating the take-back process. They capture user stories, e.g.: “As a building owner, I want to know whether the OEM offers a take-back system, and under what conditions, so I can choose the right end-of-life option.” The building owner’s data steward compiles a data inventory of installed components (materials per room with m², tile-type installation dates, installation specs such as binder/adhesive and underlay, batch IDs, removal methods). The OEM likewise inventories take-back data: needs, criteria and pricing. For each dataset, the inventory records format, owner, update cycle, provenance and access rules. Sensitive fields—such as exact locations and contractor rates—are flagged for restricted access.
Step 4–Enable Data Sharing
The building owner decides to publish his data on a Solid pod, using a hosted service providing access to the Open Circularity Platform (OCP), rather than transferring it to a central database of an intermediary. The OEM sets up their own OCP Solid server to host their pods, to hold data of various products. This way they both retain control over their data, sharing selected data elements with other actors.
Step 5a—Ontology Requirements & Inventory
The developer first defines CQs to represent data needs: “Which tiles in Building X are eligible for take-back (lot, binder, wear ≤Y, contamination ≤Z) by what OEM?”, “What m² per eligible lot can be collected within time window W?”, “What packaging/handling is required per batch?”, “What is the verified chain-of-custody from removal to OEM dock?”. They then map current terms and data to CEON concepts and properties and list gaps.
Step 5b—Ontology Extension (as needed)
While most concepts and properties needed are already available in CEON, for the sake of understandability the developer decides to add tile-specific concepts and properties, e.g., RemanufacturableTile (subclass of Item), hasLotID, hasBinderType, hasWearGrade, hasContaminationScore, etc.
Step 6—Ensure Technical Interoperability
All actors of the decentralized network, namely building owners, contractors, intermediaries and OEMs, decide to keep their data in their original databases but to convert their data to RDF for data exchange through the OCP, to secure technical interoperability. As they reuse persistent globally unique URIs to identify batches and product models, or even individual tiles, the data of the various actors can be automatically combined to optimize the take-back process and create traceability.
Step 7—Define Data Transformation
A developer writes a YARRRML mapping to convert the data from a database to an RDF representation for exchange, e.g. the building owner’s data. For example, the mapping links batch IDs and model IDs, available in the building owners’ database, using the CEON concept BatchOfObject. The mapping also defines where the data is published, and includes access rules. The mapping is executed with one command, sharing the generated RDF data securely on the Solid pod of the building owner.
Step 8—Set Up Querying
The developer also writes SPARQL queries which run over all data exposed by the set of Solid pods in the OCP, to answer questions such as “Find eligible tiles by lot, with area ≥ A and pickup window next 14 days”.
Step 9–Develop Data Access Applications
An intermediary builds a digital portal to support take-back: owners view eligibility status by zone; contractors see removal/packaging instructions; OEMs pre-book pickups, generate manifests, and issue compensation offers; logistics receives route plans. The app runs predefined SPARQL queries to retrieve the data needed in the portal. Sensitive pricing information and location data appears only when an authorized party logs in.
Step 10–Plan Maintenance and Evolution
As adhesives, testing methods, or take-back programs evolve, the data stewards and developers update the data inventories, ontology modules, mappings, and queries. When new building owners enter the network, OEMs grant them read access to selected parts of their data, and the intermediary expands the sources of the SPARQL queries feeding the digital portal with the data of the new building owners, ensuring OEMs can reliably retrieve end-of-life tiles as future feedstock.
For the step-by-step path from plan to predictable returns, explore the Guides in the “Tools & Training” section.
