Ontology Querying and Its Software Component for Design Support in Supply Chains

Incheon Paik - Address : University of Aizu, Computer Science and Engineering, Tsuruga, Ikki-machi, Aizu-

Wakamatsu City, Fukushima, 965-8580, Japan- e-Mail : paikic@u-aizu.ac.jp

Hiroyuki Akimoto- Address : University of Aizu, Computer Science and Engineering, Tsuruga, Ikki-machi, Aizu-

Wakamatsu City, Fukushima, 965-8580, Japan- e-Mail : akimoto@ebiz.u-aizu.ac.jp

Ontology Querying and Its Software Component for Design Support in Supply Chains

ABSTRACT

Effective support of product design stage in the supply chain management (SCM) is important for raising the

competitive power of a company. Existing technology for design support of supply chain has limitations on

managing semantic data and handling logical operations, which agents will use for their intelligent and

autonomous activities. In this paper, we suggest an ontology querying mechanism and software component for it,

based on the supply chain network, for the agent’s intelligent activities. This querying engine can service several

operations, including reasoning and logical functions, together with the ontology of the specified domain of

product attributes and its instance data. We defined operators to provide the necessary ontology query according

to the operation category in the domain of design support in SCM, which will be provided as several interfaces in

the form of server side components and Web service. Finally, we explain the meaning of our querying system,

comparing with the early version and other querying systems.

INTRODUCTION

The market environment of e-business has changed rapidly by consolidation of the Information Technology (IT)

infrastructure. In an environment of rapid technology innovation and diversification of customer’s needs,

optimization of the supply chain is an important issue for companies desiring to remain competitive. In particular,

the product design, the first stage of supply chain management (SCM), is important because it influences the

efficiency of the entire SCM.

To support this design stage, some information infrastructure based on semantic Web (Paik et al., 2004; Paik &

Park, 2005), which provides a multilateral view to designers, was developed to optimize SCM for business-to-

business (B2B) collaboration. This information infrastructure provides an environment that has attributes of cost,

1

function, quality and technology to manage the SCM efficiently. More reliable product design in the supply chain

(SC) can be achieved when these attributes are integrated organically.

The semantic Web supports an unambiguous machine-interpretable environment with logical operations on the

existing Web. Ontology and its description language, ontological service description framework, and related query

language systems can contribute to the design support in the SCM. In a semantic Web environment, we can

describe each kind of business data, such as product attribute data, as ontology, and its instances can provide clear

semantic meaning. To process this ontological data, we require a dedicated query engine. This ontology can

provide a consistent taxonomy and an integrated concept for the target data. Furthermore, on a higher level, the

semantic Web can provide a service description to outside agents, such as general users or automating agents,

through a service description, such as Web Ontology Language-Service (OWL-S) (OWL Service -

www.daml.org/services/). The methodologies and tools enable full understanding and processing of these

languages, such that a virtual machine would be required for a more automated environment. A more seamless

and automated Web environment for e-Business will be realized by combining the Web service with the

intelligence from the semantic Web.

On the other hand, according to the need of the scalable and high-performance computing to handle distributed

business transaction, security, and directory services, many middleware infrastructures have been developed such

as Corba, Java 2 Enterprise Edition (J2EE), or Component Object Model (COM) technologies together with the

existing Web technologies (Gorton & Liu, 2003). The server-side software component such as Enterprise

JavaBeans (EJB), Distributed COM based on Component Based Software Development (Brown & Wallnau, 1998)

have become a robust infrastructure to support reusable software and easy construction of business logic at back

office of application server. The interfaces of software component of business logic to provide services for

ontology querying on special domain will be useful for both developers of business logic and users of those

interfaces.

In this paper, we focus on a querying system and its software component for product attribute ontology and its

instance data to decrease a client’s or agent’s work while pursuing improvement of the early version of the

ontology query engine, with the prospect of a system constructor. New service operations for reasoning and

