Web Service-Oriented Model for E-Commerce

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

1

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
5029
Kunal Thakur
5036
Saras Joshi
5371

2

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

_______________________________ _______________________________

3

External Examiner Head of Department

________________________________
Principal

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

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.

4

TABLE OF CONTENTS

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

5

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 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.

6

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 which
Organization 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 business
Environment. 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:

7

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.

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.

8

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)

9

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
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

10

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 an
industrial world. But there are many divergences between industrial view and academical
view on component model. Large companies implement theirs component models directly
and pushes users to use as-is. On the other hand academic world is spending long time
on development and tenement of theirs component models, and rarely they implement it
and 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.

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.

11

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.
There is no single correct ontology for any domain. Ontology design is a creative
process and no two ontologies designed by different people would be the same. The potential
applications of the ontology and the designer’s understanding and view of the domain will
undoubtedly 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
application
Domains.

Without explicit
goal, does not
focus on
concrete
application
domains.

? Principles based on the conceptual
work done in WSMF.
Vague,
development

12

based set of tasks
to be
Solved.

? Discovery Web Services
(capability),goal.

Profile.
? Composition Orchestration +
choreography.

Process Model.

? Invocation Grounding+WSDL/SOA
P.

Grounding+WSDL/SOA
P.

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

13

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
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.*;

14

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.
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.

15

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 athttp://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.

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.

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).

4.Design:

4.1 Diagrams:

1)Use-Case Diagram:

17

2)Sequence Diagram:

18

3)Collabration Diagram:

19

4)Database(Ontology) Diagram:

20

5)GUI-Login Page:

21

6)GUI-Registration Page:

7)GUI-Payment Page:

22

5.Implementation:
5.1 Architecture:

23

? 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.

? 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

24

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
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.

25

? 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 functionality
Easily 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.
? 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.

26

? 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
? 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.

27

? 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.

? 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

28

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 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

29

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.
? 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.

30

? 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
? 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:

31

? Customer will open the web-site.
? Customer can register, login etc.
? 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:
Our Semantic web service-oriented web site will answer the following future requirements
like:

32

? Web compliance
? Ontology-based
? Strict decoupling
? Centrality of mediation
? Ontological role separation
? Description vs. implementation
? Execution semantics
? Service vs. Web service

7. Conclusion:
Web services provide a mechanism to connect applications regardless of the
underlying software/hardware platform and their location .Commercial organizations can thus

33

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 propose
an 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.

8.References:
[1] Mitra, N., ?SOAP Version 1.2 Part 0: Primer?, W3C

34

Recommendation,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 Description
Language (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 Web
Services: An Overview and Comparisons?, Lecture
Notes in Computer Science, Vol.3053, pp.225-239,
2004.
[5] Antoniou, G. and van Harmelen, F., ?A Semantic
Web Primer”, Cambridge, Ma: The MIT Press, 2004
[6] Passin, T. B., ?Explorer's Guide to the Semantic?
Web. Greenwich, CT: Manning Publications
Co. ,2004
[7] Singh, M. P. , ?Introduction to web semantics, The
Practical 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 Web
Service?,http://www.w3.org/Submission/OWL-S/,2003
[9] McGuinness, D., and Harmelen, F. D., ?Owl Web
Ontology Language Overview?,http://www.w3.org/TR/owl-features/,2004
[10] Lausen H.,Polleres A.,RomanD., ?Web Service
Modeling 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 for
Creating WSMO-based Semantic Web Services.?
Proceedings of the Workshop on WSMO
Implementations Frankfurt, Germany, September
29-30, 2004, CEUR Workshop Proceedings, ISSN
1613-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 Resea.

[15] Brickley, D. and Guha, R.V. 1999. RDF Schema Specification
(draft). W3C (World Wide Web Consortium). At

35
http://www.w3.org/TR/1999/PR-rdf-schema-19990303.html.
[16] Farquhar, A.; Fikes, R.; and Rice, J. 1997. Tools for
Assembling Modular Ontologies in Ontolingua. In Proceedings
of 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. In
AI 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 Knowledge
Bases: Towards a Terminological Clarification. In N. Mars (ed.)
Towards Very Large Knowledge Bases: Knowledge Building
and Knowledge Sharing, 25-32. Amsterdam: IOS Press.

doc_374075900.docx
 

Attachments

Back
Top