This paper introduces an ontology-based approach to model supply networks aimed at identifying bottlenecks among suppliers. Considering concepts from existing ontologies, we develop a concise ontology to represent the structure of supply networks, focusing on products and their derivational dependencies. We compare our ontology to PRONTO, a heavyweight ontology with a similar scope, demonstrating its reduced complexity while retaining suficient modeling capabilities. Reduced expressiveness in some product cases due to the abstraction of product variants is a limitation. Further work is needed on network metrics and measures to identify bottlenecks.
In 2021 a global shortage of microchips forced car manufacturers to halt production [
A recent accumulation of environmental and geopolitical challenges has led to unprecedented
disruptions in supply networks [
Bottlenecks in enterprises’ supplier networks are the suppliers with the highest loss
contributions in consequence of a disruption [
The goal of this paper is therefore to provide a graph model representing the structure of supply networks. The graph model allows to identify bottlenecks among suppliers in a supply network based on instance data. The results can aid enterprises in their supplier management.
In the remainder of this paper, we cover related work in Section 2 and in Section 3 discuss the choice to model the supply network graph with products as nodes and derivational dependencies between them as edges. Our contribution in this paper is an ontology to model the supply network graph, for which we present the methodology (cf., Section 4) where we set the target of developing a small, concise ontology for a wider audience. We discuss and present the ontology itself in Section 5, taking into account ontologies from related work. In an evaluation (cf., Section 6), we use the ontology with the largest overlap of scope (PRONTO, cf., Section 2) as a baseline for comparison. The paper concludes with Section 7, which includes limitations and open questions.
This section provides an overview of supply network graph models from the literature. We discuss the choice of graph model with regard to the identification of bottlenecks among suppliers in Section 3.
Wagner and Neshat [
Kim et al. [14] model supply networks as directed graphs with firms as nodes and either delivery and receipt of materials or contractual relationships as edges. These two types of supply networks have the same firms as nodes but may have diferent network structures if a buying company establishes a contract with a second- or third-tier supplier and directs the top-tier supplier to receive materials from them.
Kim et al. [
Reyes Levalle and Nof [
This section provides an overview of relevant ontologies from the literature. We discuss the concepts represented by various ontology terms with regard to our ontology in Section 5.
The TOVE project on enterprise modeling resulted in a Resource Ontology [15] and an ontology for requirements in the engineering design domain [16]. The Resource Ontology focuses on resources in enterprises and includes concepts for resource division, quantity, and usage [15]. The requirements ontology introduces parts, features, requirements, and constraints as main concepts [16].
The Enterprise Ontology [17] resulted from the Enterprise Project on the topic of enterprise modeling and the management of change. Concepts represent a comprehensive view of enterprises including processes, strategy, organizational structure, resources, goals, constraints, and environment [17].
The Onto-SCM ontology [18] was developed as a common semantic model for semantic integration in the supply chain management (SCM) domain. Major concepts cover supply chain structure, -management, -activities, -items, and -resources [18].
The GoodRelations ontology [19] was developed to annotate product and service oferings on the Web for e-commerce. The ontology includes the concepts of Web Resource, Business Entity, Ofering, Business Function, Product or Service, and Unit of Measurement [19].
PRoduct ONTOlogy (PRONTO) [20] is an ontology from the product modeling domain that represents product information with an abstraction hierarchy and a structural hierarchy. The core classes are Product, VariantSet, Family, Structure, Relation, Change, and Restriction [20]. PRONTO is the ontology with the largest overlap in scope compared to our goal and therefore used for comparison throughout this paper.
Schema.org [21] is an ontology targeted at Web developers to annotate websites. The Schema.org terminology is partly derived from GoodRelations, but also contains additional terms to cover a greater scope. The major concepts1 include CreativeWork, Event, MedicalEntity, Person, Place, Product, and Action.
The supply network graph models from the literature difer in their choice of nodes and edges for the graph model. This section evaluates the graph models to identify the most suitable one for our use case.
Wagner and Neshat [
Kim et al. [
Reyes Levalle and Nof [
Kim et al. [14] model enterprises ("firms") using either delivery and receipt of materials or contractual relationships as relations. For our goal of detecting bottlenecks among suppliers in a supply network, this model seems a suitable choice. However, modeling dependencies between enterprises does not propagate well across multiple tiers in a supply chain because these relationships are not (entirely) transitive.
We use Figure 2a for an example. If the car manufacturer BMW orders components from Continental to build its cars, BMW clearly depends on Continental. Continental also is a manufacturer of conveyor belts for the mining industry. When Continental orders chips from NXP to build a conveyor belt, Continental clearly depends on NXP. The dependence of BMW on NXP is however questionable. BMW could sufer from disruptions in Continental’s manufacturing of conveyor belts due to financial problems or human resource planning afecting Continental’s car components. The efect on BMW of a disruption in Continental’s car components is however undoubtedly greater. If Continental were to order chips for their car production from NXP, the situation would be diferent. The enterprise supply network graph model does not provide a means of distinguishing between the two.
A solution is to incorporate products into the graph model. Figure 2b shows the supply network from Figure 2a with products as nodes. Continental’s enterprise is replaced with three products. The supply network lacks a connection from NXP’s chip to BMW’s car. It becomes evident that BMW’s car production does not depend on NXP. Therefore, a supply network graph that models products and their supply relation is suitable for our use case.
However, the supply network graph must not ignore the relationship between a product and its enterprise as this information is necessary to identify suppliers. Adding enterprise names to the node labels in Figure 2b does not establish a connection between Continental’s products in the data and cannot be evaluated by a query. Furthermore, the dependence on certain products in a supply network may decrease if an alternative product exists. The cockpit computer in Figure 2b may either use the chip from Qualcomm or Nvidia.
Knowledge graphs ofer the necessary structure to express more sophisticated entities and the relations between them. Knowledge graphs are a suitable representation of supply networks (a) Enterprise supply network. (b) Product supply network. (that resemble graphs) enriched with further data. Ontologies ofer a way to model the schema of knowledge graphs. Ontologies provide a taxonomic approach to managing complexity, the necessary expressiveness for knowledge as well as data integration, and a precise formal foundation. Therefore we develop an ontology as a model for the supply network graph.
While PRONTO is designed as "a heavyweight ontology" [20, p. 1308], we seek a small, more lightweight ontology that can be easily understood and utilized. A wider audience beyond dedicated ontologists should be able to make use of the ontology as ontologists are rare in enterprises. A simpler ontology also reduces the amount and complexity of available data that is required to instantiate the ontology. Available data is limited in practice as most enterprises have little data on their supply networks and the coverage of deeper tiers quickly declines [22]. The goal for the ontology is a one-size-fits-all solution that can be applied across all industries (such as automotive, textile, electronics, food) and types of supply networks (potentially involving multiple industries). This approach should make the ontology more applicable.
Marquardt et al. [23] presented a series of ontology design principles that provide a credible indicator of ontology quality. These principles are coherence, conciseness, intelligibility, adaptability, minimal ontological commitment, and eficiency. The PRONTO ontology adopted these principles with a suitable balance between them [20].
The development of our ontology has a particular focus on conciseness. "The principle of conciseness, a.k.a. minimality or minimization, demands (i) to reduce the number of vocabulary terms to the necessary minimum and (ii) to avoid redundancy with respect to axiomatic definitions. A concise ontology is easier to understand, easier to apply, and easier to maintain" [23, p. 355]. Conciseness is particularly relevant for a small ontology.
We identify the domain of the ontology (its competence) with a set of competency questions. The competency questions provide a characterization of the ontology as well as an understanding of its scope and limitations. The ontology must be usable to model instance data that can answer queries based on the competency questions. The competency questions were chosen to support the identification of bottlenecks among suppliers by providing data on a supply network on which network measures can be conducted.
1. How many/much of a certain product does the creation of a product require across the supply network? 2. How many derivational dependency paths from a product to another certain product are there in a supply network? 3. Which enterprise sells a certain product in the supply network?
Based on the assessment of the ontology’s goals so far, we identify the following modeling requirements, which guide the design of our ontology.
1. Provide a representation of products that are available for (potential) customers. 2. Provide a representation of the enterprise that sells a product. 3. Provide a representation of derivational dependencies between products of diferent enterprises, specifically all dependencies where a product is (partially) consumed in the process of creating another product. 4. Provide a representation of the quantity of a dependency. 5. Provide a representation of a derivational dependency being split between alternative products.
PRONTO also covers these modeling requirements, but not in a specifically concise way. We omit the following modeling requirements considered by PRONTO.
"Handle the representation of product variants using the concepts of product family and generative BOMs" [20, p. 1309]. Product variants contribute significantly to the complexity of PRONTO. To achieve a small, concise ontology, we abstract products and product families to a single concept (cf., Section 5). The expressiveness of our approach is still suficient for our use case.
"Support the management of constraints in the derivation of product structures" [20, p. 1309]. Due to the omission of dedicated product families, the structural hierarchy does not include component combinations derived from product families. Therefore, we do not require constraints.
workforce or facilities that are disjoint with products. The creation of a product might depend on human workforce, facilities, and equipment, but the dependency is considerably smaller than on entities that are consumed in the process of creating a product. Without new human workforce, facilities, and equipment, the creation of new products can continue as these entities persist. Without new consumed entities, the creation of new products halts. The consumption of an entity is therefore the required criterion for the representation of entities a product depends on.
The concept of a product is often defined from a sales perspective as an entity ofered to customers [21, 17]. An intermediate entity that is the result of a manufacturing process in an enterprise and later only used for the creation of products of that enterprise is therefore not a product [17]. The product concept only covers entities exchanged between enterprises. With regard to the dependency relation to products of other enterprises, intermediate entities are abstracted into the products they derive into. A car by BMW is manufactured with a door also manufactured at BMW. The door is built using a keyless transceiver from Continental. For a product abstraction, the car individual depends on the keyless transceiver individual, disregarding the door.
Products may be created in discrete or continuous manufacturing such as the chemical industry [18]. The products concept also extends to services [21, 19, 18]. Earlier we noted that the consumption of an entity is required for entities a product depends on. If we state that a product depends on other products and products incorporate services, services must be consumable in the creation of products. That is the case if services are not an infinite pool but a limited amount of depletable (time)slots. The foundry service of TSMC for example is only available in limited amounts and a bought slot is not anymore available. That specific slot derives into the manufactured product. Should a service be limitless (e.g., software licenses), the dependency is on another level that we do not consider.
Some ontologies consider the concept of products on multiple abstraction levels. There is a distinction between a product individual/instance (as a class) and a product model [21, 19]. The former represents a very, single identifiable entity while the latter represents the specification of an entity in the sense of a prototypical description. At a car dealership, one can buy "a BMW iX" (product model) or "that blue BMW iX over there in the corner" (product individual/instance). For the identification of bottlenecks among suppliers, a supply network graph at the product model level is suficient and requires considerably less instance data.
Another abstraction is possible between a product and a product group/family [21, 20]. The latter represents similar products having alike structures, similar characteristics, and production routes, that vary only in certain well-described ways, such as by size, color, or material. The car "BMW iX" could be seen as a product group/family with all the diferent configurations of the car as members of that product group/family. As we seek a small, concise ontology, we abstract products and product groups/families into a single concept. Enterprises may decide themselves if variants deserve a distinct representation or if a single representation is suficient, depending on the complexity of products and variants as well as on the tradeof between efort and payof.
Further abstraction is that of a product class that describes products with the same functionality and/or physical characteristics used for achieving the same goal [19]. The product class for the "BMW iX" would be "car". This abstraction is not associated with specific enterprises or supply networks and therefore too high to identify bottlenecks among suppliers.
Several ontologies contain a concept for the structural hierarchy of resources or products similar to a "partOf" relation [15, 16, 20]. The relation is transitive, non-reflexive, and antisymmetric [16]. The creation of products can have the nature of a composition (several products turn into one) or a decomposition (one product turns into several) [20].
As established earlier, the dependency between two products in a supply network is characterized by the (partial) consumption of one product for the creation of the other. This does not necessitate that a product becomes part of a (physical) presence of the created product. Examples are chemicals used for cleaning in the manufacturing of chips or the foundry service slot. Neither example becomes a chip, but without them, no new chips are created.
Any foundational or spatial relation [25] between entities is therefore ineligible in our case. A temporal relation is however suitable as the consumed entities stop existing when a new product is created. The concept of derivation represents a relation between distinct entities when one succeeds the other across a temporal divide2. Therefore, we model our supply network graph using derivational dependencies between products. The derivation of multiple products into a certain product must not happen simultaneously as we abstract products to include intermediate entities.
Usually, the derivation relation is between two products to express the dependence of one product on another. The creation of a product might involve alternatives if substitutes for consumed products exist [15, 16, 20]. To represent a dependence on multiple alternative products, a single derivation may relate multiple products.
The existence of a derivation relation between products states a dependency but not its quantity. A car might require one cockpit computer but four doors with respective door parts. A quantity property states how many of a product must be consumed to create a product [20]. The quantity number might be a fraction if one product is derived into multiple products. Besides a quantity value, a unit property provides information on the unit of measurement of a volumetric entity (e.g., corn or oil) [15].
The identification of bottlenecks among suppliers requires a relation that connects the products in the supply network graph with their respective enterprises. Existing ontologies use an owns relation to express the possession of a product [21, 19]. We want to express which enterprise supervises the creation of a product and sells the product to (potential) customers. Therefore we use a sells relation between an enterprise and its products.
The ontology is evaluated in two ways. First, we compare the ontology to PRONTO for an evaluation of our target of a small, concise ontology. Afterwards, we demonstrate the capability of the ontology to answer our competency questions.
PRONTO was evaluated using metrics to assess its structural complexity [20]. We applied the same metrics to our ontology and compare the results in Table 1. Notably, our ontology is much smaller but contains relatively more properties.
Regarding the competence of the ontology, we use the example supply network shown in Figure 4 to answer our competency questions. For the first question, we determine how many 10nmSlots the creation of one iX needs. We calculate 2 * 0.004 + 1 * 1 * 0.004 + 1 * 1(1 − ) * 0.005 = 0.013 − 0.001 * = 0.0125 with the factor weighting the alternative between Snapdragon8 and T500 set to = 0.5. The second competency question on the same data results
Metric
Number of classes Number of relationships Number of leaf classes Number of root classes Relationship richness
Inheritance richness Depth of subsumption hierarchy
Attribute richness in the 3 paths we used to calculate question one. For the third question, the enterprise selling iX is BMW.
The paper introduced an ontology representing supply networks of products with derivational dependencies between them as a graph model to identify bottlenecks among suppliers in supply networks. The ontology is concise and considers various concepts and definitions from existing ontologies. We compared the ontology to PRONTO, an ontology with a similar scope.
Our approach comes with some limitations. Our high abstraction level of products that disregards product variants limits the ability to model all product cases. The expressiveness of our concise ontology is naturally limited compared to heavyweight ontologies like PRONTO.
To identify bottlenecks among suppliers, we ofer a model to instantiate data with a supply network graph. However, our paper does not provide guidance on which network metrics and measures to use for identifying bottlenecks. Hereof, further questions remain. How to execute the necessary calculations of metrics (with queries)? How to weight and aggregate quantities regarding alternative products?3 When a derived product includes variants, how to determine the weights of quantities if a product is only required occasionally? Real supply networks overlap with each other. Each product in the example from Figure 4 would have various other (possible) derivations in other supply chains. How to consider overlapping supply networks in the identification of bottlenecks? Addressing these questions will enhance the ontology’s applicability in real-world supply network scenarios.
Partially funded by the German Federal Ministry of Education and Research (BMBF) through the project “Velektronik” (FKZ 16ME0224) as well as the German Federal Ministry for Economic Afairs and Climate Action (BMWK) through the project "Antrieb 4.0" (FKZ 13IK015B).
3In the evaluation in Section 6, we took the naive approach and set = 0.5.