logical functions together with the ontology of the specified domain of product attributes and its instance data

2

were developed. The following sections provide a detailed discussion of ontology querying software component.

We provide an example scenario to help understand the necessities of ontology querying to illustrate our

contribution. At the next section, the concept of integrated design attributes, which are our basic ontology data to

be processed, will be explained briefly. These tables will form the basic framework for product attributes and their

integration. And a general ontology in our supply chain network will be described, from which real product

attribute information can be derived. In this ontology an improved intelligent ontology querying service will be

explained together with the entire system architecture and operation flow. To show a running case for our

scenario, we illustrate the application of our querying engine to application-centric agents. In addition, we provide

a performance evaluation of our system, comparing it with former studies to evaluate its practicability. Finally, we

conclude by highlighting the meaning of various ontology querying systems to support design in the SC.

MOTIVATING SCENARIO

Currently, when companies make a product, they usually consider the quantity, price, and delivery of

components for products in the supply chain. When companies design an innovative product, they consider

combinations of the four product design attributes. Integrating these four attributes into one infrastructure

produces positive effects on the design in the supply chain. To begin our explanation, consider the two following

scenarios.

Scenario A. A flashlight company has a plan to increase the quality “Brightness” of its existing flashlight from

7.5 cd/mm2 to 10 cd/mm2. The company wants to know which components must be changed, what technologies

will be required, and what costs will be incurred.

In this scenario, to discover the answers to these questions, the designer must look for several product attribute

databases, distributed along the supply chain network, with cross-references (e.g., quality–component or quality–

technology). In an early version of the information infrastructure, as relation ontology was designed to cover the

query for cross-references, the query engine answers these questions as a normal query (see next section.)

Scenario B. A designer wants to look for “the parent component of Glass Ball” to obtain the cost of “upper part of

Glass Ball” and the list of its sibling components excluding plastic. If we did not have a dedicated database

schema and query system, it would be difficult to find the answer to this question. Furthermore, to provide and

3

maintain services with complex functions at the higher level would be more complex and difficult. In the semantic

Web service world, the description language of ontology simplifies the provision of services for logical operations

at the higher level.

INTEGRATED DESIGN ATTRIBUTES TABLES

Four product attributes, the basic entities of the information infrastructure for design support, are mutually

related. They are made to adapt to rapid informational changes by connecting them relationally. The optimal state

of the SCM can be maintained by sharing the product design data of the four attributes (fitting cost, function,

quality, and technology) among all the SCs. These attributes are represented by four tables, of component cost,

quality, function, and technology.

Information infrastructure for design support manages the data schema, consistency, and query of the four

tables corresponding to the four product design attributes. The component-cost table describes the composition of

a complete product, which can be hierarchically broken down from the root node (complete product) into its

subcomponents and finally to the material sources through the supply chain. The final cost of a product can

therefore be calculated from the costs of every subcomponent. All the components can be expressed in a tree

structure in which the nodes have the relations of super classes and subclasses. Each component cost is divided

into the parts cost, which includes the materials cost, and the manufacturing cost.

In Figure 1, a “Flashlight” consists of “Cover”, “Light” and “Power Battery”. “Light” consists of “Miniature

Bulb” and “Socket”, and “Miniature Bulb” consists of several terminal nodes. The parts cost is the cost when

purchased from outside, and the manufacturing cost is the cost of the technology, methods of construction,

equipment, and management technology used.

The function table consists of functions broken down into smaller tasks by functional analysis using value

engineering, which defines functions related to the product and creates a functional system diagram and

component-cost table classified according to function. The quality table consists of qualities that have been broken

down into smaller quality units using a Quality Functional Deployment (QFD) technique, which maps user

demands for the product onto alternative characteristics, defines the design quality of the final product, and

4

develops relations systematically between items (function, quality of the components, etc.) related to quality. The

