A Project Report on

Semantic Web Service-Oriented Model for E-Commerce

Under the guidance of

Prof. Swati Ringe

Submitted by

Name Roll No.Shazia Ali 5029Kunal Thakur 5036Saras Joshi 5371

1

Certificate

This is to certify that Miss. Shazia Ali, Mr. Kunal Thakur and Mr.Saras Joshi have completed their project report on ‘Semantic Web Service-Oriented Model For E-commerce’ satisfactorily in partial fulfillment under the department of ComputerEngineering during academic year 2010-2011.

_______________________________ _______________________________ Internal Guide InternalExaminer

_______________________________ _______________________________External Examiner Head of Department

________________________________Principal

Submission date : November --------- , 2010

2

Acknowledgement

We would like to express our sincere thanks and gratitude to our guide Mrs.Swati Ringe for her valuable guidance and suggestions. We are highly indebted to her for providing us an excellent opportunity to learn and present our studies in theform of this project report.

We take this opportunity to thank the members of the teaching and non-teaching staff of Fr.C.R.C.E.for the timely help extended by them.Lastly thanking our parents for their morale support andencouragement.

TABLE OF CONTENTS

3

Sr No. Contents Pg No.

1. Preface 5

2. Introduction 6

2.1 Abstract 6

2.2 Problem Definition 6

2.3 Scope of Project 6

3. Review Of Literature 7

3.1 Methods of implementing Ecommerce 9

3.2 Comparison of technologies 11

4. Design 16

4.1 Diagrams 16

5. Implementation 22

5.1 Architecture 22

5.2 Working 30

6. Future Scope 31

7. Conclusion 32

8. References 33

1. Preface:

E-commerce on the internet provides a high level of flexibility and openness, but it still has many drawbacks due to the heterogeneity of

4

the exchanged information. Web Services have added a new level of functionality on top of current Web, enabling the use and combination of distributed functional components within and across company boundaries, but they offer only syntactical description that are hardly amenable to automation. Developments in the field of Semantic Web Services (SWS) show the opportunity of adding higher semantic levels to the existing frameworks, to improve their usage and ease scalability. In this paper, we outline a Semantic Web e-commerce in which data sources and services are made available through SWS, described by ontologies, allowing interoperability as well as reasoning to create a comprehensive response adapted to user goals. We present a semantic web service oriented model for e-commerce, aiming to integrate the development of Semantic Web services using the OWL-S into JAVA framework,it can also be applied to e-government.

5

2. Introduction:

2.1 Abstract:

Semantic Web shows great potentials in the e-commerce. A key word searching in current online shopping is not only tedious and time-consuming but also often results in large amounts of irrelevant information. Current Web services offer only an inflexible interface with some human oriented metadata that describes what the service does, and whichOrganization developed it. Web Services are typically intended for applications consumption, in contrast with contemporary Web applications which are meant for human users. However, the lack of machine readable semantics is hampering their usage in complex businessEnvironment. Semantic Web Services (SWS) come along and provide a solution with rich formal descriptions of their capabilities, thus facilitating automated discovery, dynamic binding, and invocation of services within an open environment, which can be utilized by applications or other services without human assistance and immune to highly constrained agreements on interfaces or protocols. According to a semantic specification in ontology, a commercial infrastructure can be featured for a better communication between buyer and seller. The rest of the documentation provide a general overview of semantic web service-oriented model for e-commerce.

2.2 Problem Definition:

A SEMANTIC WEB-SERVICE-ORIENTED MODEL FOR ECOMMERCE

Create a E-commerce based website. (E-shop). Include web services in the E-commerce based website which provides a mechanism

To connect applications regardless of the underlying software/hardware platform and their location.

Commercial organizations can thus use web services technology to expose elements of their business processes.

OWL-S provides a framework for the description of Semantic Web Servicesthat enables seamless business integration through formal descriptions, maximal decoupling of components and strong mediation support.

6

2.3 Scope Of Project:

A complete E-commerce-based website will be developed based on Semantic Web Service-oriented model which will have following features:

Allow Customers to search Electronic devices of their choice(for ex: mobile phones,laptop,T.V, music players etc).

Allow Customers to make payment through credit and debit cards. Receive purchased product within 1 month of the purchased date. Allow customers to make comparison of various products before

buying. Sending Receipt through an e-mail to customer. Generating monthly payment reports. Customer management. Products Management.

7

3. Review of Literature:

Ecommerce

