Вы находитесь на странице: 1из 25


This is the Architectural Design Document of the project,
‘Personalized Semantic Web service for Classifieds’ (PSWSC). In Group
this document we briefly described the layering strategies used
and justifications, proposed technologies and their relevant No:15
proof of concepts.

Table of contents,
1. Introduction

1.1 Aim

1.2 People

1.3 System overview

1.3.1 Project outline

1.3.2 Project purpose

2. Architectural Goals and Constraints

2.1 The Incremental lifecycle model

2.2 List of the builds

3 Architectural Builds

3.1Implementing the ontology tree

3.1.1 Goals of Build 1

3.1.2 Ontology Tree

3.1.3 Protégé Description Logic Reasoners

3.1.4 OWL

3.1.5 Ontology Development Process Determine scope Consider reuse Enumerate Important terms Define Classes and the Class Hierarchy

3 Define Properties of Classes – Slots Define constraints Create instances

3.2 implementing the searching mechanism

3.2.1 Rules

3.2.2 SWRL

3.2.3 SWRL Rule Engine Bridge

3.3 Making the User Interface according to the requirements

listed in the SRS

3.3.1 Login

3.3.2 Advertise Your Ad

3.3.3 Register

3.3.4 Search

3.3.5 Send a Message

3.3.6 Email Ad

3.3.7 Report Generation

3.3.8 Administrator

3.4 Making the web based front end and back end for the PSWSC


3.4.1 Adobe® Flex® Builder™

3.4.2 Frontend Creating Pages Building Ads RSS feed Forms

3.4.3 Backend XML

1 Introduction

1.1 Aim

The Architectural Design Document (ADD) aims to create a modular

decomposition of the project Personalized Semantic Web Service for
Classifieds that is being developed.


1.2 people


Name Email address

Dr. Prasad Wimalarathna. spw@ucsc.cmb.ac.lk

Group Members:

Name Reg.No Index No

J.K.P.S. Chathurika 2007 cs 016 07000162
T.R. Kodikara 2007 cs 062 07000626
M.L.D. Prasad 2007 cs 093 07000936
R.G.S. Saranga 2007 cs 115 07001152
K. Wijewardena 2007 cs 139 07001398

1.3 System Overview

1.3.1 Project outline

Our project presents a scalable framework for personalized, ontology-

based, semantic web service discovery for classified domain by enhancing
the current search mechanism with semantic web technologies.

We provides user to advertise his vehicle ads in our system. Then anyone
can search the application with few keywords and can choose a vehicle he
desire easily.

This system also has increased functionality to allow for future expansion.
System will bridge vehicle buyers and sellers although they are in several
places in the world.

1.3.2 Project purpose

Normally a normal search on a classified web application the user faces

more difficulties when searching his needs. When the user searches a
vehicle using few keywords the system gives list of data (with lot of user
unwanted data). Then the user has to find the advertisement that suit to


him one by one. In here user gets a lot of troubles to find the actual
vehicle that he wants.

When searching, if the search gives only the data that the user probably
wants, it’s a huge opportunity to the user to find his needs easy and
without wasting any time.

2 Architectural Goals and Constraints

This project intends to use a Three Tier Architecture Model as the overall
system architectural model. This model was chosen due to its features of
scalability, reusability, maintainability as well as edibility. Adhering to this
model the system will be divided into three tiers.

Top Tier

Web Server Middle


Database/X Bottom Tier


° Top most tier involving System User Interface.

° Middle tier, the Web Server, handling request processing from the
top most tier and responding with the required information from the
bottom tier, handling also authentications and validations and
computation and analysis.

° Bottom tier acting as a store of data.


2.1 The Incremental lifecycle model

The Incremental Model of development is used as the Software Life Cycle

model in developing the product ‘Personalized Semantic Web Service for
Classifieds’. The product will be designed, implemented, integrated, and
tested as a series of incremental builds, where a build consists of code
pieces from various modules interacting together to provide a specific
operational capability.

The incremental model was chosen due to the fact that the ‘Personalized
Semantic Web Service for Classifieds’ project could be easily broken into
several parts which can be done independently of each other. The
separate design, implementation and testing will allow Team PSWSC to
utilize the available resources most efficiently. By using this model, an
operational quality product maybe delivered, at the completion of each
build. The gradual construction of the product will allow the team to add
new features later on without having to worry about the parts already
done. Finally it will make maintenance of the product much easier. Since
the various features of the system, have been implemented in builds,
narrowing down the area of a fault or upgrade is much more manageable.

2.2 List of the builds

