Circular Economy (CE) as defined by the European Union, is a model of production and consumption, which aims to share, lease, reuse, repair, refurbish and recycle existing materials and products as long as possible 1 . In this way, materials or product parts can be circulated 14th Workshop on Ontology Design and Patterns (WOP 2023) -Colocated with the 22nd International Semantic Web Conference (ISWC 2023) November 6-10, 2023. Athens, Greece ⋆ Author contributions: Overall project idea by EB and ML. Method and architecture of the ontology network by EB.
Implementation of modules by EB, HL, and RK, reviewed by ML. Survey on related ontologies by HL, MAN and YL, feedback by PL. Draft paper by EB, with sections from ML, HL and RK, reviewed/edited by remaining authors. ** Corresponding author. eva.blomqvist@liu.se (E. Blomqvist); huanyu.li@liu.se (H. Li); robin.keskisarkka@liu.se (R. Keskisärkkä); mikael.lindecrantz@ragnsells.com (M. Lindecrantz); mina.abd.nikooie.pour@liu.se (M. A. N. Pour); ying.li@liu.se (Y. Li); patrick.lambrix@liu.se (P. Lambrix) https://liu.se/en/employee/evabl45 (E. Blomqvist) 0000-0003-0036-6662 (E. Blomqvist); 0000-0002-9084-0470 (P. Lambrix) before they become waste, which will reduce value loss and avoid waste. Taking into account a product's entire life cycle is necessary to design and enable a CE strategy. This includes answering questions such as what raw materials are needed, how the materials are dealt with in the manufacturing process, how the products are distributed in a supply chain, what strategies can be used for reusing, refurbishing, and remanufacturing products, and finally recycling their materials in different end of life scenarios. In order to address these concerns, stakeholders from various industry domains need to be involved, including material suppliers, manufacturers, brands and retailers, end-users, repair and maintenance shops, collectors, sorters, and recyclers. Therefore, sharing data in a secure, quality assured, and automated way among these actors is necessary in a CE. However, there is a challenge in making decentralized data and information from actors across industry-sectors understandable and usable by both humans and machines. As explained in [1], leveraging open standards for semantic data interoperability and establishing a shared network of ontologies for data documentation is a starting point to address such a semantic interoperability challenge, and the aim of our ongoing project Onto-DESIDE 2 .
In this paper we summarise our initial results towards this aim, in terms of the outline of an ontology network, that is grounded in a careful analysis of existing ontologies and requirements. An ontology network is a "collection of ontologies related together via a variety of relationships, such as alignment, modularization, version, and dependency" [2]. We also exemplify the use of the network in two industry sectors. The main novelty and contribution of our work is the use of an ontology network, playing the role of both a "pattern language"3 and a core ontology, for a complex cross-domain use case such as CE. Still to this date the most common approach is to create monolithic ontologies, that are hardly reusable outside their original set of requirements, while we show the feasibility of creating truly reusable ontologies via a modular approach. While the full evaluation of the network, and alignments to existing ontologies is still future work, our current results show the feasibility and usefulness of our approach, and highlight the importance of a modular design and the use of Ontology Design Patterns (ODP).
In [4] we already presented a comprehensive survey of ontologies related to both the CE domain, and related topics. The survey found 37 existing ontologies, related to the topics of CE and sustainability, materials, as well as products, manufacturing, and logistics.
In the case of materials ontologies, several ontologies exist that cover the topic of materials, at different levels of granularity, and from different perspectives. In this area, there are ongoing efforts for unifying existing materials ontologies, c.f. the EMMO ontology 4 , and OntoCommons 5 . Hence, in this area our contribution will be mainly to ensure appropriate alignments to these ontologies, making sure that the needed perspectives and level of granularity of CE-specific use cases are covered. For instance, we note that in relation to CE, the notion of "material" itself is a context-dependent concept, where usually the materials required as input for the processes of one actor may actually refer to the product (output) produced by the previous actor in a flow. Hence, one of our main contributions will be to cater for such flexible modelling.
Similar, in the case of products, manufacturing, and logistics, there is a large number of ontologies available. However, many of them are quite specific to a certain type of process or industry domain, hence, our main contribution will be to provide generalised concepts that can map between more specialised ontologies, and cater for extensions into currently uncovered industry sectors. Exactly which ontologies to align with, however, remains future work.
Finally, regarding the notion of CE itself. First, we note that few core ontologies for CE can be found. Most target very specific use cases in specific industry domains. However, in [5] two ontologies are presented, i.e. the Circular Materials and Activities Ontology (CAMO) and the Circular Exchange Ontology (CEO), but these ontologies also target the construction domain specifically. Still, in [6] CEO and CAMO are used also for representing textile data, and in [7] for a Materials Passport Ontology. Further, in [8], an ontology is developed for the Circular Economy Monitor, to describe materials flows. Several ontologies have also been proposed for CE business modelling, e.g. [9, 10, 11]. Finally, there are also some ontologies focusing on specific circular strategies, such as recycling, e.g. [12]. The above examples are all efforts to enable the usage of ontologies for CE in practice, but where the ontologies are either not publicly available, not published according to FAIR principles, e.g. not accessible or documented, or target only a specific industry sector. There are also gaps in terms of modelling circular value networks (CVNs) themselves, i.e. configurations of actors that collaborate, which this work addresses. Hence, our conclusion is that the CE domain is currently not sufficiently covered by any ontology, at a general level, and while we will attempt to align to existing CE ontologies publicly available, this is the area where most modelling contributions should be made.
Still, an important note is that our target is broader than either of these listed domains. In fact, our target is to connect these domains. Although some of the surveyed ontologies do touch upon more than one domain, there is no ontology that covers all the needed aspects of CE. Additionally, most of the ontologies found are monolithic, i.e. do not have a modular structure, nor do they make their basic modelling assumptions explicit in the form of the ODPs they use. Whereas our belief is that any monolithic ontology for CE is bound to fail, due to the complexity and the cross-domain nature of CE. Instead, we strongly advocate a catalogue of ODPs, i.e. a "pattern langauge" for CE, as well as an ontology network that specialises such ODPs, which can then be configured and extended in any specific CE setting.
In this section we present the methodology applied. This includes a brief account of the overall project methodology, setting the context, as well as more details on the specific ontology engineering methodology, and some notes on the FAIR publishing of the ontology network.
The overall project research methodology divides our work into three iterations. In the current (first) project iteration the intention is to create a first prototype of a data sharing platform for CE data, where the ontology network presented in this paper constitutes the backbone for semantic data interoperability, sharing, and querying. However, it is important to note that the prototype, including ontology modules, will certainly change in the coming two iterations.
Nevertheless, as a starting point for the ontology engineering process, we rely on a needs and requirements analysis done at the start of the project. This needs analysis was performed using a CE-specific analysis framework, called Circularity Thinking6 [13, 14], which allows for detailed analysis and mapping of current flows and ways of working, as well as to outline desired flows, e.g. by applying more circular strategies, such as reuse, refurbishment, remanufacturing, or recycling. This needs analysis was done in the three project use cases, originating in the textile, electronics, and construction industries respectively [15]. The mapping of the intended future circular value flows were then transformed into a set of project requirements, collected in the form of user stories, and analysed in terms of their overlaps and cross-cutting concerns [16].
There is a trade-off between modularity and architectural complexity of the ontology network to be developed. However, when modelling for the CE domain it is clear that we need to prioritise modularity over a simpler ontology architecture, to (i) increase the reuse potential of the ontologies, (ii) separate concerns and allow for alternative models, and alignments to different related ontologies, for certain specific domains, and (iii) increase the understandability of the notions we are modelling. This clearly follows from the fact that the domain of CE is highly diverse, and it would simply be impossible to model all aspects and all possible industry sectors in a single ontology. In addition, it is highly likely that circular value networks change over time, hence, modelling so that changes have minimal effect on the overall solution is essential. Therefore we envision the situation where an ontology for a specific use case can be composed from a library of modules (and ODPs), and existing ontologies in that domain. Thus it will be tailored to a specific CE use case, but where interoperability is still ensured by having a set of core ODPs shared by all specific ontology modules. This is the motivation for targeting an ontology network, composed of modules, instead of one (or a set of) larger ontologies.
The small set of core modules that are to be shared throughout the ontology network, can be viewed as a coherent set of shared ODPs, i.e. a "pattern language". In practice they will be represented as well-documented ontology modules, but with a minimal ontological commitment to be as reusable as possible (c.f. points (i) and (iii) above). These will constitute the core of the ontology network, and will then be reused and specialised (i.e. extended with further details), aligned to external ontologies etc., to fully cover any set of requirements (c.f. the flexibility requirement in point (ii) above). By taking this highly modular approach we ensure that the core modules can also be reused independently of the rest of the ontology network.
Given these architecture principles, we then needed to select an appropriate ontology engineering methodology. It is clear that the methodology had to be suitable for creating highly modular ontologies, reusing and developing ODPs, and it needed to be highly agile, since not all requirements are known beforehand and access to domain experts is limited so some modelling decision may have to be revised later on. Given these methodological requirements, we mainly considered agile ontology engineering methodologies, such as eXtreme Design (XD) [17], SAMOD [18], and the modular ontology development suggested in [19] (as a variant of XD). Other methodologies that inspired our work includes test-driven development [20], and the iterative evolution of ontologies, such as DILIGENT [21], however, neither of these fulfil all the requirements listed above. As the basis of our work we have selected the XD methodology, mainly because it is well-established and has been applied in many documented use cases and projects, it is highly focused on both the use and production of ODPs, and it allows for rapid prototyping of ontology modules, which is suitable for our iterative project methodology. However, XD also had to be slightly adapted, i.e. mainly the following four adaptations have so far been considered, in relation to the original description of XD in [17]:
1. Less focus on the initial scoping of the ontology -The scope is allowed to emerge from the emerging set of requirements. 2. No fixed set of external resources identified at the project start -The set of external ontologies and non-ontological resources to relate and align to is allowed to emerge and evolve over time. 3. Increased attention to architectural principles and patterns -A core set of shared modules (ODPs) are first created, as the backbone of the ontology network. 4. A modified process regarding requirements analysis -Requirements are developed outside of the development loop, and core requirements (requirements of core concepts and crosscutting notions) are all formulated before modelling of those modules start.
Once ontologies have been modelled, they also need to be shared with the community. To guide and support the sharing of scientific results in general, and artefacts in particular, the FAIR principles were proposed [22]. To adhere to these principles, the ontologies will be represented using the W3C standard OWL 7 , use permanent URIs as identifiers based on a persistent URI service, i.e. the w3id service 8 , while the source files will be available both from an open source service (GitHub) 9 , where we handle issues, change requests, and ontology versioning, and when stable they will be registered in indexing services such as LOV 10 and the ODP portal 11 . In order to ensure interoperability of the ontologies themselves, the ontologies will also be linked to standard ontologies, and aligned with other relevant industry standards. In the related work section of this paper we briefly report on our recent survey of related ontologies. By developing the core of the ontology network in a modular and extensible fashion we ensure reusability across industry sectors, i.e. the possibility to specialise the ontologies for any industry domain in the future, and by developing such specialisations for three specific industry use cases (two of them discussed in this paper) we exemplify and evaluate the reusability of the ontologies. The ontologies are also published under an open licence. Documentation is another important aspect and the project leverages pyLODE 12 for generating web-friendly documentation directly from the ontology files. Additionally, we employ OWL2VOWL 13 and WebVOWL14 to generate interactive visualizations, providing an easy to understand overview of each ontology on their respective documentation page.
In this section we outline the results of our work, i.e. the ontology requirements, the network outline and list the modules being released.
In order to design the ontology network, we have studied (1) existing ontologies and nonontological knowledge sources in the area [4], and (2) a set of ontological requirements, coming from industry use cases in three different sectors (textile, electronics, and construction) [23]. The set of ontologies surveyed in [4] consists of 37 related ontologies. Our ontology requirements consist of 73 ontology stories each with a related set of Competency Questions (CQs) [23], where we have initially chosen to focus on the ones that appear in more than one of the industry use cases, i.e. cross-cutting notions and concepts. Each ontology module is annotated with a lists of the requirements it targets, using the numbering of [23]. For an intuition of the kind of CQs we have elicited, the following is an example from story CUS0 (construction sector), related to actors and roles, where the CQs were deemed to be relevant across use cases:
• C0-1: What are the actors involved in this value network? • C0-2: What are the roles of this actor in this network?
To create an appropriate set of core ontologies, we have first identified the core topics based on the requirements discussed above. An overview, in the form of an informal illustration is displayed in Figure 1. Note that the boxes do not represent concepts, but rather areas (i.e. topics), that each are covered by one or more ontology modules. The dark blue boxes contain new concept definitions, i.e. modules introduced by our network, while the light blue box (location) indicates reuse of existing ontologies. The lines between boxes indicate relations between the topics as mentioned in our requirements set, but are in the actual implementation of the ontology network replaced by formal relations between modules, e.g. owl:import and/or concept references across module boundaries, as well as alignments and dedicated properties.
In our first release we have included three abstract ODPs, i.e. modelling processes, actors and resources. The rationale for claiming these modules to be ODPs is mainly that they are entirely independent of the CE domain, i.e. they simply represent patterns of modelling these abstract notions, but refrain from including any specific conceptualizations related to CE. Our intention is further to, in future releases, include alignments between these ODPs and top level and foundational ontologies, such as DUL, in separate alignment modules.
Our focus in this first release has been on the central CVN module, and the modules for process, actor, and material/product. The value module is so far not elaborated, partly due to its close connection to ongoing work on standardising CE terminology in ISO/TC 323 15 . Hence, this module so far consists only of a "stub" for further extension in future releases. Additionally, the materials and product modules, as specialisations of the resource ODP, will be further extended in the next release, due to a limited coverage of the ontology requirements in the current release. The ontology modules are published publicly via GitHub, under a permanent w3id URI 8 and further documented and maintained in our GitHub repository 9 .
The Actor ODP 16 is at its core a variant of the common participation 17 and participant role 18 ODPs, although where the "event" in those patterns have been interpreted very generic, as any context with a time extent. Hence, the core concept is a participation relation (i.e. a reified relation), named Participation, that relates an Actor, to either a Resource or a Process where the actor is holding a specific Role. The participation may be indexed with time and spatial context. An actor can also be associated with an ActorType and have a certain Capability, which is used in the participation in a process.
The Actor module 19 , specialises this pattern by adding concrete CE-relevant roles, both for processes (e.g. collector, sorter, recycler, remanufacturer) and resource relations (e.g. owner, issuer, holder, seller, buyer). An example of a participation in a resource relation is an organisation (actor) that owns (role) a certain batch of recyclable material (resource) at a certain point in time. An example of a participation in a process is an organisation (actor) that acts as the collector and sorter (roles) in a recycling process, as a prerequisite to the recycling.
The Resource ODP 20 is merely a small top level ontology for resources, identifying two types of resources; PhysicalObject, and Information. Where physical objects in turn are composed of certain Matter, and may have some Constituent that is in turn another physical object. The Materials module 21 specialises this ODP by adding MaterialComponent as a subclass of Constituent, and Material and ChemicalEntity as subclasses of Matter. This is in line with the top structures of current materials ontologies, to which alignments are planned in separate modules, and allows for modelling of materials at various levels of granularity. The Product module 22 in turn specialises the ODP by adding Product as a subclass of PhysicalObject and ProductComponent as a certain kind of Constituent. As mentioned earlier, these modules are not intended to introduce new notions but merely cover the aspects relevant for CE, with minimal ontological commitment to maximise reusability, and allow for alignments with existing, more detailed, materials and products ontologies.
The Process ODP 23 distinguishes between a Process and its concrete ProcessExecution, and also models the composition of processes from other processes, and their ordering. In addition, a particularly important kind of process, in the CE context, is a Transformation that takes some input and transforms it to some output, i.e. moves the current state from one situation (context) to another (c.f. the Transition ODP in the ODP portal 24 ). In particular, the Process module 25 specialises such transformation processes, and lists the typical processes involved in a CE, such as dismantling, deconstruction, refurbishment, recycling, reuse, and take-back processes, although their detailed transitions are still to be added in future releases.
The CVN module 26 models a CVN as a kind of Collaboration between actors, that implements some CircularStrategy aiming to produce some Value 27 . An important notion is also the one of a CVN blueprint, which intuitively corresponds to a plan, in the sense of the difference between a plan and its execution (e.g. inspired by ODPs such as TaskExecution 28 . Hence, the module intends to make it possible to describe an envisioned value network, i.e. the "plan" or blueprint of it, without knowing what exact actors will fill the needed roles and capabilities. This is important both for use cases where the task is to find such actors to fill certain gaps in the network, but also for being able to describe abstract network blueprints that can act as templates for future instantiation of similar networks, but with potentially different actors.
The end goal of the network is to bridge the silos of industry sectors, and allow cross-domain interoperability. However, the first step in the evaluation is to show the applicability of the modules within different industry sectors. We do not yet have full evaluation results, but we present examples from two of the sectors in our project.
In the textile use case of our project the scenario revolves around circularity assessments, and certifications, to be presented to consumers when buying footwear products with recycled content. For instance, answering consumer questions like "How circular is this shoe?". But also for being able to improve fibre recycling post-use, by maintaining a trace of the material content of footwear, without exposing trade secrets of the material providers. For this use case, a Product Circularity Data Sheet (PCDS) [24] is extended with additional variables for textile materials, and the sheet is then modelled using the ontology network. This makes data semantically interoperable throughout the supply chain, and usable for certification, for presentation to footware customers, and for recyclability assessments when collecting used footware.
In the initial setup, the main ontology modules used are the Actor module, for describing actors providing data for the sheet, and the certification authorities, as well as the Product and Materials modules, for describing material content. Hence, rather than having to include the full network, we can utilize the modular structure and pick the modules that are relevant in this case, and specialise only those. A small example of modelling the PCDS using the Actor and Product modules is depicted in Figure 2. Illustrations use the Grafoo notation29 , with the addition of dashed boxes to illustrate the origin of the classes and instances, instead of prefixes.
In the construction use case the scenario revolves around a take-back system for floor tiles, where a trace needs to be kept of the use of the floor tiles in various buildings, in order to be able to retrieve them and send them back to the manufacturer when they are dismantled from the building (e.g. when it is renovated or demolished many years later).
In the initial setup for this use case, the CVN and Actor modules are used to describe the connections between actors, e.g. manufacturers and sellers of floor tiles, building owners as the users of the product, and the manufacturer again in their role as customers of used tiles in the take-back process, i.e. for reusing, refurbishing, or recycling the tile material. In addition, certain properties of the tiles also have to be described, i.e. both at the level of product data, as well as data about individual tiles, such as their location in a certain building and the recommended method for dismantling the floor. In this case the focus is on different modules, compared to the textile example above, i.e. here the CVN and roles of the actors is in focus. A small example of modelling a network using the Actor and CVN modules is depicted in Figure 3.
When analysing existing ontologies, we note gaps in coverage of central CE concepts, such as the CVN itself. In other domains on the other hand, e.g. materials and manufacturing, there are instead many overlapping ontologies and/or partly competing conceptualizations. Our proposed solution is to create a set of ODPs, i.e. a "pattern language", and ontology modules that represent core concepts related to CE, in order to provide a core to which existing ontologies can be aligned, and in addition complement missing CE concepts. Alignments to existing ontologies are still part of future work, as well as validation of our modules in all industry use cases of Onto-DESIDE, and validation of the core CE concepts against emerging standards, such as the CE terminology and definitions by ISO/TC 323. However, we can still conclude that the approach has proven feasible and useful, in initial modelling exercises of the project. Together with the extended methodology, FAIR publishing, and the high degree of modularisation we see this as a step towards true ontology reusability, even in cross-domain scenarios such as CE.
Future work includes (i) the creation of alignment modules, to connect our network to ontologies found in our survey, and (ii) to perform a more extensive evaluation, involving actual data exchange through the Solid-based Onto-DESIDE data exchange platform, and to extend the evaluation to encompass cross-sectorial data exchange. Further work involves to more deeply study the methodological implications of ontology engineering for this setting, i.e. to adapt XD further to highly distributed and highly agile settings, where ODPs are created alongside the ontology modules as requirements emerge and commonalities are discovered.
This work has received funding from the European Union's Horizon Europe research and innovation programme under grant agreement no. 101058682 (Onto-DESIDE), the Swedish e-Science Research Centre (SeRC), the Swedish National Graduate School in Computer Science (CUGS), and the Swedish Research Council (Vetenskapsrådet, dnr 2018-04147).