The Internet and other new technologies (e.g. agent systems, mobile computing etc.) have created a number of interesting and innovative ways to deliver value to the customer while increasing the income potential of the merchant.The Web, as a place for e-commerce, brings both advantages and challenges. While e-commerce has the same goal as any other form of commerce, to maximize the amount of sold commodities and thus the generated income, it differs from it in many respects. (1)While the conventional stores carry only a limited supply of (typically most popular) items, e-shops can offer an almost unlimited number of items, including specialty products targeted for only relatively few customers. In particular, agglomerations of e-merchants (e.g. www.totu.pl, www.amazon.com), acting as intermediaries between sellers and customers generate a very large commodity search space (e.g. [MABA00], [VALE01]). This allows customers to comparison-shop and select their favorite brand without leaving their chairs. (2) By the same token, traditional store can reach mainly customers who live in the neighborhood, whereas the e-store makes it possible to pursue global sales. In addition, keeping a physical store open 24 hours a day is rather expensive (with nightly operation generating only minimal income), while the computer system supporting e-commerce can run non-stop with almost no overhead. These features generate a potential advantage for the e-merchants. (3) while the traditional commerce is limited by time and space, the Internet commerce is characterized by an almost unlimited availability. (4) An additional benefit of e-commerce is that it allows the seller a natural opportunity to gather information about the behavioral patterns of visiting customers (including their transaction records). There is a number of ways that such an information can be applied: (a) to better meet individual customer expectations (resulting in the increased number of transactions and thus in increased profits), (b) to study the behavior of the entire client population (mining knowledge that can be then fed-back to the e-commerce support systems), (c) to study the current market trends (e.g. to assure that fashionable commodities are available to the clients), (d) to exchange information with (to sell it to) other businesses1 (as a source of additional information applicable in own system and/or source of additional income). The e-commerce system brings also about some challenges. (5) While it is relatively easy to gather information, its amount may lead to an information overload2. It is only “processed” information that can be useful to the user (merchant). (6) When considering the case of an e-store, we notice a small paradox, which needs to be appropriately addressed. On the one hand, it is easy to provide the potential customer with more information about product(s) and service(s) that we try to sell (and large amount of such information is also available in a multitude of additional, Internet based, repositories). On the other hand, e-stores have to convince the customer to shop without the support of a human (and without a physical contact with the merchandise)3. Therefore, it is important to develop an environment such that when buyers make their purchasing decisions, they can feel like being in a traditional small store. In response to these opportunities and challenges, the development of successful e-commerce initiatives requires creation of an appropriate infrastructure that will support the required functionality. Such an infrastructure has to play two major roles. On one hand, it should help the customer to purchase goods in the time frame in the way that he/she is inclined to do it. On the other hand, it should help the merchant to maximize the total number of purchases completed by her e-business, thus increasing her income. This infrastructure should provide

8

assistance by dealing with the vastness of the search space and offering recommendations based on the knowledge of individual customers acquired, among others, through analysis of their earlier/other purchases . We have 2 goals here. First, to present an overall infrastructure of an e-commerce endeavor. Second, to discuss the required functionalities to satisfy the client and support the merchant. While pursuing this goal, we have to make it clear, that we are approaching this problem form the merchants’ perspective (the ultimate goal of the system being profit maximization). Here, the maximization of profits is achieved through the satisfaction of clients needs, and in this way increasing the likelihood of client’ purchasing goods. The e-commerce system can be described in a number of ways. We have decided to proceed with the functional decomposition first, as it gives us a natural way of presenting the highest level of abstraction of the system design. At this level of detail we have combined some more specific functions into joint units, which will have to be concretized during the system development process. The summary of the system functional decomposition is presented in Figure (all of the references in the form “block n” below refer to this figure). We will proceed first, to describe the customer part of the system and follow with the description of the sales-and-supply-related functionalities. Finally, in the next section, we discuss the e-commerce infrastructure necessary to support it. E-COMMERCE SYSTEM Customer System (CS) Supply System (SS) WEB communication channel environment. When the customer is ready to complete a transaction, the transaction module will process her order and when the interaction with the system is completed (regardless if transactions took place or not), information of the session is sent to the cleaner agent, which prepares the data to be stored in the customer database. At the same time, the transaction information is sent to the commodity database. Both these databases store the “current” data about commodities, transactions and customer behavior. This data is analyzed and the results are sent to the supply module, as well as the expert system responsible for the sale strategy generation. As the data in the customer and commodity databases becomes old, it is then send to the data warehouse where it is further analyzed in search for long-term trends and rules for the expert systems. Results from mining of the data warehouse are then sent to the supply module, where they are combined with the market scouting reports and participate in supply chain management and business partner selection. Finally, the system-manager exchange module is responsible for the interactions between the managers and the system.

Methods used to Implement Ecommerce.

EContemporary component model development is getting more and more important in anindustrial world. But there are many divergences between industrial view and academicalview on component model. Large companies implement theirs component models directlyand pushes users to use as-is. On the other hand academic world is spending long timeon development and tenement of theirs component models, and rarely they implement itand with pure support and development environment.

