This study shows how the semantic rules in conjunction with ontologies can be used for managing the intricate network among supply chains partners. Nowadays, an enterprise is no longer a self-sufficient firm but an integral part of supply chain. When structuring a supply chain network, it is problematic to identify who the partners are across multiple supply chain tiers. Worst, an inclusion of potential partners may cause the links to become an intricate network. We introduce ontological knowledge framework which first building concepts for defining enterprises and products, describing instances with properties as facts, and developing semantic rules to infer inter- and intra relationships among facts. The major advantage of this design is its ease to implement that individual firm and its parts manage their direct and known knowledge. Small examples were presented using ontology and semantic rules.
Modern business competition is no longer individual company versus another
company but two opposite supply chains against each other [
Traditional supply chain focused on enhancing efficiency of business functions.
However, modern business encounters dynamic products and complicated
supplydemand relationships more then ever. At the strategic manufacturing planning level,
capable firms must not only control and collaborate with existing supply chain
partners efficiently but also need to keep watch for potential partners [
As mentioned above, identifying entire supply chain partnerships is one of key success elements in modern manufacturing collaboration. Without knowing which partners of a supply chain, planning system cannot establish specific supply chain visions. Absence of knowing potential partners, we cannot make an agile composition of supply chain partners. To extend supply chain planning and control, the main purposes of this study are threefold: (1) How to identify who the partners of the entire supply chain are. (2) How to implement network traversal; and (3) How to provide mechanism in managing a composition of supply chain partners. This study first utilized ontological knowledge framework to model the task domain related to supply chain partners. Then, we developed rules to define how supply chain partners are behaved, how a production planning is made, and so on. After knowledge and rules have been built, existing facts can be linked to generate and infer proper connection of a spanned network. 2
Issues in making a successful supply chain can be various and complicated. This
study is interested in structuring supply chain networks. That is, who are the members
with whom to link processes? Since a wide spectrum of the supply chain partners can
be extended as an intricate network, connecting suppliers across multiple tiers of
entire supply chain is a challenge task. Increasingly, the efforts of constructing the
supply chain include model building, facts and relationships collection, and lots of
domain knowledge accumulation. In order to better manage supply chain members,
knowledge-intensive approaches such as ontology is suited to the occasions. Several
ontology engineering approaches and implementations have been discussed in studies
[
Ontology provides an explicit specification of a conceptualization to express
shared human perspectives of the real world [
In order to elucidate the principles above, this study assumes partnerships among supply chain members are based on supply-demand relations of products or services. We first determine the scope of the task domain and the vocabulary necessary to describe the conceptual structures. The preparation stage of knowledge acquisition was implemented on collecting relevant concepts and properties of supply chain members. As shown in Table 1, basic concepts of supply chain such as Company and Product are identified. A listing of properties beyond each concept is used to describe concept’scharacteristics.Regardingthevalueinsideproperties, this study informally divided properties into two categories: “Asserted Properties” and “Inferred Properties”.Assertedpropertiesareallowinginputknownfactsorcalledexplicit knowledge.Forexample,company’sLocation and Capital are known facts. Inferred properties are unapparent facts or called implicit knowledge that leads an inference using known facts or assumptions. For example, Potential_Suppliers and Potential_Customers can be inferred by known facts.
To select notation or formalism used for representing the knowledge to be stored in
ontology, OWL (Ontology Web Language) is utilized in this study. OWL is being
developed by the W3C Web ontology working group. OWL is primarily designed to
represent information about categories of objects and how objects are interrelated [
OWL ontology is designed to represent information about concepts of instances
and how instances are interrelated. Description Logics (DL) further helps concepts to
formally definerestrictionsthatconstrained instances’behaviors.Consequently,
OWL ontology with DL facilitated knowledge model in an abstract view. In this study,
however, an individual firm in a supply chain may have multiple roles such as a
supplier, a customer or both roles. The roles of a firm are dynamic depending upon
the needs of its products (i.e., OWL instances) in supply-demand relationships.
Therefore, semantic relationships of individuals are usually described by its properties
rather than its concept. Horrocks et al. have reported several DL inference limitations
in instance properties such as syntactic, expressive, and computation [
Implementing this rule would take variant individuals to indicate corresponding
variables. For example, the following particular individuals C1, C2, C3 indicates
variables x, y, z respectively. After inference computing, individual C1 obtains a 2nd
tier’ssupplierC3. SWRL also supports built-ins predicates, which expand its
expressive power such as comparisons and math operations. Theprefix“swrlb:”is
used by convention to denote the SWRL built-ins namespace. For example,
swrlb:subtract(?a, ?b, ?b) is math built-ins. The SWRL rules can be edited in the
Protégé OWL platform by choosing the plugin named SWRLTab. The rule engine
such as JESS (Java Expert System Shell) needs to connect in the Protégé platform
before execution. The JESS software consists of three components including a rule
base, a fact base and an execution engine [
The SWRL rules editor plug-in is a Java-based API, called SWRL Factory, which allows developers to access SWRL rules in OWL ontologies. On the other hand, JESS rules engine also provides a Java-based API, called SWRL-JESS Bridge, to execute its rule engine. For applications development needs, developers can use both APIs to develop runtime interactions programmatically. 4
This study has experimented with OWL ontology on building supply chain partners knowledge. Three examples of using SWRL rules are shown below in finding multipletiers’suppliers,potentialsuppliers,andaproductionplanbasedonavailable capacities of products. The representation of SWRL rules is relatively straightforward. We have noted that there are several possible ways to reach same rules functions of our examples. Once the rules have been represented, the JESS engine can perform rules inference. As rules fire, OWL asserted facts, inferred facts performed by the DL engine, and SWRL rule facts can be inserted into the fact base.
An Individual firm usually has various products that are supported by different partners. To find all suppliers across multiple supply chain tiers, SWRL rules are utilized to explore relationships starting from interpreting products rather than suppliers. For example, the following SWRL rule would be to assert that the combination of hasProducts, needParts and Factory properties implies the Suppliers property. hasProducts(?x, ?y)^ needParts(?y, ?z)^ Factory(?z, ?a) Suppliers(?x, ?a)
The above rule provided only a general syntax for finding next suppliers. Users can iteratively perform the rule to find the furthest upstream partners of the supply chain. Fig. 2 containedⅠ,Ⅱ and Ⅲ blocks to demonstrate successive iterations. Inside each block, a shaded rectangle represents a company, a circle represents single product, small shaded circles represent properties of a class, and arrow lines denote inference progression. The facts data can be inserted into variables (e.g. ?x). From this rule in the first block, if the C0 company has P0 product, P0 need P1 parts, and P1 is manufactured by C1 company then C0 company get a supplier is C1 company. The second block performs the same rule but giving different facts. The rule inference result is from C1 company and P1 product to infer that C1 company has a supplier C2 company. Table 2 listed the iterations step by step. Through properties conjunctions of the SWRL rules, users can possibly obtain suppliers across entire supply chains. Example 2: Finding potential suppliers across multiple partner tiers.
The Previous example has shown how to identify contract suppliers of a firm. In this example, we try to find potential suppliers. The potential suppliers are simply defined that they are capable to provide products with same functions to satisfy the needs of a customer. To identify potential suppliers, SWRL rules first identify the product type of existing supplier and then using the product type to seek suppliers which manufacture same type of products comparing with existing contract suppliers. The following SWRL rule asserts that the conjunction of hasProducts, needParts, Factory, hasType and hasFactory properties can be used to conclude who are the potential suppliers and assign company names into the Potential_Suppliers property. hasProducts(?x, ?y)^ needParts(?y, ?z)^ Factory(?z, ?a)^ hasType(?z, ?w)^ hasFactory(?w, ?b) Potential_Suppliers(?x, ?b) Example 3: A production forecasting based on available capacities of products The last example about production forecasting is much more complex. Assuming a firm plans to raise 20% production of a product. If contract suppliers have available capacity, they have a high priority to join the new plan. If contract suppliers are short of production capacities then potential suppliers become new suppliers of the plan. To simplify this scenario, two assumptions are made: (1) each company has reported accurate capacity utilization; (2) a product and each composing part are a 1-to-1 relationship. Three SWRL rules are given to implement the planning goal. ˙
ThefollowingSWRLruleutilizesthevaluesofproduct’sassertedpropertiesand some SWRL math built-ins functions to calculate available capacity of each product. The swrlb:subtract(?a, 1, ?y) requires three arguments that the first argument is the arithmetic difference of the second argument minus the third argument. The swrlb:multiply(?b, ?z, ?a) also requires three arguments that the first argument is the arithmetic product of the second argument multiplies the third argument. From this rule, if P0 product has an asserted capacity utilization (i.e. ?y; say 80%), the value of available capacity utilization will assign 0.2 to ?a (e.g. 1-0.8= 0.2), P0 has an asserted monthly production capacity (i.e. ?z; say 20000), the amount of available capacity will assign 4000 to ?b (e.g. 20000* 0.2= 4000) then the value will be inserted into the Available_Capacity property of the product.
Capacity_utilization(?x, ?y)^ swrlb:subtract(?a, 1, ?y)^ capacityMonth(?x, ?z)^ swrlb:multiply(?b, ?z, ?a) Available_Capacity(?x, ?b) ˙
The following SWRL rule selects qualified contract partners by verifying that the available capacity of a product is grater then a value. Assuming a firm decides to increase 2000 units of a product. From this rule, if C0 company has P0 product, P0 needs P1 parts, P1 is manufactured by C1 company, obtaining the value of the Available_Capacity that we have calculated, and using a SWRL math built-ins function swrlb:greatThan(?a, 2000) to compare with the number 2000 then the qualified suppliers are inserted into the Plan_Suppliers property of the product. Fig. 4 demonstrated the identifying process step by step. hasProducts(?x, ?y)^ needParts(?y, ?z)^ Factory (?z, ?w)^ Available_capacity(?z, ?a)^ swrlb:graterThan(?a, 2000) Plan_Suppliers(?x, ?w)
If contract suppliers are unavailable to support the capacity needs of the new plan, a firm has to seek qualified potential partners. The criterion of selecting partners is verifying available capacity of a product is grater then the set value. From the following rule, if C0 company has P0 product, P0 looking for potential suppliers from Potential_Suppliers property of the product, obtaining the products from potential suppliers, and using comparing process to confirm the available capacity of a product great then 2000 then the supplier will be inserted into the Plan_Suppliers property. Fig. 5 demonstrated the identifying process step by step.
hasProduct(?x, ?y) ^Potential_Suppliers(?y, ?z) ^hasProduct(?z, ?a) ^ Available_Capacity(?a, ?b)^ swrlb:greaterThan(?b, 2000) Plan_Suppliers(?x, ?z) A successful SCM requires constructing close relationships with suppliers and customers in order to survive in the highly competitive market. Since supply chain is a network of multiple businesses and relationships, monitored activities of business partners across multiple tiers of a supply chain is challenges. To address complicated relationships among partners, this study introduced an ontological approach to model knowledge about specific tasks. Based on knowledge engineering principles, this study identified necessary concepts, characteristics, and relationships among supply chain members. Then, the Protégé OWL tool is utilized to edit this knowledge into OWL-based ontologies. Since OWL ontology mainly provides an abstract view in the concept level, semantic relationships among individuals are difficult to discover. SWRL rules provide procedural knowledge power to enhance limitations of ontology inference especially in discovering semantic relationships among instances. This study then utilized SWRL rules in conjunction with ontologies to manage the intricate supply chain network. Three examples were provided including finding contract suppliers multiple across multiple tiers of supply chains, finding potential suppliers, and a production plan based on available capacities of products.
Since the knowledge of supply chain partners have been built, more applications can be further created to infer new and implicit knowledge. Based on our experiences with building SWRL rules and OWL ontologies we conclude that such approaches will be crucial to achieve the following advantages: ˙ Developers has captured and modeled knowledge of the task domain into ontologies that the computer has all the knowledge needed to solve specific problems. ˙ Information holders only need to edit or update their known facts as ontological knowledge. The separation of knowledge framework and information collection makes easier for both developers and users. ˙ The rules are solid expertise of common agreements that describe how things get done. Existing facts obey the guidance of predefined rules. If facts change, new connections of supply chain networks can be rapidly rebuilt by inference services.
Although this study presented only a few simple examples of tracing suppliers, the ontology is scalable by including more factual individuals, enterprises, products and product types. Further, by following the above development processes, both domain ontology and task ontology can be expanded to solve more complex and practical problems. A Web-based system can be developed by simply utilizing Java-based applications supported by Jena API, Protégé API and SWRL API. Consequently, an inferred ontology can be considered a knowledge base with intelligence. Acknowledgment The author would like to thank the National Science Council (NSC) of the Republic of China, Taiwan, for financially supporting this research under Contract No. NSC 96-2416-H-033-002-MY3.