The PSWSC project will be separated into four builds. The builds were
decided by analyzing the overall system structure, the priority of the
requirements and their dependencies. Lists of the four builds are shown

° Build one:

Implementing the ontology tree

° Build two:

Implementing the searching mechanism


° Build three:

Making the User Interface according to the requirements listed in

the SRS

° Build four:

Making the web based front end and back end for the PSWSC

2.3 Builds Interaction

The interactions of the four builds are shown in Figure 1.

Requirements Specification Architectural Design


Detailed Implementation Testing

Design & Integration

Detailed Implementation Testing

Design & Integration

Detailed Implementation Testing

Design & Integration

Detailed Implementation Testing

Design & Integration

Complete Application

Figure 1

3 Architectural Builds

3.1 Implementing the ontology tree

3.1.1 Goals of Build 1


The goal of this build is to create an Ontology Tree that will support the
proposed system.

3.1.2 Ontology Tree

Ontology is a formal representation of a set of concepts within a domain and

the relationships between those concepts. It is used to reason about the
properties of that domain, and may be used to define the domain.

In theory, ontology is a "formal, explicit specification of a shared

conceptualization". Ontology provides a shared vocabulary, which can be
used to model a domain — that is, the type of objects and/or concepts that
exist, and their properties and relations.

Ontologies are now central to many applications such as scientific knowledge

portals, information management and integration systems, electronic
commerce, and semantic web services.

3.1.3 Protégé

We use Protégé (Protégé 3.4.1) when developing the Ontology.

Protégé is a free, open-source platform that provides a growing user

community with a suite of tools to construct domain models and knowledge-
based applications with Ontologies. At its core, Protégé implements a rich set
of knowledge-modeling structures and actions that support the creation,
visualization, and manipulation of Ontologies in various representation
formats. Protégé can be customized to provide domain-friendly support for
creating knowledge models and entering data. Further, Protégé can be
extended by way of a plug-in architecture and a Java-based Application
Programming Interface (API) for building knowledge-based tools and


Figure 2

The Protégé platform supports two main ways of modeling Ontologies:

° The Protégé-Frames editor

° The Protégé-OWL editor

The Protégé-OWL editor enables users to build Ontologies for the Semantic
Web, in particular in the W3C's Web Ontology Language (OWL). So we use
The Protégé-OWL editor to build our Ontology. Description Logic Reasoners

In addition to providing an API that facilitates programmatic exploration and

editing of OWL Ontologies, Protégé-OWL features a reasoning API, which can
be used to access an external DIG compliant reasoner, thereby enabling
inferences to be made about classes and individuals in an ontology.

OWL-DL has its foundations in Description Logics, which are decidable

fragments of First Order Logic. For a particular task, a logic is decidable if it


is possible to design an algorithm that will terminate in a finite number of

steps (i.e., the algorithm is guaranteed not to run forever). For example, in
Description Logic it is possible to write an algorithm that calculates whether
or not one concept is a subclass of another concept, which is guaranteed to
terminate after a finite number of steps. Because OWL-DL ontology can be
translated into a Description Logic representation, it is possible to perform
automated reasoning over the ontology using a Description Logic reasoner. A
Description Logic reasoner performs various inferencing services, such as
computing the inferred super classes of a class, determining whether or not
a class is consistent (a class is inconsistent if it cannot possibly have any
instances), deciding whether or not one class is subsumed by another, etc.
Some of the popular Description Logic reasoners that are available are listed


° FaCT

° FaCT++

° Pellet

In our application we are using RACER logic reasoner when developing the

3.1.4 OWL

The OWL Web Ontology Language is a language for defining and

instantiating Web Ontologies. OWL ontology may include descriptions of
classes, properties and their instances.

The OWL language provides three increasingly expressive sublanguages

designed for use by specific communities of implementers and users.

° OWL Lite


° OWL Full


OWL is a component of the Semantic Web activity. This effort aims to make
Web resources more readily accessible to automated processes by adding
information about the resources that describe or provide Web content. As
the Semantic Web is inherently distributed, OWL must allow for information
to be gathered from distributed sources. This is partly done by allowing
Ontologies to be related, including explicitly importing information from
other Ontologies.

In addition, OWL makes an open world assumption. That is, descriptions of

resources are not confined to a single file or scope.

3.1.5 Ontology Development Process

Semantic Web

Toyata.o Audi.o

wl wl
Core Ontology

Internal Layer

Cars.o End-User
wl Service
Cars.ja (WSDL)