We use a component and architectural model of the EJB .A key idea is to introduce Enterprise Object Adapter (EOA), that control lifecycle and service employment of the component types. This approach is seamlessly incorporated into current EJB specification with respect to backward compatibility and functionality. Thismodel will be tuned and implemented as a part of project.

9

Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications .The EJB specification is one of several Java APIs in the Java EE specification. EJB is a server-side model that encapsulates the business logic of an application. The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0) and JSR 318 (EJB 3.1).

The EJB specification intends to provide a standard way to implement the back-end 'business' code typically found in enterprise applications (as opposed to 'front-end' interface code). Such code was frequently found to address the same types of problems, and it was found that solutions to these problems are often repeatedly re-implemented by programmers. Enterprise JavaBeans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.

Accordingly, the EJB specification details how an application server provides:

Transaction processing Integration with the Persistence services offered by the Java Persistence API (JPA) Concurrency control Events using Java Message Service Naming and directory services (JNDI) Security (Java Cryptography Extension (JCE) and JAAS) Deployment of software components in an application server Remote procedure calls using RMI-IIOP. Exposing business methods as Web Services.

Additionally, the Enterprise JavaBean specification defines the roles played by the EJB container and the EJBs as well as how to deploy the EJBs in a container. Note that the current EJB specification does not detail anymore how an application server provides persistence (a task delegated to the JPA specification), but instead details how business logic can easily integrate with the persistence services offered by the application server.

An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions of basic concepts in the domain and relations among them. We use ontologies because

To share common understanding of the structure of information among people or software agents To enable reuse of domain knowledge To make domain assumptions explicit To separate domain knowledge from the operational knowledge To analyze domain knowledge

In practical terms, developing an ontology includes: defining classes in the ontology, arranging the classes in a taxonomic (subclass–superclass) hierarchy, defining slots and describing allowed values for these slots, filling in the values for slots for instances.

We can then create a knowledge base by defining individual instances of these classes filling in specific slot value information and additional slot restrictions.

10

There is no single correct ontology for any domain. Ontology design is a creativeprocess and no two ontologies designed by different people would be the same. The potentialapplications of the ontology and the designer’s understanding and view of the domain willundoubtedly affect ontology design choices. “The proof is in the pudding”—we can assess the quality of our ontology only by using it in applications for which we designed it.Inconsistency and incompleteness are important problems that affect the Semantic Web therefore ontology mapping systems that operate in this environment should have the appropriate mechanisms to cope with these issues. Mapping ontologies with high precision on the Semantic Web is a challenging problem that needs to be addressed in various domains.One of the main problems with any mapping process, which needs to be applied on different domains is that it always has a certain degree of uncertainty associated with it. In this paper we introduce a method based on Dempster-Shafer theory that use uncertain reasoning over the possible mappings in order to select the best possible mapping without using any heuristic or domain specific rules.

OWLS V/S WSMO:

Features WSMO OWL-S Goals Actual goal, specific

applicationDomains.

Without explicit goal, does not focus onconcrete application domains.

Principles based on the conceptual work done in WSMF.

Vague, development based set of tasks to beSolved.

Discovery Web Services (capability),goal.

Profile.

Composition Orchestration + choreography.

Process Model.

Invocation Grounding+WSDL/SOAP.

Grounding+WSDL/SOAP.

11

WSDL:

Introduction: the need for adding semantics to WSDL

Web services have primarily been designed for providing inter-operability between business applications. Current technologies assume a large amount of human interaction, for integrating two applications. This is primarily due to the fact that business process integration requires understanding of data and functions of the involved entities. Semantic Web technologies, powered by description logic based languages like OWL[1], aim to add greater meaning to Web content, by annotating the data with ontologies. Ontologies provide a mechanism of providing shared conceptualizations of domains. This allows agents to get an understanding of users’ Web content and greatly reduces human interaction for meaningful Web searches. A similar approach can be used for adding greater meaning to Web service descriptions, which will in turn, allow greater automation, by reducing human involvement for understanding the data and functions of the services, Several standards have been proposed for creating semantic Web services. Primarily, OWL-S[2][8], WSMO[3] and METEOR-S [4] have proposed various solutions for creating for expressive descriptions for Web services. In this draft, we present WSDL-S, a lightweight approach for adding semantics to Web services. This draft is based on the ongoing METEOR-S project, LSDIS Lab, University of Georgia, which aims to add semantics to the complete lifecycle of Web processes. Section 2 outlines WSDL and how semantics can further enhance it. Section 3 discusses on adding semantics to web services. Section 4 describes the WSDL-S Meta-Model while Section 5 explains a step-by-step approach of adding semantics. Appendices provide further details and corroborating information. Appendix I shows an example WSDL-S file while an example of corresponding annotated source code is provided in Appendix II. Appendix III details the interim step between WSDL and WSDL-S. Appendix IV lists the tools that are being built under METEOR-S to support WSDL-S while Appendix V shows the WSDL-S support in METEOR-S. 2. WSDL