technology table lists the techniques or means identified by simple terms in the database, which represent the

addition of human work to natural items to make them more useful. Here, we store technical names and technical

contents in a database describing the technologies previously used for existing products. If technologies are

intended for a new product, technical deployment similar to QFD is necessary. Detailed construction methods and

examples are described elsewhere (Paik & Park, 2005).

Figure 1. Structure of Product Attributes

5

ONTOLOGY QUERYING SYSTEM

Semantic Web Service Framework

The approach to semantic Web ontology was designed from two pragmatic perspectives in information

infrastructure. The first is the definition of taxonomies to unify the four attributes, and the second is the definition

to improve the agent’s activities. The definition of taxonomies is shown in Figure 2. The concept corresponding to

each table is defined in the ontology description.

This ontology enables product design attributes to be described consistently in an ontology description

language, OWL. Detailed catalog data of each company for product design can be in itiated from this ontology,

and those data can be processed by the XML querying system or the ontology querying system.

Figure 2. Ontology For Design Attributes in UML

6

To retrieve the target data within the data, the normal XML processor, the XML query processor, or the

ontology query processor can be used. The query processor of the early version was implemented using Xpath

(Paik et al., 2004). This query engine can deal with basic data retrieval (the case of scenario A) at the same level

of database querying in SQL. To deal with higher logical reasoning operations, the functions for generalization

(Akahani et al., 2003), specialization, traversing, and local relation tracing are required. Furthermore, for more

intelligent and autonomous activity of the agent, discovery and execution of the service descriptions are required

to be understood semantically and processed automatically, but these are beyond the scope of this paper.

Generalized Ontology Query Model

Intelligent Ontology Querying. Ontology-based intelligent querying interprets the meaning of data and answers a

query according to the semantics. Unlike existing simple searches of text or relational databases, it can fulfill the

user’s demands without defining a complicated query procedure. For example, we can illustrate that the

specialization, or generalization, of some item in the ontology description can cause a higher logical operation and

concept induction according to the clients’ or agents’ requests.

Specialization is the operator that selects the node of the more concrete semantic (i.e. concept of sub class) than

the source node on the ontology tree. For example in our scenario, the result of the specialization the sample

operator “Cover” in List 1 is “Plastic1”. If we try to realize this operation using existing XML API, we have to

write an algorithm to perform “Get all subClass of node, get all attributes of its node, and compare its text with

Cover”. Therefore, this work would be not only time consuming but also difficult to maintain.

Generalization is the operator that selects the node having more abstract semantics than the source node. For

example, the result of generalization of sample operator “Cover” in List 1 is “Flashlight”. As well as these two

operators, several other logical reasoning operators are described in the next section.

Generalized Concept of the Ontology Query Model. Ontology in the semantic Web has an important meaning

when it can provide a reasonable answer to queries related to semantic understanding and logical reasoning as

well as general relational database queries. Further to this, the ontology query engine should be able to understand

all semantic meanings of the information in a domain and trace all the relationships between classes and attributes

to find an answer with logical connectives or set operations, such as reverse, conjunction, disjunction, union, etc.

7

List 1. Example of Instance for Product Attributes Ontology

Intelligent ontology querying is classified into two domains by their behavior: Node-Tracing and Node-

Information. The node-tracing domain is related to traverse and obtains the necessary nodes as all the ontology

nodes with unambiguous semantics. The node-information domain deals with gaining information of the nodes’

attributes. Every operator in each domain has also sub-logical connectives and set operations (not, reverse,

conjunction, disjunction, union, intersection, transition, etc.) in the form of a parameter. Furthermore, both

domains are divided into categories according to type of operator. In the Node-Tracing domain, there are

Vertical Logical Operators, which trace the relationships of the semantics vertically, a Horizontal Logical

Operator that traces horizontally, and a Characteristic Based Operator that obtains the target objects from their

characteristics. In addition, in the Node Information domain, there are the Property Related Operator, which