Figure 3
Dynamic Object Model Web Service, Control
Semantic Web applications usually need to make some ontological
Logic (Java Code)
commitments, i.e., (OWL
Reasoners they DL,
need to have hard-coded knowledge about certain
domain ontology.
…) In the example above, the application has hard-coded
behavior that depends on the cars.owl ontology, which contains classes like
Toyota and Audi. The application can also operate on extensions of these
core concepts, e.g., stemming from dynamic extension Ontologies about
specific types of Toyota cars and Audi cars. Then, the application can exploit
reasoning engines like Racer or rule engines like SWRL to expose


"intelligent" behavior. All of this is controlled by some logic (Java code),

which also interacts with the end user by means of interface technologies
like JSPs.

Ontology development steps,

Determine Consider Enumerate Define Define Define Create

scope reuse terms classes properties constraints instances Determine scope

In our Ontology we cover the domain, CAR.

Our system provides classifieds of cars. Here sellers can sell their cars and
buyers can buy cars which they prefer. Consider reuse

System reuses other Ontologies to save the effort, to interact with the tools
that use other Ontologies, to use Ontologies that have been validated
through use in applications.

Ontology libraries

° DAML ontology library (www.daml.org/ontologies)

° Ontolingua ontology library


° Protégé ontology library (protege.stanford.edu/plugins.html)

Upper Ontologies

° IEEE Standard Upper Ontology (suo.ieee.org)

° Cyc (www.cyc.com)

General Ontologies


° DMOZ (www.dmoz.org)

° WordNet (www.cogsci.princeton.edu/~wn/)

Domain-specific Ontologies

° UMLS Semantic Net

° GO (Gene Ontology) (www.geneontology.org) Enumerate Important terms

Make, model, sub models, year, engine, color, price, etc. Define Classes and the Class Hierarchy

A class is a concept in the domain which is a collection of elements with

similar properties. Classes usually constitute a taxonomic hierarchy (a
subclass-superclass hierarchy).

Instances of classes (individual),

° A car ad

Levels in the Hierarchy,

Top Level

Middle Level


Bottom Level

Figure 4 Define Properties of Classes – Slots

Slots in a class definition describe attributes of instances of the class and

relations to other instances.

E.g., each car will have model, color, engine, etc…

Slot and Class Inheritance

° A subclass inherits all the slots from the super class

° If a class has multiple super classes, it inherits slots from all of them Define constraints

Property constraints (facets) describe or limit the set of possible values for a

Common Facets

° Slot cardinality

° Slot value type

° Minimum and maximum value

° Default value Create instances (individuals)

The class becomes a direct type of the instance. Any super class of the direct
type is a type of the instance.


Example of Ontology,


Audi BMW Hyund Isuzu …


100 200 4000 … Accen Sonat Azera …

t a

CS S Base … GLS GS SE …

Seda Wago Coup …

n n e

2008 2007 2006 …

Red Green Yello …



Figure 5

3.2 Implementing the searching mechanism

This is the most important build of the system. Complete project completely
depends on this build.

Implementing searching mechanism is interconnecting the ontology and

individuals (In our system an individual is an ad).

Our system’s searching criteria works on according to the several user

inputs. In several stages user wants to select options that system gives.
Then system directs user to the correct destination very fast.

User Interface

Ontology Rule Engine Web Browser
Engine Bridge


Figure 6

3.2.1 Rules

Rules are of the form of an implication between an antecedent (body) and

consequent (head). The intended meaning can be read as: whenever the


conditions specified in the antecedent hold, then the conditions specified in

the consequent must also hold.

In order to write rules we have to use rule engine which facilitate sufficient
environment to write rules.


Human Readable Syntax:-

hasParent(?x1,?x2) ∧ hasBrother(?x2,?x3) ⇒ hasUncle(?x1,?x3)

XML Concrete Syntax:-

The XML Concrete Syntax is a combination of the OWL Web Ontology

Language XML Presentation Syntax with the RuleML XML syntax.

<ruleml:_rlab ruleml:href="#example1"/>
<swrlx:individualPropertyAtom swrlx:property="hasParent">
<swrlx:individualPropertyAtom swrlx:property="hasBrother">
<swrlx:individualPropertyAtom swrlx:property="hasUncle">

RDF Concrete Syntax:-


It is straightforward to provide such an RDF concrete syntax for rules, but the
presence of variables in rules goes beyond the RDF Semantics. Translation
from the XML Concrete Syntax to RDF/XML could be easily accomplished by
extending the XSLT transformation for the OWL XML Presentation syntax.

3.2.2 SWRL

SWRL (Semantic Web Rule Language) is a proposal for a Semantic Web

rules-language, combining sublanguages of the OWL Web Ontology
Language (OWL DL and Lite) with those of the Rule Markup Language
(Unary/Binary Datalog)