The WSDL specification began with WSDL 1.0 in 2000. This was quickly followed by WSDL 1.1[5] which has been used in many Web service tools. A effort to enhance it, WSDL 1.2, has been renamed WSDL 2.0[6], as it includes some major changes. Draft releases of the WSDL 2.0 standard have been available since March of 2004 and are expected to become W3C recommendation in 2005. A central purpose of WSDL is to describe interfaces (formerly known as port-types) to Web services. Actual Web services may then be viewed as remote implementations of these of interfaces. In general, service providers/implementers could use a standard interface, extend a standard interface or develop there own. Broadly speaking, an interface contains a set of operations. Each operation has a signature which includes an operation name, input, output and exception messages. These messages

12

have types that are defined using some XML-based schema language. The schema language that is commonly used is XSD[7], although OWL is an alternative. In WSDL 2.0, types are pushed more completely outside the standard. This makes sense on the onehand, since types systems are complex to define and there exist at least two well-accepted type systems in the XML world: XSD and OWL. On the other, this makes it difficult for WSDL interfaces to be first-class citizens (i.e., types) which they would be under an object-oriented approach.

A client of a Web service will look to the interface to find out what it will do. Indeed, interface descriptions may be used to find candidate Web services. Such descriptions are therefore critical to proper discovery and use of Web services. Hence, adding semantics to interfaces is very important. To illustrate this idea, more semantics is added to Web service interface in a step by step fashion. Note, the examples are based on Java source for brevity. 1. Minimal semantics. interface Interface1WS { String operation1 (String param); String operation2 (String param); } // Interface1WS 2. Use meaningful argument names and more specific types. interface BookWS { double getPrice (String isbn, String title, int year) boolean buy (String ISBN); } // BookWS 3. Require types to be from (or extend) standard libraries. Upcast to existing types is automatic, while one must supply a method for downcast. For language independence, these types need to be standardized for an XML based schema language, such as XSD or OWL. Conversion from one type system (XSD, OWL and Java) to another is currently an open problem. import BookTypes.*; interface BookWS { double getPrice (BookID isbn, BookTitle title, Date year) boolean buy (BookID ISBN); } //BookWS 4. Add Design-By-Contract (nominally pre and post conditions) import BookTypes.*; interface BookWS { @post (return > 0.0);

double getPrice (BookID isbn, BookTitle title, Date year); @pre (isbn != null); boolean buy (BookID isbn); } //BookWS 3. Adding Semantics to Web services

The OWL-S (formerly DAML-S) project defines an ontology for the domain of Web services. This ontology provides tags which can be used for describing actual Web services.

13

The ontology consists of three sub ontologies, service profile, service grounding and the process model, which are tied together using a service ontology. The service profile defines the functional and non-functional properties of the services. Service grounding contains information about invocation. In an effort to align with industry standards, service grounding provides mapping OWL atomic processes to WSDL operations. The process model describes the ordering of the operations of the service. Due to the late alignment of OWL-S to WSDL, the design of OWL-S may be unnecessary complex. WSDL-S aims to provide a lightweight approach for creating semantic Web service descriptions. We call our approach lightweight because:

• We provide simple extensions to WSDL to add semantics, thereby allowing semantic descriptions of Web services.

• We have designed the WSDL-S service ontology, which is more aligned with WSDL 2.0 and more compact than OWL-S, without losing significant expressivity. In particular, we were not convinced on separating the service grounding from the service profile. An important feature of our approach is that we automatically populate our ontology from WSDL 2.0 descriptions. We view our ontology as an intermediate entity and plan to shield the users from interacting with it.

• Our approach allows integration of semantic and non semantic descriptions of Web services, as users using special types must specify translation to OWL

4. WSDL-S Meta – Model

In this section, we present a meta-model for WSDL 2.0. Our extensions have been shown in red and green. In near future, we will present further refinements to this meta–model and an approach to represent the process model. The tags in red are our proposed extensions. We explain them in detail in the next section. WSDL 2.0 draft already discusses using different type systems for Web services. We have shown OWL and XMI as possible type systems, along with XSD in the meta-model. Since WSDL 2.0 partially supports this, we have shown them in green. We are still investigating efficient ways for transforming from one type system to the other.

5. Adding Semantics: Step – by – step

In this section, we will explain our approach of adding semantics to WSDL 2.0.

5.1. Referencing Ontologies in WSDL-S

