introduction
TRANSCRIPT
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 : [email protected]
Hiroyuki Akimoto- Address : University of Aizu, Computer Science and Engineering, Tsuruga, Ikki-machi, Aizu-
Wakamatsu City, Fukushima, 965-8580, Japan- e-Mail : [email protected]
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