3.2.3 SWRL rule Engine Bridge

The SWRL Rule Engine Bridge is a subcomponent of the SWRLTab that

provides a bridge between an OWL model with SWRL rules and a rule engine.
Its goal is to provide the infrastructure necessary to incorporate rule engines
into Protégé-OWL to execute SWRL rules. The bridge provides mechanisms
to import SWRL rules and relevant OWL classes, individuals, properties and
restrictions from an OWL model; write that knowledge to a rule engine; allow
the rule engine to perform inference and to assert its new knowledge back to
the bridge; and insert that asserted knowledge into an OWL model. The
bridge also provides mechanisms to dynamically add graphical user
interfaces to the SWRLTab to allow interaction between a particular rule
engine implementation and a user.


3.3 Making the User Interface according to the requirements listed

in the SRS

This build is to implement user interface according to the User Interface

requirements listed in the SRS. Each screen in the SRS has been treated as a
module. The modules have been grouped into several module sets. Each
module set contains modules that are closely related to each other. An
illustration of the module sets is in Figure 6.

Advertise your
Home Login

Search Administrator
Register Create a new
Ste Maintenance

External Links

Send a Massage

Email Ad

Figure 7


3.3.1 Login

This module set contains the modules that will handle user login. It will direct
user to his personal account. If a user hasn’t an account he can register in
the system through “create an account” link.

3.3.2 Advertise Your Ad

After login user can put his ads on the site in this module. User wants to fill a
form to provide his information about the ad. User may also upload photos of
his car.

3.3.3 Register

This module requests several details from the user and create an account for
the user. User should fill a form including his personal details.

3.3.4 Search

This is the most important module of the system. This gives user to enter few
keywords and search. In few steps the system drives user to the ad/ads he
prefer. In the middle stages system takes few user inputs also. In a few
seconds user can select ad/ads he is looking for.

3.3.5 Send a Massage

After selecting ad user can leave a message to the ad holder.

3.3.6 Email Ad

In this module system facilitate user to email the ad he selected.

3.3.7 Report Generation

Here user can generate a report from the ad he selected.

3.3.8 Administrator

After login administrator can handle the system. E.g. maintain the site, set
user privileges, create accounts, delete accounts, maintain ads, etc.


3.4 Making the web based front end and back end for the PSWSC

The goal of Build 4 is to build the web site frontend and backend. To build
entire system we use ‘Adobe® Flex® Builder™ 3’ which is flash oriented
web design tool. E.g. page’s interfaces, ads, forms, reports, etc.

Flex Builder 3 MXML Compiler App.ht

ml f
App.mx App.sw

Figure 8

3.4.1 Adobe® Flex® Builder™

Flex is a highly productive, free open source framework for building and
maintaining expressive web applications that deploy consistently on all
major browsers, desktops, and operating systems. While Flex applications
can be built using only the free open source framework, developers can use
Adobe® Flex® Builder™ software to dramatically accelerate development.

3.4.2 Frontend Creating Pages


Home page consists of 4 blocks, top banner and other three vertical blocks.
Normally other pages consist of two blocks, including the top banner. When
building these things we use flex’s components. Such as Canvas, panel,
form, Hbox, Vbox, button, control bar, text area, data grid, etc. Building Ads

Flex builder has its own components list, also it provides user to build their
own components. We generate a flex component to use as an ad.

When considering the ad it has two forms, small and large. Immediate after
the user searching ads, ads will display as a small form. In small form there
are a few details are listed in the ad. Like picture, make, model, year. User
wants to click on the ad to view it as a large form. In large form there is all
details displayed in the ad.

Normally ad holds a picture of the car (if user didn’t upload a picture system
places a default picture), details of the car, details of the car owner, other
features and buyers can make a comments. RSS feed

We put RSS feeds from several automobile sites. Newest news from
automobile world will display on our site as well. Forms

When creating forms flex provides several components to create forms, like
label, text, button, check box, list, radio button, text input, etc.

3.4.3 Backend

When considering the backend it is full of xml files. We use xml files to store
all of our useful data other than a usual database. XML

When HTML is used to display data, the data is stored inside HTML. With
XML, data can be stored in separate XML files. This way we can concentrate
on using HTML for data layout and display, and be sure that changes in the
underlying data will not require any changes to our HTML.

In the real world, computer systems and databases contain data in

incompatible formats. One of the most time-consuming challenges for


developers has been to exchange data between such systems over the

Converting the data to XML can greatly reduce this complexity and create
data that can be read by many different types of applications.

All the ads (data) that user input will converts to xml files. User account
details are also stored as xml files.