We present examples using an ontology based on the Rosetta net PIP directory. An initial draft on the ontology is available at http://webster.cs.uga.edu/~azami/pips.owl. We use the namespace feature of WSDL to reference classes and properties from this ontology. Below, we show an example of creating the namespace “rosetta” for the Rosetta Net ontology.

<definitions

.

.

xmlns:rosetta = http://webster.cs.uga.edu/~azami/pips.owl# …… />

14

5.2. Adding semantics to operations

In WSDL 2.0, each interface consists of a number of operations. Each operation can be seen as a unit of functionality of the service. It is imperative to capture the functionality of the each operation. In order to illustrate our extensions, let us consider an operation which allows users to cancel an order. WSDL 2.0 fragment for this particular operation is shown below.

<operation name = "checkStatus" pattern="mep:in-out" >

<action element = "rosetta:QueryOrderStatus” />

<input messageLabel = ”statusQuery” element = "xsd:PurchaseOrderStatusQuery" />

<output messageLabel = ”status” element = "xsd:PurchaseOrderStatusResponse" />

</operation>

In this section, we show the corresponding WSDL-S representation for the above fragment. A complete WSDL-S interface is shown in Appendix I. We have used extensibility of WSDL 2.0 to add two child (shown in red) tags to the “operation” tag. They are:

1. “Action” tag depicts the action the operation performs. This operation which allows a client to cancel an order, is depicted using PIP 3A9 Request Purchase Order Cancellation. We use the action tag to point to the corresponding class in the Rosetta Net ontology.

2. “Constraint” tag is used to depict pre and post conditions. In this case the confirmation number must be greater than zero for the operation to be executed. So it is depicted using the pre tag.

<operation name = "checkStatus" pattern="mep:in-out" >

<action element = "rosetta:QueryOrderStatus” />

<input messageLabel = ”statusQuery” element = "rosetta:PurchaseOrderStatusQuery" />

<output messageLabel = ”status” element = "rosetta:PurchaseOrderStatusResponse" />

<pre condition=”PurchaseOrderStatusQuery.orderStatusDoc.?PurchaseOrder !=null” />

</operation>

In addition, we depict the inputs and outputs using OWL types (shown in bold) from the Rosetta Net ontology instead on XML schema types (XSD).

15

4.Design:

4.1 Diagrams:

1)Use-Case Diagram:

16

2)Sequence Diagram:

17

3)Collabration Diagram:

18

4)Database(Ontology) Diagram:

19

5)GUI-Login Page:

6)GUI-Registration Page:

20

7)GUI-Payment Page:

21

5.Implementation:

5.1 Architecture:

E-commerce Website: Electronic Virtual Shop Platform for website: JAVA(jsp,servlets) Server: GlassFish 3 Platform for web services: Java Other platforms: EJB, Ontology, jena framework, glassfish.

E-shop web site consists of electronic devices like Mobiles,Laptops,T.V, Music Players etc.

Customer can shop any device of his choice. 5 web services will be created for ex:

1. searching.2. payment.3. comparison of devices etc.

All the java web services will be created in wsdl. All the created wsdl web services will be registered to

juddi.

22

Javascript:

JavaScript is an implementation of the ECMAScript language standard and is typically used to enable programmatic access to computational objects within a host environment. It can be characterized as a prototype-based object-oriented scripting language that is dynamic, weakly typed and has first-class functions. It is also considered a functional programming language like Scheme and OCaml because it has closures and supports higher-order functions.

JavaScript is primarily used in the form of client-side JavaScript, implemented as part of a web browser in order to provide enhanced user interfaces and dynamic websites. However, its use in applications outside web pages is also significant.

JavaScript uses syntax influenced by that of C. JavaScript copies many names and naming conventions from Java, but the two languages are otherwise unrelated and have very different semantics. The key design principles within JavaScript are taken from the Self and Scheme programming languages.

Servlets:

A Servlet is a Java class in Java EE that conforms to the Java Servlet API, a protocol by which a Java class may respond to HTTP requests. Thus, a software developer may use a servlet to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as CGI and ASP.NET. Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL rewriting.

The servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.

A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application.

Servlets can be generated automatically from JavaServer Pages (JSP) by the JavaServer Pages compiler. The difference between Servlets and JSP is that Servlets typically embed HTML inside Java code, while JSPs embed Java code in HTML. While the direct usage of Servlets to generate HTML (as shown in the example below) is relatively rare nowadays, the

23

higher level MVC web framework in Java EE (JSF) still explicitly uses the Servlet technology for the low level request/response handling via the FacesServlet. A somewhat older usage is to use servlets in conjunction with JSPs in a pattern called "Model 2", which is a flavour of the model-view-controller pattern.

Why JSP?

JSP pages perform with no issues on any platform .

They can be accessed from any web server.

