• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
INTRODUCTION
 

INTRODUCTION

on

  • 658 views

 

Statistics

Views

Total Views
658
Views on SlideShare
658
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    INTRODUCTION INTRODUCTION Document 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 : 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
    • 2 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,
    • 3 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 were developed. The following sections provide a detailed discussion of ontology querying software component.
    • 4 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/mm 2 to 10 cd/mm 2. 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 maintain services with complex functions at the higher level would be more complex and difficult. In the semantic
    • 5 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 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
    • 6 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). Component-Cost Function Quality Technology Table Table Table Table Root-C Root-F Root-Q Root-T Cover Light Power Battery Turn On Focusing Improve Power Miniature Light Injection Miniature Bulb: Appearance Contact Modeling Vacuum Pump Bulb Steel: Casting Filament: Vacuum Method Miniature Fix Plastic Cover & Switch Vacuum Light Luminous Power Plastic1 Bond1 Socket Plastic2 Bond2 Connection Turn Bulb Miniature Battery Storage Degree Value Flux Battery Switch Bulb Bundle degree Miniature of Light Bulb Bulb Raise Voltage Brightness Glass Operation Lens Trans- Reflec- Ball Filament Soldering Solvent1 Store Color Tone of Switch Position Size missivity tance Battery Steel: elegant Power of S/W Solvent2 Carbon Plastic2 Copper Light Size Light source Brightness Non-Terminal Instance Node SubComposedOf Relation Terminal Instance Node Inter Attributes Relation Root Node Figure 1. Structure of Product Attributes
    • 7 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 initiated from this ontology, and those data can be processed by the XML querying system or the ontology querying system. <<TransitiveProperty>> New- RelationScheme SupCompose Product <<inverseOf>> Product Existing- ComponentTechnologyScheme FunctionTechnologyScheme TechnologyQualityScheme ComponentFunctionScheme >> ComponentQualityScheme Product <<TransitiveProperty FunctionQualityScheme Described <<domain>> SubComposedOf Design-Attribute <<range>> Component- Function Quality Technology Cost RelationAttribute Sub Sub Sub Sub Component- Quality Technology DesignAttributeRelation Cost Function Component- Quality Technology Importance Attribute- Cost Function Levels Relationships Scheme Scheme Scheme Scheme Figure 2. Ontology For Design Attributes in UML
    • 8 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.
    • 9 <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> 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
    • 10 Domain Category Methods Vertical Logical Operator getParents, getChildren, Node getAlldescendant, getRoots Horizontal Logical Operator GetBrothers Tracing Characteristic Based Operator getNodeFromAttribute, getRelatedInstances Node Property Related Operator getProperties, getDifferences Informat-ion 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.
    • 11 User 12 Bean Manager Infrastructure Interfaces Bean Beans OWL-QL Java Theorem Interfaces Prover Ontology Query & Reasoning Information Infrastructure Application Server Product Attribute Ontology 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 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.
    • 12 Table 2. Operators of Ontology Querying Specification (node ∋ { ComponentCost, Quality, Method Example Function, Technology, Attribute } ) Get parents Getting parents of inputted node GetParents(“Cover”) → “Flashlight” getParents: node_name → ∩node Get children Getting children of inputted node getChildren(“Flashlight”) → “Cover”,“Light”,“Power GetChilds: node_name → ∩node Battery”,“Strap”,“Connection Part” Get all Getting descendants of inputted node getAllDescendants(“Light”) → “Miniature descendants getDescendants: node_name → ∩node Bulb”,“Socket”,“Glass Ball”,“Filament”,“Prop”, “Soldering”,“Carbon Copper1”,“Plastic3”,“Carbon Copper2”,“Solvent2” Get brothers Getting brothers of inputted node getBrothers(“Cover”) → “Light”,“Power getBrothers: node_name → ∩node Battery”,“Strap”,“Connection Part” Get the shortest Getting the shortest route between the nodes from the getRoute(“Power Battery”,“Miniature Bulb”) → “Power route between inputted two nodes Battery”,“Flashlight”,“Light”,“Miniature Bulb” nodes getRoute: node_name → ∩node Get related Getting nodes from relation table getRelatedinstances(“Turn on an Electricity”) → “Carbon instances getRelatedNode: node_name → ∩node Copper1”,“Plastic3”,“Battery”,“Spring” Get root node of Getting root node of Component, Function, Quality or getRoots(“Power Battery”) → “Flashlight” scheme Technology scheme getRoot: node_name → node Get node from Getting nodes from inputted attribute and its value getNodeFromAttribute(“materialCost”, “5.0”) → “Plastic4” attribute getNode: {Attribute, Value} → ∩node Get properties of Getting nodes attributes getProperties(“Power Battery”) → {“rdfs:label”,“Power node getProperties: node_name → ∩node Battery”}, {“subComposedOf”, “Battery”}, {“materialCost”, “5.0”}, {“componentImportance”, “7”} Get prefix Getting name space of node getPrefix(“Plastic1”) → “null” getPrefix: node_name → prefix_name Get the number Getting the number of total nodes getNumOfNodes(“Power Battery”) → 27 of all nodes getNumOfNodes: node_name → Get the Getting differences nodes by attributes getDifferences(“Power Battery”, “Battery”) → {{“rdfs:label”, differences getParents: node_name → node “Battery”}, {“rdfs:label”,“Power Battery”}}, between nodes {{“materialCost”,“5.0”}, {“materialCost”,“0.0”}},…
    • 13 Client’s Client Stationary Stationary Web Web Browser Service Agent Application Agent Application Web Service Composition in OWL-S Servlet Web Interface Web Service WSDL Mobile Agent / SOAP Stationary Agent for Mobile Agent AccessControl InformationGate Bean SessionBean AttributeInstance RelationTable AttributeTable Business SessionBean Beans EntityBeans Logic EJB Container Application Server Ontology Product Query Attribute Engine Instances Infrastructure (Ontology and Data) DataBase Product Attribute Ontology 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,
    • 14 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. Client J2EE Server User Client Web Service Business Infrastructure Application Logic Layer Logic Layer Layer Ontology Query Engine (DQL/XPath) Ontology Convert Order Serialize Deserialize Parameter to XPath Language Ontology Instance Querying Data Receive Deserialize Serialize Return Figure 5. System Work Flow
    • 15 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.
    • 16 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
    • 17 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. Flashlight Light Power Battery Strap Connection Part Cover Deserialize Battery Figure 7. Component Cost Scheme Sample : Parent’s Brothers of “Battery” Figure 8. Demonstration of Ontology Querying
    • 18 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.
    • 19 Experimental Result 300 000 200 500 Processing Time 200 000 Xp th a 15 0 0 00 O L-Q & JTP W L 10 0 0 00 500 00 0 0 0 0 0 0 00 10 20 50 20 10 30 50 75 10 No. of Iterations 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/.
    • 20 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/.