gets node attributes, and the Node Related Operator, which analyzes the XML definition of the node

information. The corresponding relations of categories and methods are shown in Table 1.

Table 1. Domains and Categories of Operators

8

<ComponentCostScheme rdf:ID=“#FlashLight”><rdfs:label>flashlight</rdfs:label><rdfs:comment/><subComposedOf rdf:resource=“#Cover”/><subComposedOf rdf:resource=“#Light”/><subComposedOf rdf:resource=“#PowerBattery”/><subComposedOf rdf:resource=“#Strap”/><subComposedOf rdf:resource=“#Connection”/><materialCost>55.2</materialCost><manufacturingCost>44.8</manufacturingCost><componentImportance>47</componentImportance></ComponentCostScheme><ComponentCostScheme rdf:ID=“#Cover”><rdfs:label>Cover</rdfs:label><rdfs:comment/><subComposedOf rdf:resource=“#Plastic1”/><subComposedOf rdf:resource=“#Plastic2”/><subComposedOf rdf:resource=“#Bond”/><materialCost>10.0</materialCost>

<manufacturingCost>8.0</manufacturingCost><componentImportance>5</componentImportance></ComponentCostScheme>

Domain Category Methods

Node

Tracing

Vertical Logical Operator getParents, getChildren,

getAlldescendant, getRoots

Horizontal Logical Operator GetBrothers

Characteristic Based Operator getNodeFromAttribute,

getRelatedInstances

Node

Informat-ion

Property Related Operator getProperties, getDifferences

Node Related Operator getPrefix, getShortestRoute,

getSizeOfAttachedScheme

As an example in our query scenario, we illustrate the logical operation “getBrothers”. In Table 1, we can get

the all brothers of “Cover”, which are “Light”, “Power Battery”, “Strap and “Connection Part” intuitively. To

process the query “getBrothers”, the parameter to be queried (i.e., query data) should be explored on the ontology

tree to find the parent class. Generating a triple for reasoning can perform this operation. In our system, we used

the OWL Query Language (OWL-QL) (DQL Project-ksl.stanford.edu/projects/dql/, 2002; DAML Query

Language,2002 - www.daml.org/2002/08/dql/; Fikes et al., 2003) server and Java Theorem Provider (JTP) (JTP -

www.ksl.stanford.edu/software/JTP/) to trace triples and reasoning on the ontology tree (Figure 3). After the

parent class of query data has been found, the child classes can be found similarly.

The query system in detail is an interface of the information infrastructure generates an OWL-QL syntax from a

request by a user and sends it to the OWL-QL server. The OWL-QL server analyzes it and performs reasoning

using JTP, which is a modular reasoning system of OWL implemented in Java. Jena (Jena Semantic Web

Framework - jena.sourceforge.net/index.html) is used in the JTP package to process OWL. The result is converted

to OWL-QL syntax by the OWL-QL server. The result is extracted from its syntax, and returned to the user as the

answer to the ontology querying.

In the early version of the information infrastructure, there were 144 interfaces for querying product attribute

data and their related data in the form of EJB and Web service interfaces (Figure 4). We prepared another Session

Bean for these new logical operators, which consist of 12 interfaces.

9

Figure 3. Ontology Querying Procedure

System Architecture

Information infrastructure is a server side application, which consists of sets of the components of EJB in the

business logic layer (Figure 4). All components run in the environment of J2EE where those components are

deployed.

Business logics for process and management of product ontology data are implemented by EJB and are

provided as interfaces of these server side software components. The information on 10 tables managed by the

Session Bean is converted into a DOM tree, and Java API for XML Processing (JAXP) is used for management.

The operation of the information infrastructure starts from the Session Bean, then is transferred to the Entity Bean,

and to the query engine.

These interfaces of operations are included in the Web service for strong openness, discovery, and

interoperation. A service description, in OWL-S, is also provided with consistent WSDL grounding. By matching