JSP technology emphasizes on reusing the components that helps to develop more purposeful page designs.

The features portability, reusability and logic components of java language can be utilized across platforms.

Memory management and exception management is optimized.

Provide a large range of API to increase the result oriented functionalityEasily deployable and performance is robust on multiple requests.

Why Java?

Write Once, Run Anywhere Security Network-centric Programming Dynamic, Extensible Programs Internationalization Performance Programmer Efficiency and Time-to-Market

What is an Ontology?

An ontology is a specification of a conceptualization that is designed for reuse across multiple applications and implementations. …a specification of a conceptualization is a written, formal description of a set of concepts and relationships in a domain of interest.

An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions of basic concepts in the domain and relations among them.

24

In practical terms, developing an ontology includes:

defining classes in the ontology,

arranging the classes in a taxonomic (subclass–superclass) hierarchy,

defining slots and describing allowed values for these slots,

filling in the values for slots for instances.

Why we want to develop an ontology?

To share common understanding of the structure of information among people or software agents.

To enable reuse of domain knowledge.

To make domain assumptions explicit.

To separate domain knowledge from the operational knowledge.

To analyze domain knowledge.

Packages to be used for Implementation:

Jena-2.5.6

ARQ-2.8.5

Owl-s-1.1.0-beta

Pellet-1.3

Jena Framework:

Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine.

Jena is open source and grown out of work with the HP Labs Semantic Web Programme.

The Jena Framework includes: A RDF API Reading and writing RDF in RDF/XML, N3 and N-Triples An OWL API In-memory and persistent storage

25

SPARQL query engine.

ARQ:

ARQ is a query engine for Jena that supports the SPARQL RDF Query language. SPARQL is the query language developed by the W3C RDF Data Access Working Group.

ARQ Features: Standard SPARQL Free text search via Lucene SPARQL/Update Access and extension of the SPARQL algebra Support for custom filter functions Property functions for custom processing of semantic relationships Aggregation, GROUP BY and assignment as SPARQL extensions Support for federated query Support for extension to other storage systems Client-support for remote access to any SPARQL endpoint

OWL-S:

OWL-S is an ontology built on top of Web Ontology Language (OWL) by the DARPA DAML program. It replaces the former DAML-S ontology. "OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Semantic Web Services. It will enable users and software agents to automatically discover, invoke, compose, and monitor Web resources offering services, under specified constraints.

Development of OWL-S aims to enable the following tasks: Automatic Web service discovery: with the development of the

Semantic Web, many Web Services will be available on the Web, performing the most various tasks. OWL-S will help software agents to discover the Web Service that would fulfill a specific need within some quality constraints, without the need for human intervention.

Automatic Web service invocation: it is necessary to write a specific program to invoke a Web Service, using its WSDL description. OWL-S will open the possibility for a software agent to automatically read the description of the Web Service's inputs and outputs and invoke the service.

26

Pellet Reasoner:

Pellet is an open-source Java based OWL DL reasoner. It can be used in conjunction with both Jena and OWL API libraries and also provides a DIG interface.Pellet API which provides functionalities to see the species validation, check consistency of ontologies, classify the taxonomy, check entailments and answer a subset of RDQL queries (known as ABox queries in DL terminology).

Pellet is an OWL DL reasoner based on the tableaux algorithms developed for expressive Description Logics. It  supports the full expressivity OWL DL including reasoning about nominals (enumerated classes). Therefore, OWL constructs owl:oneOf and owl:hasValue can be used freely. Currently, Pellet is the first and only sound and complete DL reasoner that can handle this expressivity. Pellet ensures soundness and completeness by incorporating the recently developed decision procedure for SHOIQ (the expressivity of OWL-DL plus qualified cardinality restrictions in DL terminology).

Ontology analysis and repair OWL has two major dialects, OWL DL and OWL Full, with OWL DL being a subset of OWL Full. All OWL knowledge bases are encoded as RDF/XML graphs. OWL DL imposes a number of restrictions on RDF graphs, some of which are substantial (e.g., that the set of class names and individual names be disjoint) and some less so (that every item have a rdf:type triple). Ensuring that an RDF/XML document meets all the restrictions is a relatively difficult task for authors, and many existing OWL documents are nominally OWL Full, even though their authors intend for them to be OWL DL. Pellet incorporates a number of heuristics to detect "DLizable" OWL Full documents "repair" them.  Species Validation Here is a write-up by one of the Pellet programmers that explains how we process an OWL file for species validation.

Entailment In Semantic Web, entailment is the key inference whereas the Description Logic community have focused on satisfiability and subsumption. While entailment can be reduced to satisfiability, most DL systems do not support it. In part to pass a large portion of the OWL test suite, we implemented entailment support in Pellet.

