Reuse of doors
(C) End-of-life: reuse (construction case)
Explore a reuse case: doors listed with passports and access-controlled terms, linking sellers and builders to match fit, code, and price.
From pre-demolition audits to second-life installation, this reuse example shows how doors can move from one project to the next with confidence. Guide 1 Value chain design, development & innovation structures the decision process—do resource, value and information flows align?—so reuse can beat disposal. Guide 2 Decentralised data & information sharing delivers the data infrastructure: door passports, ontology alignment, and access-controlled data that lets buyers test fit and verify ratings automatically. CEON and OCP refer to Onto-DESIDE’s Circular Economy Ontology Network and the Open Circularity Platform.
What: Reuse and resale of a door for use in other building projects.
Why: Linking supply & demand through a digital market place for second-life parts & components.
A building owner, preparing for demolition, assesses the reuse potential of installed elements, such as doors, for repurposing through resale. This information is used by the demolition contractor to negotiate a fair price for the building’s demolition, and sets the frame for what demolition methods will be used.
To find a new use, the building owner lists the components, including the doors, on a digital marketplace—provided by an intermediary for sale to construction companies for reuse in new projects. Metadata such as dimensions, condition, and installation history are shared, and enriched with images, enhancing buyer confidence. Pricing information is managed securely via decentralized data pods, ensuring only authorized parties can access commercial terms and optimising the value for the building owner. Planning considerations are automatically taken into account.
Step 1: Current undermining tensions and desired patterns using the Multi-Flow Method
Robustness vs. Adaptability: Ahead of demolition, doors are assessed and listed, but rigid, document-based formats can’t capture real-world variability. Key fields—dimensions, swing, interfaces, material, glazing, ratings, condition, and install history— are missing or incomparable so buyers can’t test fit for new projects. Planning constraints aren’t linked, and commercial terms sit in scattered PDFs. “Robust” formats (reports, photos) are too static to support confident pricing for reuse, so building owners accept conservative offers or default to disposal.
Improvement opportunity for data flows: Enable machine-readable door passports with geometry, interfaces, ratings, condition, provenance, images, and location, using shared vocabularies and verifiable credentials. Sync planning constraints automatically and manage contracts decentrally so only authorized parties can access them. Interoperable APIs let marketplaces and builders auto-check fit and code, improving negotiation with the demolition contractor and enabling confident resale into new projects. Putting this in place becomes the main concern of the project that follows.
Step 2 & 3—Requirements & Data Inventory
The intermediary (marketplace owner) consults with other actors, buyers and sellers of reused building elements, what their data needs are, and they formulate a set of user stories. The intermediary’s data steward then helps the building owner to create a data inventory for reuse-relevant data on doors, including sources such as pre-demolition audit (measurements, condition grades), installation history, certification (fire/acoustic), images, location and planning constraints. For each dataset, they record format, location, owner, update cycle, sensitivity and access rules. They flag sensitive fields (exact addresses, pricing) for restricted sharing, and log information gaps (e.g., missing hinge). This inventory clarifies what information exists, what is missing, and which additional data can be produced.
Step 4–Enable Data Sharing
The intermediary’s developer sets up a Solid pod per building owner, as a part of an Open Circularity Platform (OCP) setup, so owners retain control over their data. The building owners can then share door passports, each in their own Solid pod, exposing some data publicly, and restricting access to commercial and location data to selected buyers. This enables secure, scalable data exchange across actors.
Step 5a—Ontology Requirements & Inventory
Before putting such data online in the Solid pods it needs to be described by a shared model. Thus the actors jointly define CQs to represent common concepts in the data and data needs of the actors: “Does this door fit opening X within ±y mm?” “Is the fire rating valid for intended use?” “What is handedness and frame/hardware compatibility?” “What is the condition and provenance?” The intermediary’s developer then maps CQs and current data to shared terms from the CEON ontologies and identifies gaps. While a Product concept is present in CEON, there is no notion of a building element, and locations within a building, such as floors and rooms etc.
Step 5b & C—Ontology Extension & Alignment (as needed)
The developer extends CEON with door-specific properties/classes (e.g., hasHandedness, hasTolerance, hasHingePattern, hasBackset, hasFrameType, hasRatingCredential, and hasCondition), some which can be reused from IFC, to describe item-level passports. Additionally, location parameters relevant to the door placement are reused from the Building Topology Ontology (BOT) ontology, a common ontology used in the smart buildings domain which is already used by several of the building owners.
Step 6—Ensure Technical Interoperability
To secure technical interoperability, RDF has been selected as the common data format, and several of the building owners can already exchange RDF data directly to/from their facility management systems. The graph-based structure of RDF, and use of globally unique identifiers, allows for seamless integration of new information types, supporting the diverse use cases of various building owners.
Step 7—Define Data Transformation
The developer creates YARRRML mappings describing how the data from the building owners that is still not in RDF natively is transformed to RDF using CEON terms and door-specific ontology extensions and alignments. For example, door ids are mapped to URIs and image URLs are linked with the property hasImage, defined in a CEON extension for this use case. Additionally, this mapping includes the creation of access control rules for sensitive data, such as pricing and precise location, and finally the data is published on the Solid pods.
Step 8—Set Up Querying
The developer also provides SPARQL queries that buyers and planners can reuse and submit over the OCP, answering questions such as “Select doors within ±10 mm of WxH for Opening #ID”. Queries are executed through the intermediary, across the OCP Solid pods of various building owners sharing their data to shortlist viable units for reuse.
Step 9–Develop Data Access Applications
The intermediary hosting a marketplace application, for sale of reused construction elements, extends their application from manual data input to using SPARQL queries over the OCP to retrieve data from door passports shared via decentralised Solid pods. This data is processed to present items that match the needs of the logged in users. Interested buyers can request read access to sensitive data such as price or exact location. This information is rendered only after this access is granted to the logged in user.
Step 10–Plan Maintenance and Evolution
When new fire ratings, new component attributes or new certification types appear, data inventories, ontologies, mappings and queries are updated. As the graph-based structure of RDF allows for seamless integration of new properties into the datasets, without the need to adapt all other datasets, the data on the decentralized Solid pods remains backwards compatible and reuse transactions and queries continue reliably.
See how strategy and data meet to make reuse predictable at scale in the Guides in the “Tools & Training” section.