10

all the interfaces to SOAP, remote clients are able to access the information infrastructure. When a client has no

security restriction, it is also possible to access the EJB directly using an RMI/IIOP interface.

Table 2. Operators of Ontology Querying

MethodSpecification (node ∋ { ComponentCost, Quality,

Function, Technology, Attribute } )Example

Get parents Getting parents of inputted node

getParents: node_name → ∩node

GetParents(“Cover”) → “Flashlight”

Get children Getting children of inputted node

GetChilds: node_name → ∩node

getChildren(“Flashlight”) → “Cover”,“Light”,“Power

Battery”,“Strap”,“Connection Part”

Get all

descendants

Getting descendants of inputted node

getDescendants: node_name → ∩node

getAllDescendants(“Light”) → “Miniature

Bulb”,“Socket”,“Glass Ball”,“Filament”,“Prop”,

“Soldering”,“Carbon Copper1”,“Plastic3”,“Carbon

Copper2”,“Solvent2”

Get brothers Getting brothers of inputted node

getBrothers: node_name → ∩node

getBrothers(“Cover”) → “Light”,“Power

Battery”,“Strap”,“Connection Part”

Get the shortest

route between

nodes

Getting the shortest route between the nodes from the

inputted two nodes

getRoute: node_name → ∩node

getRoute(“Power Battery”,“Miniature Bulb”) → “Power

Battery”,“Flashlight”,“Light”,“Miniature Bulb”

Get related

instances

Getting nodes from relation table

getRelatedNode: node_name → ∩node

getRelatedinstances(“Turn on an Electricity”) → “Carbon

Copper1”,“Plastic3”,“Battery”,“Spring”

Get root node of

scheme

Getting root node of Component, Function, Quality or

Technology scheme

getRoot: node_name → node

getRoots(“Power Battery”) → “Flashlight”

Get node from

attribute

Getting nodes from inputted attribute and its value

getNode: {Attribute, Value} → ∩node

getNodeFromAttribute(“materialCost”, “5.0”) → “Plastic4”

Get properties of

node

Getting nodes attributes

getProperties: node_name → ∩node

getProperties(“Power Battery”) → {“rdfs:label”,“Power

Battery”}, {“subComposedOf”, “Battery”}, {“materialCost”,

“5.0”}, {“componentImportance”, “7”}

Get prefix Getting name space of node

getPrefix: node_name → prefix_name

getPrefix(“Plastic1”) → “null”

Get the number

of all nodes

Getting the number of total nodes

getNumOfNodes: node_name →

getNumOfNodes(“Power Battery”) → 27

Get the

differences

between nodes

Getting differences nodes by attributes

getParents: node_name → node

getDifferences(“Power Battery”, “Battery”) → {{“rdfs:label”,

“Battery”}, {“rdfs:label”,“Power Battery”}},

{{“materialCost”,“5.0”}, {“materialCost”,“0.0”}},…

11

Figure 4. Architecture of the Information Infrastructure

System Work Flow

The work flow of the querying system is shown in Figure 5. A client referring WSDL sends a request to the

Web service interface to ask the query using SOAP. The J2EE server receives the request and passes it to the

Session Bean after deserialization. The Session Bean converts the parameter to XPath and passes it to the query

engine. The query engine searches the instance data of the attribute or reference table, changed into a DOM tree,

12

and returns the result. Session Bean sends the result of the query engine back to the client through the Web service

interface serializing the message into a SOAP message.

Use of the OWL-QL engine is the same as the XPath engine. Conversion in a OWL-QL language is performed

for every interface. For example, if the getChildren interface, which acquires children of “Flashlight”, is called it

will be changed into the OWL-QL sentence “tkb:subComposedOf tkb:Flashlight ?x” by the Business Logic layer.

Order

Receive

Serialize

Deserialize

Deserialize

Serialize