Conjunctive ABox query Query answering is yet another important feature for Semantic Web. We have implemented an ABox query answering module in Pellet using "rolling-up'' technique. We

27

have devised algorithms to optimize the query answering by changing how likely candidates for variables are found and tried. Exploiting the dependencies between different variable bindings helps us to reduce the total number of satisfiability tests thus speeding up the answer significantly.

Datatype Reasoning XML Schema has a rich set of basic datatypes including various numeric types (integers and floats), strings, and date/time types. It also has several mechanism, both standard and unusual for creating new types out of the base types. For example, it's possible to define a datatype by restricting the integers to the set of integers whose canonical representation has only 10 digits, or whose string representation matches a certain regular expression. Currently, XML Schema systems tend toward validation of documents and generation of PSVI instead of type checking (though, with the advent of XQuery, this might change). Pellet can test the satisfiability of conjunctions of thus constructed datatypes.

User-defined Simple Datatypes The main problem of having user-defined datatypes is how to define URI's for XML Schema definitions. SWBPD working group at W3C discusses the problem and several different solutions in detail. In Pellet, we adopt the DAML+OIL solution which says a datatype URI is constructed from the URI of the XML schema document and the local name of the simple type. We parse the XML schema document from the given URI and locate the type using name attribute of the definitions.  Example ontology that refers to the datatype descriptions in the XML schema document.

Multi-Ontology Reasoning using E-Connections An E-Connection is a knowledge representation language defined as a combination of other logical formalisms. We use E-Connections as a language for defining and instantiating combinations of OWL-DL ontologies, i.e. as a way of combining KBs, rather than logics. This approach provide an alternative to owl:imports will always bring all the axioms from the imported ontology, lets us to identify sub-parts of an ontology and gives a well-founded logical framework for reasoning with multiple ontologies.Pellet provides support for reasoning with E-connected ontologies through both Jena and OWL-API interfaces.

28

Ontology Debugging Detection of unsatisfiable concepts in an ontology is a straright-forward task. However, the diagnosis and resolution of the bug is generally not supported at all. For example, no explanation is given as to why the error occurs (e.g., by pinpointing the root clash, or axioms in the ontology responsible for the clash) or how dependencies between classes cause the error to propagate (i.e., by distinguishing root  from derived unsatisfiable classes). Pellet, provides support for both kinds of tasks by pinpointing axioms that cause an inconsistency and the relation between unsatisfiable concepts.

Softwares to be used for Implementation:

Netbeans 6.9.1

Protégé 4.0.2

Graphviz 2.26.3

Netbeans:

NetBeans refers to both a platform framework for Java desktop applications, and an integrated development environment (IDE) for developing with Java, JavaScript, PHP, Python, Ruby, Groovy, C, C++, and others.

The NetBeans IDE is written in Java and runs everywhere where a JVM is installed, including Windows, Mac OS, Linux, and Solaris. A JDK is required for Java development functionality, but is not required for development in other programming languages.

The NetBeans Platform allows applications to be developed from a set of modular software components called modules. Applications based on the NetBeans platform (including the NetBeans IDE) can be extended by third party developers.

Benefits of Netbeans:

Extensible and easy modular design

29

Vast API of commonly used tasks Easy to design Swing GUI using Netbeans IDE Pre-defined update center and automatic update notification

Protégé:

Protégé is a free, open source ontology editor and knowledge-base framework.The Protégé platform supports two main ways of modeling ontologies via the Protégé-Frames and Protégé-OWL editors. Protégé ontologies can be exported into a variety of formats including RDF(S), OWL, and XML Schema.

Protégé is based on Java, is extensible, and provides a plug-and-play environment that makes it a flexible base for rapid prototyping and application development.

One of the most well known advantages of Protégé is its plug-ability.

Graphviz:

Graphviz (short for Graph Visualization Software) is a package of open source tools initiated by AT&T Research Labs for drawing graphs specified in DOT language scripts. It also provides libraries for software applications to use the tools.

Graphviz consists of a graph description language named the DOT language and a set of tools that can generate and/or process DOT files:

dot  a command-line tool to lay out directed graphs into a variety of output formats (PostScript, PDF, SVG, annotated text and so on). neato  for "spring model" layout (in Mac OS version called "energy minimised") twopi  for radial graph layouts. circo  for circular graph layouts. fdp  another layout engine for undirected graphs. dotty  a graphical user interface to visualize and edit graphs. lefty  a programmable (in a language inspired by EZ) widget that displays DOT graphs and allows the user to perform actions on them with the mouse. Lefty can therefore be used as the view in a model-view-controller GUI application that uses graphs.

Working Of the Project:

Customer will open the web-site. Customer can register, login etc.

30

If customer decides to search, compare etc then respective web services will be called.

Java agent will search related information in the ontology.