Convert Parameter to XPath Language

Return

Ontology Querying

Instance Data

User Client Application

Web Service Logic Layer

Business Logic Layer

Client

Infrastructure Layer

Ontology Query Engine (DQL/XPath) Ontology

J2EE Server

Figure 5. System Work Flow

13

EVALUATION OF THE SYSTEM

Comparison of Application Examples

An existing agent (Figure 6) can fulfill the goal of scenario A to give queries to early version of ontology query

engine with conventional operations successfully. When this agent looks for the parent’s brothers of “Battery”

(Figure 7) using the early querying system, it has to perform additional processing in XML to produce the result.

As an additional remark, when the information infrastructure receives the query, the query engine parses the

whole XML document to seek “subComposedOf” to obtain the parents of “Battery”, without any semantic

meaning. The other operations to get another parent and its children would be carried out in same way.

Furthermore, if the server does not support these complex operations, the client must prepare them, which causes

an overload.

In the new feature of ontology querying, these operations are prepared using the higher ontology querying

language. The ontology querying methods can retrieve the requested node described above through the logical

operation of getting the parent of “Battery” and getting the brothers of the previous result. Figure 8 shows a

running example of our ontology query system. As another example, when the quality of “Battery” was changed,

we can reason the other components affected by this change by tracing parent, child, brothers or the other

components with logical connectives and set operations.

Experimental Performance Comparison

To investigate our new ontology query system’s practicability, we compared the response time with the earlier

query system. The experimental environment for the server and client was the same machine, because we wished

to check the query engine performance alone. We used a test set of 20 types of query and iterated 100 times.

The average time taken is approximately 270 ms by the existing system and 250 ms by the ontology querying

system. The processing time of the ontology querying system was somewhat shorter (approximately a 10%

decrease). This shows that our ontology query system can work in harmony with the existing query system.

14

Figure 6. Existing Application-Centric Agent

Other Ontology Query Systems

We can illustrate several basic ontology storages and querying systems according to query language and

implementation (Magkanaraki & Karvounarakis, 2002). Besides these general ontology querying systems, some

ontology querying formalizations and their implementation have been studied. OWL-QL gives strong ontology

querying formalization based on inference (Fikes et al., 2003). ONTOLOG system aimed formulating query using

ontology-based similarity measure to find more suitable information or additional information (Bulskov et al.,

2004). Finin et al. (2002) also have an ontology querying function, HOWLIR, which advocates search and

inference for precise retrieval using the semantic concept. It provides a framework that is able to extract and

exploit the semantic information of events in the university, perform sophisticated reasoning and filter results for

better precision. It infers the event data by ontology querying the request of a user. Our system is exploiting an

15

ontology querying system on product design support of SCM. Also, it gives fundamental server-side interfaces

(EJB) to query ontology based on inference and several logical operations.

Cover Light

Deserialize

Flashlight

Power Battery

Battery

Strap Connection Part

Figure 7. Component Cost Scheme Sample : Parent’s Brothers of “Battery”

Figure 8. Demonstration of Ontology Querying

16

CONCLUSION

Information infrastructure for product design support has contributed to optimizing SCM, which has greatly

improved the competitive power of a company. This system offers a framework that can integrate the four

attributes required for a product design. As this framework has achieved a shortening of the time for product

design and an improvement in reliability, a cost reduction is expected.

The early version of the querying system can reply to a first-order query–answer pair, such as a relational

database, although it has ontological data representation. This gives users or agents an overload in preparing

alternative procedures. To provide a more complete ontology query environment, we improved the early system to

include higher logical reasoning operations.

Two domains and five subcategories were classified, according to the behavior and characteristics of the

operator. Twelve operations are provided in the form of interface of server side components and Web services.

Using these ontology query systems, users or agents can gain several benefits.

1. Higher logical operations with several logical connectives and set operations in one interface call

2. Easier service composition of several services with semantics

3. A pathway to wrapping business logics and robust their server side components, such as EJB or CORBA,

with semantic Web service

This information infrastructure with the intelligent ontology querying system has been built under less practical

or industrial background. To be a more pragmatic system on a pragmatic semantic Web service, several

challenges remain, such as extracting existing Web applications into an ontological description of the service and

data on the semantic Web, adapting a more appropriate format for the new Web, coincident ontology flow from

primitive ontology data in the low level to Web service ontology in the higher level, as well as some other issues

(Heflin & Hunhs, 2003).

Future research to relate this system to real SCM solutions includes pragmatic modeling of supply chain graphs

for design attributes, granular security processes, and automatic mutual conversion between product design

attribute information and the existing SCM information. Further plans include building more rational agents to

support design through multi-agents that have improvements in autonomy, intelligence, mobility, and

collaboration, which are based on our ontology query system with a robust, rational foundation.

17

Figure 9. Experimental Results

REFERENCES

Akahani, J., Hiramatsu, K., & Kogure, K. (2003). Coordinating Heterogeneous Information Service based on

Approximate Ontology Translation. B. Burg, J. Dale, T. Finin, H. Nakashima, L. Padgham, C. Sierra, & S.

Willmott (Eds.), Agentcities: Challenges in Open Agent Environments, 25–31. Springer-Verlag.

Brown, A.W., Wallnau, K.C. (1998, September-October). The Current State of CBSE. IEEE Software, 37-46.

Bulskov, H., Rasmus Knappe, & Andreasen, T. (2004, June). On Querying Ontologies and Databases.

Proceedings of 6th International Conference on Flexible Query Answering Systems.

DQL Project for the Stanford Knowledge Systems Laboratory. Retrieved from ksl.stanford.edu/projects/dql/.

DAML Query Language. (2002, August). Retrieved from http://www.daml.org/2002/08/dql/.

18

Fikes, R., Hayes, P., & Horrocks, I. (2003). OWL-QL – A Language for Deductive Query Answering on the

Semantic Web, KSL Technical Report 03-14. Retrieved from http://ksl.stanford.edu/KSL_Abstracts/KSL-03-

14.html.

Finin, T., Joshi, A., Cost, R.S., Mayfield, J., & Shah, U. (2002, November). Information Retrieval on the

Semantic Web. Proceedings of ACM Conference on Information and Knowledge Management.

Gorton, I., Liu A. (2003, May-June). Evaluating the Performance of EJB Components. IEEE Internet

Computing, 7(3), 18-23.

Heflin, J., & Hunhs, M.N. (2003, September-October). The Zen of the Web. IEEE Internet Computing, 7(5),

30–33.

Jena Semantic Web Framework. Retrieved from http://jena.sourceforge.net/index.html.

JTP: An Object Oriented Modular Reasoning System. Retrieved from http://www.ksl.stanford.edu/software/JTP/.

Mandell, D.J., & McIlraith, S.A. (2003, May). Automating Web Service Discovery, Customization, and

Semantic Translation with a Semantic Discovery Service. Proceedings of the Twelfth International World Wide

Web Conference.

Magkanaraki, A., Karvounarakis, G. (2002, April). Ontology Storage and Querying, Technical Report No. 308,

Foundation for Research and Technology Hellas Institute of Computer science Information Systems Lab.

OWL Services Home Page. Retrieved from http://www.daml.org/services/.

Paik, I., & Park, W. (2005). Software Component Architecture for an Information Infrastructure to Support

Innovative Product Design in a Supply Chain. Journal of Organization Computing and Electronic Commerce ,

15(2), 105-136.

Paik, I., Akimoto, H., & Takami, S. (2004, May). Automating Design in Supply Chains on Semantic Web

Services. Proceedings of 14th WWW Conference, Semantic Web and Application Design Workshop. Retrieved

from CEUR-WS.org/Vol-105/.

19