After retrieving information from ontology, java agent will called requested web service from the java web services created in WSDL.

Get the results in Java agent. Display the results received by java agent in terms of

GUI/JSP page.

6. Future Scope:

31

Our Semantic web service-oriented web site will answer the following future requirements like:

Web compliance

Ontology-based

Strict decoupling

Centrality of mediation

Ontological role separation

Description vs. implementation

Execution semantics

Service vs. Web service

7. Conclusion:

32

Web services provide a mechanism to connect applications regardless of the underlying software/hardware platform and their location .Commercial organizations can thus use web services technology to expose elements of their business processes. Semantic Web Services enable the formal specification of services, allowing their automated, goal-driven, location and usage. OWL-S provides a framework for the description of Semantic Web Services that enables seamless business integration through formal descriptions, maximal decoupling of components and strong mediation support. In this work, we proposean e-commerce model and make an attempt to integrate the development of Semantic Web services using the OWL-S into Java framework. This model can also betaken into e-government consideration.

33

8.References:

[1] Mitra, N., “SOAP Version 1.2 Part 0: Primer”, W3CRecommendation,http://www.w3.org/TR/soap12-part0/, 2003[2] UDDI Consortium, “UDDI Specification”,http://www.uddi.org/specification.html, 2000[3] Christensen, E., Curbera, F., Meredith, G.,Weerawarana, S., “Web Services DescriptionLanguage (WSDL) 1.1”, W3C Note 15 March 2001,http://www.w3.org/TR/2001/NOTE-wsdl-20010315[4] Cabral L., Domingue J., Motta E., Payne T.,Hakimpour F., “Approaches to Semantic WebServices: An Overview and Comparisons”, LectureNotes in Computer Science, Vol.3053, pp.225-239,2004.[5] Antoniou, G. and van Harmelen, F., “A SemanticWeb Primer”, Cambridge, Ma: The MIT Press, 2004[6] Passin, T. B., “Explorer's Guide to the Semantic”Web. Greenwich, CT: Manning PublicationsCo. ,2004[7] Singh, M. P. , “Introduction to web semantics, ThePractical Handbook of Internet Computing”,pp29-1-29-13, Chapman & Hall/CRC2005, 2005[8] Martin, D., Burstein, M., Hobbs, J., Lassila, O.,McDermott, McIlraith, S., Narayanan, S., Paolucci,P.,Parsia,B.,Payne,T.,Sirin,E.,Srin ,E.,Sirnivasan,N.,Sycara,K., “OWL-S Semantic Markup for WebService”, http://www.w3.org/Submission/OWL-S/,2003[9] McGuinness, D., and Harmelen, F. D., “Owl WebOntology Language Overview”,http://www.w3.org/TR/owl-features/,2004[10] Lausen H.,Polleres A.,RomanD., “Web ServiceModeling Ontology(WSMO)”Http://www.w3.org/Submission/WSMO/,2005[11] Domingue, J.; Cabral, L.; Hakimpour, F.; Sell D.;Motta, E., “IRS III: A Platform and Infrastructure forCreating WSMO-based Semantic Web Services.”Proceedings of the Workshop on WSMOImplementations Frankfurt, Germany, September29-30, 2004, CEUR Workshop Proceedings, ISSN1613-0073..

[12]Sun Microsystems \JavaBeans" http://java.sun.com/beans[13] Sun Microsystems \Java Messaging System" http://java.sun.com/jms[14] G. Kiszales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.M. Loing, J. Irwin, \Aspect-Oriented Programming", Xerox Palo Alto Res ea.

34

[15] Brickley, D. and Guha, R.V. 1999. RDF Schema Specification(draft). W3C (World Wide Web Consortium). Athttp://www.w3.org/TR/1999/PR-rdf-schema-19990303.html.[16] Farquhar, A.; Fikes, R.; and Rice, J. 1997. Tools forAssembling Modular Ontologies in Ontolingua. In Proceedingsof the Fourteenth National Conference on Artificial Intelligence(AAAI-97), 436-441. Menlo Park, CA: AAAI Press.[17] Fensel, D.; Decker, S.; Erdmann, M.; and Studer, R. 1998.Ontobroker: How to enable intelligent access to the WWW. InAI and Information Integration, Technical Report WS-98-14,36-42. Menlo Park, CA: AAAI Press.[18] Foo, N. 1995. Ontology Revision. In Conceptual Structures;Third International Conference, 16-31. Berlin: Springer-Verlag.[19] Guarino, N. and Giaretta, P. 1995. Ontologies and KnowledgeBases: Towards a Terminological Clarification. In N. Mars (ed.)Towards Very Large Knowledge Bases: Knowledge Buildingand Knowledge Sharing, 25-32. Amsterdam: IOS Press.

35