Project On-Science

1
OnScience
A Project Report submitted in partial fulfillment of the requirements for the
degree of
Bachelors of Technology
Submitted by
Amrit Ravi (06BIF008)
Vellore Institute of Technology University
Vellore- 632014, TN, India
[DEC 01 - MAY 17(2009-2010)]

2
ACKNOWLEDGEMENT
Several people have been instrumental in allowing this project to be completed. First, we
wish to thank Mr. G. Viswanathan, Chancellor, Vellore Institute of Technology University
for the excellent opportunities and facilities provided for undergraduate education.
We would also like to thank Dr. Lazar Mathew, the Director of School of Bio Sciences and
Technology (SBST), Prof. G. Jayaraman (Divisional head for Bioinformatics) for giving us
the opportunity to pursue this project outside VIT University and supporting us in every
aspect.
We are deeply indebted to Dr. Rao Sethumadhavan, School of Bio Sciences and
Technology (SBST), for being our internal guide. We appreciate him for providing a healthy
environment which made us working under his guidelines interesting and easy. His
encouragement helped us all the time during the research and also in writing of this thesis.
He has also guided us in editing our work, and made sure that our performance was
delivered at a superior level.
For finding us eligible, selecting us to be a part of project and at the same time believing in
our capabilities required to comply with the task for the whole time we sincerely thank our
Project Guide Mr. Timothy Peterson, PhD fellow from MIT-Whitehead Institute,
Massachusetts, USA (http://www.wi.mit.edu or, http://www.whitehead.mit.edu).
It was a tremendous and extensively learning experience working with the group which
includes talents from all over the globe.
At last, we would like to thank the team members for creating an extremely friendly
environment for us and sharing every bit of knowledge while working on the project. It was
great to work with adepts of multiple disciplines so far and we wish and look forward to
work with them in future.

3
CONTENTS
TITLE PAGE NO.
Cover Page 1
Certificate 2
Certificate from Organization 3
Acknowledgement 4
Abstract 6
Abbreviations 7
Introduction 8
Literature Review 9
Resources and Methodology
Workflow 10
Architecture and Schematics Designing Phase 1 12
Interface Front-End and Database Development Phase 2 19
Linking of the Modules Phase 3 23
Referencing and Testing Phase 4 38
Advertisement and Promotion Phase 5 42
Result and Discussion 44
Future Aspects 45
References 46
The Team 47

4
Abstract
OnScience is the concept with the sole primary objective of providing ease of access to the
millions of users across the globe in order to make the data availability as abundant as possible
using a highly user friendly interface. The functioning of this concept has to do with certain
goals which are crucial in the domain of life-science to be specific and can prove to be a major
breakthrough. The ideology is to provide a publishing and granting network along with the
availability of information of every kind to make novel biomedical research findings widely
accessible and reviewable in real time. Our goal as a publisher is to provide autonomy to the
researchers in formatting their work and to expedite the publishing process. To promote
continued discoveries, we also aim to use the portal for connecting granting/funding
organizations directly to the researchers and scientists. Another aspect of OnScience is the
researcher rating system where you have the opportunity to see the ratings of different
scientists based on the number and quality of their publications, i.e. considering the impact
factors of the publishers. Features also include polling on relevant topics and discussions using
forum, blogs, news updates, ADTs, related to science all over the world.
OnScience will have both commercial and non-commercial sides in usual. A certain amount of
information will be made available to the users free of cost. For some specific data or content
the user might have to pay some nominal amount in return in order to use or download that
data using the e-commerce portal. The portal is designed in a way that it will work on almost all
major browsers available or utilized all over the world and contains multiple mini-widgets which
could help the user track the way user wants to obtain the information. OnScience will also
include an entertainment domain on its portal where users will be able to access or download
music, videos, snapshots and other relevant data types by paying the prescribed amount. The
portal is designed in a way that it covers almost everything a researcher would need in order to
pursue some study or scientific research whereas the comfort of every class of users is widely
considered during the development of the service.

5
Abbreviations
ADTs: Auto Downloadable Tools
ADI: Architectural Development of
Interface
AJAX: Asynchronous JavaScript XML
ALU: Arithmetic and Logic Unit
ANN: Artificial Neural Network
API: Applications Programming
Interface
AVI: Audio Video Indexing
ASP: Active Server Programming
BMP: Bitmap Format
CMS: Content Management System
CPU: Central Processing Unit
CSP: Client Side Programming
CSS: Cascading Style Sheet
CSSII
: Client Support System
DBMS: Database Management System
DC: Data Curator
DHTML: Dynamic Hypertext Markup
E-CP: e-Commerce Platform
FLV: Flash Video Format
FDDU: Front end and Database Development
Unit
DTD: Document Type Definition
FTP: File Transfer Protocol
GIF: Graphics Interchange Format
GUI: Graphical User Interfacing
HPT’s: High Precision Tools
HTML: Hyper Text Markup Language
HTTP: Hyper Text Transfer Protocol
HTTPS: Secured Hyper Text Transfer
Protocol
IE: Internet Explorer
IIS: Internet Information Server
IP: Internet Protocol
ISP: Internet Service Provider
ITT: Interface Testing Team
JPEG: Joint Photographic Experts Group
LAN: Local Area Network
LoM: Linking of Modules
MI: Module Integration
MIT: Massachusetts Institute of
Technology
MPEG: Motion Pictures Expert Group
OOP: Object Oriented Programming
ORM: Online Resource Management
PDF: Portable Document Format
PERL: Practical Extraction and
Reporting Language
PEAR: PhP Extension and Application
Repository
PHP: Hypertext Preprocessor
PNG: Portable Network Graphics
PRS: Peer Review System
PSD: Photoshop Document
QCM: Quality Control Meeting
QOT: Query Optimization Tools
RSM: Rating System Module
TQM: Total Quality Management
SEO: Search Engine Optimization
SGML: Standard Generalized Markup
Language
SMTP: Simple Mail Transfer Protocol
SQL: Structured Query Language
SRT: Server Response Time
SSD: Skeleton and Schematics Designing
SSP: Server Side Programming
URL: Uniform Resource Locator
VDU: Visual Displaying Unit
VI: Validation and Integration
WAI: Web Accessibility Initiative
WAMP: Windows Apache MySQL PhP
WGO: Web Graphics Overview
W3C: World Wide Web Consortium
XHTML: Extensible Hypertext Markup
Language
XML: Extensible Markup Language

6
Introduction
The past few years, in the makeover and
advancements of life-science has proven to
be crucial since several innovative steps are
taken. With the availability of much higher
precision tools (HPTs) and technologies now
research labs can perform huge load of
tasks in a matter of hours. Informatics has
traditionally been a discipline in which
mathematics and algorithm analysts of
higher expertise level, computer scientists,
statisticians and engineers develop
technologies for supporting information
management in fields like healthcare and
data management. Thus, today the field of
informatics supports a broad spectrum of
research that determines the biological
significance of the data provides the
expertise to organize it and develops
practical computational tools needed to
mine the data for new information.
With all these considerations and
requirements of a source of data with
diverse domains of information and, which
could aid in research in a broader sense the
concept of OnScience was developed by Mr.
Timothy Peterson a.k.a Tim, a PhD fellow
from Massachusetts Institute of Technology
and a senior researcher from MIT affiliated
Whitehead Institute in Boston, MA. The
idea when proposed consisted of a plan to
bring out all the resources, be it data,
images, plots, graphs, videos, tutorials or
any relevant information, summed up onto
a single centroid interface so that the
researchers find it easy to grab all the
information they want in just a few clicks
under one roof. The project was planned
well and divided into five phases tentatively
at the beginning where the first 4 phases
involved the architecture development,
interface module development, additional
tools and annotation of data, cross
referencing of the output integrity, whereas
the last phase dealt with the marketing and
strategy planning for the interface which
proved to be a major deal since big names
like pubmed and swissprot were into the
market. The timeline of the project was
decided to be for 15 months from the date
of beginning of the development, which is
12th
December’ 2009.
The most important aspect and the reason
of the successful implementation of the
planned protocol was the team working on
the project. The team was well accoutered
with the members from all around the
globe having roles specific to their
expertise, i.e. programmer, data curator,
interface developer, back-end developer,
web programmer, biologists, senior
researchers from MIT-Whitehead Institute,
Harvard University, University of Michigan
and several other research laboratories.
With the success of every phase of this
project the team learnt the professional
and realistic approach towards high-end
platform development and its basic pros
and cons. Once the product will be
launched, it will provide its users an easy
and efficient way to access enormous
amount of useful data where the user will
get an assurance of having many media
types on a single platform.

7
Literature Review
Every new invention is followed by many
followers who try to improve the existing
facility. OnScience was planned with the
same objective. The idea came up when Tim
Peterson and a few members from MIT-
Whitehead Institute planned to develop
one such interface from where scientific
information can be retrieved at a wide
scale. To be more precise the idea was to
put together all the possible data or
information types and put it on a centroid
server from where users all around the
globe could use it. Seeing the current
situation of pre-existing scientific
encyclopedias this idea was not bad and
Peterson realized that real fast and
performed a quick action to form a
development team.
One knows it well that for any interface
development at a larger level, it requires
the involvement of numerous technologies
in the form of interfaces and languages,
same happened during different phases of
this project. The team started with the
architectural designing of the whole
interface involving the usage of Cascading
Style Sheets (CSS) which is a part of HTML.
It is one of the most effective ways to
design a very intact and well formed front-
end layout. PHP proved to be a major part
of the coding segment. Most of the
modules were coded using this eventful
language and the team used PHP 5.0
version and object oriented frameworks like
CAKE PHP to perform the coding for several
modules. References and Reviews were
taken from various sources including books
and journals. Mentioned resources were
crucial in manipulating and debugging
scripts at different stages of the project.
SQL concepts were used to send and
retrieve data to and fro the database. SQL is
known as structured query language and is
widely used to access stored data from the
database in different formats as required
using the query codes. Multiple articles and
journals were referred and read to
accomplish the required objective. Major
level data exchange was facilitated using
the concepts of SQL at various stages of the
developmental phase and it was one unique
experience for the team to learn some great
recent advancements of this powerful
language.
JavaScript was utilized to write some
advanced client side modular segments for
the interface. Multiple small parts of the
front-end were coded using this highly
required language. Journals were referred
to troubleshoot certain complexities. AJAX
is another function or, we can say, an
advancement of JavaScript which was used
in order to bridge a connection between
the JavaScript application and the server
side. AJAX is used to exchange data sets
between client-side and server-side in case
of JavaScript and is considered to be one of
the highly in-demand necessities of current
coding scenario. Visual Basics and .NET
where indispensible part of the coding
schema and were used at different stages
of the project. With all the available
resources and full coordination of the team
finishing the objective was just an excuse to
work more and more for the great aim.

8
Resources and Methodologies
Workflow
The project development was categorized into five broad phases with specific roles in each of
the phase:-
 Architecture and Schematics Designing
 Interface Front-End and Database Development
 Linking of the modules
 Testing of the Interface in multiple ways
 Advertisement and Promotion
We will be seeing the role of each and every phase one by one elaborately later in this section.
Each and every phase of the project was allotted with a tentative time frame. The progress
report was subjected to be continuously verified by the team leaders at the completion of each
working day.
Below is the representation of the entire project scenario:
Representation of the project workflow (figure 1.1a)

9
The overall approved project plan (figure 1.1b)

10
Phase 1
Architecture and Schematics Designing
The entire team was split up into several
groups based on their skills and interests.
The team responsible for the architecture
development consisted of 4 members and a
team leader. Since several members of the
entire team were participating virtually
being at the remote locations an FTP was
set up so that every member could get an
idea of the project progress and can put in
their suggestions and ideas. Before the raw
designing started it was of utmost priority
for us to have a sound idea of what actually
is needed by the current users which is
either unavailable or could be improved.
Many journals and articles were referred to
get help on this. The work began with the
enlisting of modules required to be there on
the interface with maximum user
involvement expected. Usually when one
starts to analyze currently existing scientific
web portals, the information they provide
are mostly job related, papers and journals
published or news updates. We thought
something out of the box. We planned to
include a rating system for the researchers
all over the world.
The objective was simple, to have a
centroid module where users from every
domain shall be able to see the ratings of
the scientists of their interest. The rating
was based on a simple algorithm where we
used certain parameters such as number of
papers/journals published, publishers
details, impact factor of the publisher,
whether the scientist is a first or second or
third author of the paper and similar other
criterions. These parameters were
formulated and the module architecture
was drawn. This is just an idea of how the
modules were planned in order to make the
interface maximum resourceful for the
user. The basic layout of the interface was
planned by SSD team which included many
options, such as, a link to home page, a
resources column, a news update section, a
poll of the week section, a peer review
system column, scientist rating column,
feedback forms, contact details and forms,
downloading column where the user could
download papers, articles, e-books, guides,
journals, magazines, tutorials and many
more, a multimedia column where the user
shall be able to listen to podcasts, watch
videos and download them all if needed.
There was a section prescribed for the users
as “submit your information” where the
user could create a profile and add personal
information including his/her resume and
other documents including published
papers and reviewed journals.
A major challenge for us was to develop a
modular architecture with an outstanding
robustness as an E-CP. In order to sustain
among the users and provide the best
outcome at the same time we had to
develop an algorithm with the capability to
take care of the interests of both the client
as well as the service provider. Considering
other major factors like the genuineness of
the rating of the scientist we planned a
dummy platform where the users were
asked to fill in their information or we can

11
say they were asked to create their profiles
along with all of their information so that
the rating system algorithm could be tested
for its efficiency which was a major issue.
Since the algorithm was all new and the
idea was new as well it was a firsthand
experience for all of us. We had to take care
of the factors starting from personal rights
including the right of privacy and the right
to contain original data by the scientists.
The development began with the sketch
work using highly efficient interface tool to
bring maximized effect in the layout
considering the user demands.
Projected main page layout for OnScience (figure 1.2)
The interface shown in figure 1.2 is the
projected main page or, home page for the
OnScience web portal. As mentioned earlier
it includes all the planned modules
discussed. The technologies as discussed in
the literature review section were PHP and
Javascript for the mainframe design and the
validation purposes for the page
respectively. One important aspect of
aesthetics while developing the
architecture was that the page to be
opened shall not be too overloaded with
excessive scripts and unnecessary large size
graphics. The team made sure that all the
graphics were to be of best resolution along
with manageable size factor. The major part
of the architecture development tested our
patience and skills both when we moved
into the security part of the portal and its
content which included sensitive and
personal information of many researchers
and individuals. Developing a system with
highest level of encryption with the
neatness of not affecting the remaining part

12
of the program was one major challenge.
The objective was to implement
encryptions at each possible level of the
system so that no usual hacking program or
bot could have an access or manipulate the
server and administrative data. Technology
involved was shell programming to provide
layers of data security which was for us a
learning experience. The next round of
work was to decide and finalize the modular
architecture for each and every modules
decided to be there of the portal. It was a
major deal as modules were the major part
constituting the web interface. Each and
every module had a specific task to perform
for the user and it had to be worth the
space it takes on the interface. In order to
understand the workflow in a full-fledged
scale one needs to go through each and
every module one by one and understand
the functionality well in advance before one
move to the schematics part.
Module by Module
A. Feedback Module
Info: “Rate this” module was designed and
integrated to rate any feature or content of
the portal. Here on the scale of 5 the user
can rate each and every part of the portal.
Taking an example, if a user likes a
particular article published with OnScience
then the user can rate that article based on
which the rating of the article will increase
and then it will be displayed under “highly
rated contents” section of the portal.
Another parameter to rate is to simply click
(+) or (-) shown on the module. If any user
selects (+) then the positive feedback is sent
for the particular subject on the interface.
B. Poll Module
Info: “Poll Module” was designed to
perform single and multiple option polls. It
is independent of any language barrier and
can be integrated in both Active Server
Programming server as well as Hypertext
Preprocessor server. Performing speed polls
and effective handling were the two major
objectives for the development of the
architecture of this module. The user can
see the poll results as well as create a poll
which, to appear on the mainframe, needs
to be approved by the administrators of the
portal. Multiple and Single options can be
selected as poll answers depending on how

13
the question is framed by the administrator.
Overall reviews proved it to be a very smart
and handy application altogether to
integrate with.
C. Sign Up Module
Info: “Sign-Up Module” is a highly secured
login module. The user can sign-up/register
or sign-in with the help of this module. The
user can subscribe to newsletters and
update personal details using this module.
It is a fine example of a secured login
gateway. The passwords are encrypted
using md5 method which is generates a 32
bit encrypted string of the password which
is unique and cannot be retraced.
D. Top Download Viewer
“Top Download Viewer” is a module
which is designed to display the articles
and subjects which are mostly
downloaded by the users. It is designed
based on an algorithm which works on
the number of clicks done at the
download link. It also provides with the
rating system integrated to make the
rating possible at the same time frame
while the user downloads.
E. Intra Search Module
Info: “Intra Search Module” is the module
designed using PHP concepts to retrieve
data/information, i.e. articles and journals,
published papers within the website. In
other words it can give the user back all
the data present in the database of the
system. As mentioned in the figure, there
are three parameters based on which the
search operation works
 Document Name
 Title
 Author
It is an effective and easy to integrate
module. The user can also find an
alternative option to login or signup in case
the user is not using the main page login
option. The algorithm implemented is

14
simpler and easy to process and thus the
module consumes very less of resources.
F. Complete Search Module
Info: “Complete Search Module” unlike the
Intra Search Module is not confined to the
interface database. It has the capability to
pull data from any source tangled to the
World Wide Web. We can say that it has
similar functionality as Google with a very
effective time response frame.
There are hundreds of search algorithms
which can be implemented in order to
retrieve data from internet sources but our
team used the expertise of MIT experts to
develop our own version of the algorithm
which was truly time efficient and spam
free. It was designed in a way that it
automatically eliminates the spams, applets
or unnecessary advertisements attached
with the desired search outcomes with the
help of the extensive and robust programs
running extensively behind the scene.
0
10
20
30
40
50
15 sec 30 sec 45 sec 1.0 min
1 Click
2 Click
3 Click
Time schematics of the response after click (figure 2.1)
G. Search the Catalog Module
Info: “Search the Catalog Module” is
designed to perform a search confined to
the catalogue present in the interface. The
catalog consists of major attractions or
features of the interface where the user can
just glance quickly all the key notes and
functionalities of the interface. It works on
another specific and short algorithm and
database handling concepts are invoked to
retrieve desired outputs.
H. Upload your Doc Now Module
Info: “Upload your Doc Now Module” is a
module developed to provide the user the
ability to upload certain documents or
belongings, i.e. Resume, Paper, Journals,
Articles etc. It can also be used to upload
media files to user’s personal dashboard for
entertainment purpose.

15
There is a fixed size defined for the users to
upload any file. It is 1 MB for any image file
and 5 MB for any video clip. Any file above
the defined size limit will be automatically
sent to the trash folder of your profile.
I. Scientist Rating System Module
Info: “Scientist Rating System Module” is
one of the most innovative modules
developed during the course of this project.
The functionality is in a way that the user
enters the name of the scientist of user’s
choice and the module generates the
profile of the scientist based on the
parameters running at the program end of
the module. The algorithm was worked out
to bring highly precise and justified output.
Any scientist was rated based on the
number and quality of the paper he/she has
published. Another parameters include the
impact factor of the portal publishing the
paper, whether the author is a first author
or not and many other factors.
There was a small formula developed based
on the raw algorithm implemented in order
to bring the preciseness in the action.
The position value will be taken as 1 if the
author is the first author of the article. The
entire sum value will depict the rating of
the scientist and display to the users.
Extensive use of PHP coding is used to pull
out this kind of information.
J. Publication Help Module
Info: “Publication Help Module” is the
module which is connected to a sponsored
link with one of the sponsor corporation of
the project and the module is developed to
provide all the resources which are required
by an author to submit his/her article for
review before submitting for the
publication. We know that publishing a
paper is not definitely just about
performing the research work and
displaying the results on a white sheet.
There are a lot of steps required to get a
paper published starting from formatting
the raw data into an abstract and then
collecting the abbreviations to formatting
the content. This module leads an author to
all such information and provides standards
to perform such tasks. The corporation
providing help is widely famed for
publishing prestigious and high valued
journals and papers and provides free aid to
the authors seeking for assistance.

16
K. Peer Review System Module
Info: “Peer Review System Module” is one
of the highly worked out module and we
can say the most widely accessed module.
Here the peers an create their profiles and
then view articles available for rating. Once
they are able to access the material they
get an option to review the material based
on certain parameters including
genuineness of the material, how good is
the content etc. As you can see the display
image which shows that user is logged in
and in the right and top menu bar the user
has got an option to view articles.
PHP 5.0 was implemented to develop this
module and the objective was to show an
overall rating of any article or journal based
on the prescribed parameters. Profile
information like email address, personal
URL or webpage address, Organization,
Department, Address, Alternate email,
telephone number, fax number and areas of
expertise are some of the few key nodes
taken as parameters in the development.
Time Distribution
Time distribution for the architecture development
of ever module proposed (image 2.2)

17
Phase 2
Interface Front-End and Database Development
Phase II of the project began in February
first week of 2010. The objective as the
name says was to implement the
architecture formed into an interactive
interface for the system and to perform the
database development task simultaneously.
The team structure was also revised with
some excellent database developers joining
our team. Phase II of the project involved
more of practical approach than theoretical
reading done in the previous phase where
the WGO team had to take a lead. In order
to perform an efficient coding we needed to
develop each and every module with the
sole knowledge that the module has to be
low in size when it is integrated with the
main frame and it has to be quick in
execution.
While coming to the database part, it was a
well enlarged part to deal with and had
several major and unavoidable issues to
cope with before the development started
as prescribed by the FDDU. The schema
design began by the database development
team. Raw ER Diagrams were drawn one by
one and comparisons were made in order
to find out best ER Model structure.
Multiple issues and opinions came out in
order to optimize the ER Model. Database
was handled on MySQL and certain
manipulations were made to mould the
functionalities towards what we needed.
Security of the database was a big challenge
and requirement for the working team
since there were hundreds of spammers
and hackers who possess the capability to
pool into high-end systems and manipulate
or steal or corrupt important data. With us
it was a stern requirement because our
database was going to store personal and
scientific information of naïve to expert
researchers. We had to be sure of a leak
proof storage system.
Time and resource allotment chart for development
phase II (figure 3.1)
As we see that the database development is
allotted with more time and resources we
can infer that how important the task is.
The ER diagram development took almost
15 days time to be turned out as most
precise. At the same time the proposed
modules were finalized and teams were
split to be allotted with specific assignment
for the front-end coding. Each and every
module selected to be a part of the portal
were to be presented as highly independent
and robust as they could have been so the

18
best people available for graphics and
multimedia were allotted the task.
The process of database designing
Database design is the process of producing
a detailed data model of a database.
This logical data model contains all the
needed logical and physical design choices
and physical storage parameters needed to
generate a design in a Data Definition
Language, which can then be used to create
a database. A fully attributed data model
contains detailed attributes for each entity.
The term database design can be used to
describe many different parts of the design
of an overall database system. Principally,
and most correctly, it can be thought of as
the logical design of the base data
structures used to store the data.
Out of all in the relational type of database
management model these parameters are
the tables and views. In an object database
most of the entities and relationships map
directly to object classes and named
relationships. However, the term database
design could also be used to apply to the
overall process of designing, not just the
base data structures, but also the forms and
queries used as part of the overall database
application employed within the database
management system (DBMS). The design
process consists of the following steps:
1. Determining the purpose of your
database - This helps prepare you
for the remaining steps.
2. Finding and organizing the
information required - Gather all of
the types of information you might
want to record in the database,
much as product name and order
number.
3. Dividing the information into
tables - Divide your information
items into major entities or objects,
such as Products or Orders. Each
object then becomes an individual
table.
4. Turning information items into
columns - Decide what information
you want to store in each table.
Each attribute becomes a field, and
is displayed as a column in the
table. For example, an Order table
might include fields such as User
Name and Order Date etc.
5. Specifying primary keys - Choose
each table’s primary key. The
primary key is a column that is used
to uniquely identify each row. An
example might be Product ID or
Order ID.
6. Setting up the table relationships -
Look at each table and decide how
the data in one table is related to
the data in other tables. Add fields
to tables or create new tables to
clarify the relationships, as
necessary.
7. Refining your design - Analyze your
design for errors. Create the tables
and add a few records of sample
data. See if you can get the results
you want from your tables. Make
adjustments to the design, as
needed.

19
8. Applying the normalization rules -
Apply the data normalization rules
to see if your tables are structured
correctly. Make adjustments to the
tables, as needed.
Now that we understand the process and
steps of database development we now
understand how critical this part would
have been. Below is a small representation
of the overall logic on how the database
system is interlinked:
A raw interlinking diagram for a database system
for an interface (figure 3.2)
As we see, the centroid for such a system is
the database server. A database server is
a computer mediated and controlled
program that provides the database
services straightaway to other computer
programs or computers, as defined by
the client–server model. The term may also
refer to a computer dedicated to running
such a program. Database management
systems frequently provide database server
functionality, and some DBMSs rely
exclusively on the client–server model for
database access. Such a server is accessed
either through a "front end" running on the
user’s computer which displays requested
data or the back end which runs on the
server and handles tasks such as data
analysis and storage. In a master-
slave model, database master servers are
central and primary locations of data while
database slave servers are synchronized
backups of the master acting as proxies.
Some examples of Database servers are
Oracle, DB2, Informix, Ingres, and SQL
Server. Every server uses its own query logic
and structure. The SQL query language is
more or less the same in all the database
servers. Now, proceeding ahead with the
interlinking as shown in figure 3.2, the
database server is connected to three
domains controlling three different
functionalities with prime importance
respectively. The development domain is
responsible for all the steps and
methodology for the structure of the
database system. A robust structure is
always expected in most of the cases.
Another domain is test domain where the
database server rechecks the structured
development of the schema repeatedly and
sends feedbacks to the server to assure
about the design and generates alerts if any
improvement is possible. The third domain
is production domain where the tested
database structure is relayed out to become
the finalized design. The production domain
assures the safe transaction of data through
the server. There are tables tangled with
the respective domains carrying valuable
information under a secured surveillance.

20
The process of front end designing
As the name speaks, front end of a web site
is the face of the web interface which is
seen by its users. It is indeed the part which
actually attracts the attention of its users
even if developing what is running at the
back of the website be the toughest deal
(no one sees what is going at the back end).
During the development of a web interface
there are certain key-points a developer has
to take care of:
 What browser/platform configuration
breaks your page when you use which
technology
 Which technology or elements to use to
create the navigation in
 What to do to avoid wrong display on
browsers
 How to keep the size of the final
document small
 How to convert graphics so that they
are small in file size and yet good
looking
 How to deal with data coming from the
customer in various and sometimes
rather exotic formats
 How to keep his work from stalling
when there is no data coming in that he
can use.
 How to communicate to colleagues or
customers that the amount of final data
in the product does not really fit the
design (which is a case of bad planning
to begin with, but it does happen)
 How to keep up with the rapid web
development market and techniques.
In our case it will be fair to call it as a user
interface since we were developing a
platform where the user can interact with
our system. A key property of a good user
interface is consistency. There are three
important aspects. First, the controls for
different features should be presented in a
consistent manner so that users can find
the controls easily. For example, users find
it very difficult to use interface when some
commands are available through menus,
some through icons, and some through
right-clicks. A good user interface might
provide shortcuts or "synonyms" that
provide parallel access to a feature, but
users do not have to search multiple
sources to find what they're looking for, so
we took care of this part with utmost care.
Second, the known "principle of least
astonishment" is crucial. Various features
should work in similar ways. For example,
some features in Adobe Acrobat are "select
tool, then select text to which apply."
Others are "select text, and then apply
action to selection."
Third, user interfaces should not change
version-to-version, user interfaces must
remain upward compatible. For example,
the change from the menu bars of
Microsoft Office 2003 to the "ribbon" of
Microsoft Office 2007 is universally hated
by established users. The "ribbon" could
easily have been "better" in the mid-1990's
than the menu interface if writing on a
blank slate, but once hundreds of millions of
users are familiar with the old interface, the
costs of change far exceed the benefit of
improvement. The vast majority of users
viewed this forced change, without a

21
backward-compatibility mode, as
unfavorable; more than a few viewed it as
verging on malevolence. Good user
interface design is about setting and
meeting user expectations. Better (from a
programmer's point of view) is not better.
The same (from a user's point of view) is
better. Considering all these issues which
needed prime attention of the team the
developers performed the coding in
languages like HTML with a exceptionally
good use of CSS, PHP, JavaScript, VB Script
and many bridging languages in between.
Now we will move to the next phase to see
the modular integration and some sample
layouts designed for the web portal.
Phase 3
Linking of the Modules
Before we move to the phase 3 explanation let us go through some of the screenshots of the
front end development explained in phase 2.
Home page layout for OnScience (image 4.1)
As we see and explained before the home
page was designed with basic and soothing
color combinations. The logo is located on
the top left along with intra-search module
on the right of the top banner. The main
menu holds options/links to home page,
Genres, Publications, Upload, Login and
Signup. When we move down we see a
search option which navigates the user to
the database search module were the user

22
can access 28 research publications. The
upload link next to it takes the user to the
upload section where the user can upload
personal facts and documents, e.g. resume.
Upload page along with the view of top downloads and search modules. You can also see publication help
module at the bottom center (figure 4.2)
The above mentioned snapshot discloses
the features like upload your doc, search
through the catalog, top downloads,
publication help module, overall search
module, sign up module and login module.
Most of the features of the mentioned
modules have been discussed in earlier
section in phase II, module by module
explanations. One can easily figure out the
interface as it is completely user friendly.
FAQs layout for OnScience (figure 4.3)

23
Newsfeed layout for OnScience (figure 4.4)
Newsfeed section controls all the feeds and
categorized news updates for the portal. As
one can see in the snapshot there are
categories like general, current users,
languages etc. We can also glance at the
top navigation panel of the snapshot where
we can see how we are navigating on the
pages.
Weblink layout for OnScience (figure 4.5)

24
Registration page for OnScience portal (figure 4.5)
The page shows the registration panel for the
OnScience portal. All the fields are compulsory
to be filled. This panel once filled provides user
with a username and password which will be
used for future login purpose. The display
theme is one fine example of overlay screen on
web interfaces which are quiet famous these
days and can be commonly seen on portals.
Search (advanced) page for OnScience portal (figure 4.6)
The snapshot displayed is for advanced
search page. As we are seeing here there is
a field given for accepting the search
keyword. Three categories are given as all
words, any word, Exact Phrase to put the
searching constraints. Search can be
confined to Articles, Weblinks, Contacts,
Categories, Sections and News Feeds. The
result of the search employed is displayed
below the page.

25
Now since we are through with the screen
shots for the front end development, let’s
concentrate on the modular integration on
the portal. In the previous section we have
already acquired lump sum knowledge
about modules to be added. Below are the
two major modules which are explained in
details with their construction methodology
and functionality. The two modules are:
 Scientist Rating System Module
 Peer Review System Module
Scientist Rating System Module
Home page of the Scientist Rating System Module (figure 4.7)
As the screen says, the home page provides
multiple links including the link which takes
you to the login page. Once you login to the
page you will be navigated to the page
where you will be asked to provide the
name of the scientist for your choice. Once
you submit the name of the scientist the
server will provide you with the rating of
the particular scientist on the same screen.
The script is written in a advanced manner
and is designed to produce specific outputs
based on the keywords. Other links present
on the home page navigates you to the
Arborh (OnScience) home page,
technologies section, products section,
communities section. There is a flash
section on the home page as shown which
provides a slide show of certain relevant
images informing about recent scientific
events. Now we will see other screens of
the same module in order to understand
the functionality elaborately.

26
Login page for Scientist Rating System Module (image 4.8)
Find your Scientist page for OnScience portal (image 4.9)

27
The above mentioned image 4.8 is
displaying the login page for the scientist
rating system. The login page requires a
new user to register with the portal first
before he or she could use it. Once
registered, the server automatically will
send a confirmation mail to the email
address of the user which would be needed
to be confirmed by the user by going to the
provided mail address. Once the user
confirms the account credibility by clicking
the link sent by the server from inbox the
user will be redirected to the page
displayed in image 4.9. The navigated page
is the location where user provides the
name of the scientist of his choice (for
which the user wants to see the rating). All
the user has to do is put the name of the
scientist in the text box given and then
presses submit. The ratings along with the
total number of publications with reference
IDs and details will appear right away.
Result page generated by the server once the query has been run (figure 4.10)
Figure 4.10 shows the server redirected
page once the user as given the query as a
name of the scientist. The server generates
the number of publications scientist has
made along with the journal title and PMID
of those journals respectively. When we see
to the right side of the screen we find a box
which we call the rating panel. The rating
panel displays the rating in two forms. One
is by displaying the rating as a star mark
rating out of five stars. Similarly the other
rating pattern is based on the score out of
100 points. The algorithm employed is same
but the difference is that in one case it is
displayed as starts secured whereas in
other case it is the rating based on numeric
system. The data produced by the algorithm
is genuine or not was verified by the
developers effectively and time and again
using multiple data sources.

28
A sample code fragment used to retrieve scientist details from World Wide Web (figure 4.11)
As we see here, the script is simple and
efficient enough to pull all the required
data. The code is written using PHP
concepts. It is just a fragment of the code
and there are numerous other fragments
which combine to give an effective outcome
to the interface. PERL concepts as we can
see are used. One major objective of the
team while working was to develop codes
which could be of minimum length with the
effectiveness and robustness of higher
degree. HTML concepts are used further in
this script to generate the tables in the
output page. The design and graphics of this
page were kept simple and lower sizes since
it directly affects the downloading of the
page if the user is using a lower bandwidth
internet connection.

29
Peer Review System Module
PRS Module is a segment of the interface
with two sides. One is for the peers who
review the articles submitted by users and
the other is for the users where they can
upload their articles and journals. The user
can create an account, login to the
interface, read and upload articles at the
same time those articles would be reviewed
by the peers who get a separate login
interface with different options to review
the articles and journals. The aim of this
module is to provide an online alternative
to traditional academic journals that will
allow for easy and rapid publication and
increasingly unbiased peer review of the
journal articles. The technologies used for
the development are PHP 5.03, MySQL,
MD5 Encryption, HTML and CSS, Object
Oriented Programming Concept (OOP) –
PHP Mailer, XML applications and Flash.
Home page for the PRS system (figure 4.12)
As mentioned in the home page there are
multiple links such as peer login, manager
login and user access. Each login has its own
privileges and restrictions except manager
login since the manager is the one who
controls the interface activities. Peer login is
designed for the experts who will access the
journals and articles using this login and
eventually will review them. User access
option is for the users where they can login
and create their profiles and upload
contents as well. The user will be able to
see the review results for various articles
including the uploaded by user itself.

30
Peer login page for the PRS module (figure 4.13)
Profile page of the peer once logged in. Options like profile, view articles and logout can be seen (figure 4.14)

31
Figure 4.13 displays the login for peers
using which they can visit their profiles and
rate the articles and journals. Once the
login is successful the peer is taken to the
next page, as shown is figure 4.14, where
the peer has the option to edit or view its
profile. Other options include view articles
and logout. Using view articles the peer can
see the articles available for reviewing and
rate them based on the parameters given.
Profile page for the peer login interface (figure 4.15)
Rate this article page for the PRS module (figure 4.16)

32
As displayed in the image 4.15 of the PRS
module the “edit profile” page can be seen.
This page allows the peer or the user to edit
and upload information to the PRS
database. The options to be edited in the
profile section are organization,
department, address, email, alternate
email, telephone, fax, personal webpage
and area of expertise. Figure 4.16 displays
the journal page where the peer can go
through the journal or article. There is an
option at the right side menu bar of the
page where the option “Rate this article”
can be found. Once the peer/user clicks
that option the server navigates to the
review page where peer will find the
parameters of rating the article. The
interface of the review page is shown in
next screenshot.
Review page for the journals and articles. Various parameters of rating is shown in the screenshot (figure 4.17)
Figure 4.17 depicts it well and clear about
the parameters of the reviewing of articles
and journals. Parameters given are:
 What according to the peer is the
originality level of this article
 How significant in peers opinion is
the article related to the topic
mentioned
 How accurate or rigorous is the
article or journal submitted for
review
 What existing journal on the
OnScience publication would go to if
it were not OnScience
 Comments from the users upto 1000
characters
The team performed multiple surveys
before generating the series of parameters
in order to bring highly genuine and precise
ratings. Based on the reviews done by many
peers the average is taken and the review
ratings are decided and redirected to the
stats page by the server. The stats page
consists of a graphical output which

33
displays the average rating of an article
based on the tree parameters as mentioned
forth and also an overall rating. The image
is generated dynamically using PHP graphic
libraries, XML, and flash files (swf) are also
utilized.
Stats page of the PRS module once the peer has reviewed the article (figure 4.18). The graphical output can be
exported in different formats like JPEG, PNG, GIF and BMP.
Timeline Distribution for the PRS Module
12/11/09- The project was started and we were
given the outlines of the work we are supposed
to do.
13/11/09 to 18/11/09-
 A general analysis of the Peer Review
Rating System was done.
 Various online journals were visited to
have an idea of the type of data
required to complete such a system.
 To get the concepts to use PHP for the
system from the articles and journals
23/11/09 to 28/11/09-
1) Decided over the metrics on which the
users and the peers will be able to rate
the articles published in the journal.
These are :
 Originality of the article
 Significance to the field of the
article.
 Rigorousness or the level of
accuracy for the article.
 In addition the user will also be
required to suggest some
comments for the betterment of
the journal which is kept optional.
2) Revised concepts on database
management from articles and journals
3/01/10 to 10/01/10-
 Scripts were written for the login and
logout of the peers and also for the
profile display of the peer.
 The peer ratings were stored into a
database and then converted to
graphical output using PHP libraries,
Flash and XML.
15/01/10 to 22/02/10- Module testing and
analysis of the outcome.

34
Strategy planning of PRS Module
The strategy flow of the PRS module (figure 4.19)

35
System schematics of PRS module
System schematics of events in the PRS module (figure 4.20)

36
Phase 4
Referencing and Testing
Phase IV of the project OnScience began in
mid march with a clear objective of cross
referencing each and every node of the
project with the valid and standard data.
Since we know that testing is one of the
major parts of any application or interface
development, the OnScience Testing team
allotted ample time for the testing part. In
the development of many programmes and
large projects, testing takes up a significant
portion of the budget and time. At
OnScience, the project managers defined
what they want to achieve from
testing; deliver the ongoing and standard
testing benefits and maximize the adequate
return precisely on the resources used.
Testing is not just about reducing risk but it
is also about increasing control. By aligning
the testing objectives with the OnScience
objectives and by increasing the
effectiveness of testing both will be
delivered.
For example:
 Including testing expertise in the
contractual definitions for the
system or service and the
acceptance processes can
significantly reduce the electronic
delivery risks
 Providing objective and accurate
information on risks, issues and
milestones throughout the project
lifecycle can significantly increase
control. And this clarity enables
managers to make informed and
timely choices as the project
proceeds. Precise and effective
testing services improve the
outcome and the journey to
create it.
There were several levels on which the
testing was performed in a widespread
manner:
 Performance Testing: including load
testing, stress testing, scalability
testing and performance monitoring
services
 Migration Testing: including data
conversion and the wide application
or infrastructure migration
 Usability Testing: by using customer
representatives and expert
assessments
 Security Testing: including the wide
penetration testing, threat
assessments and risk analysis
 Web Testing: including a full set of
test lab services such as
compatibility and interoperability
testing
 Business Continuity Testing: involves
including resilience and failover
testing
 Disastrous Recovery Testing: The
system includes backup and recovery
testing
 Network Testing: including network
performance monitoring and tuning

37
The flow schematics of the testing phase of project OnScience (figure 5.1)

38
Application or Modular Testing
Application testing deals with tests for the
entire application. This is driven by the
scenarios from the analysis team.
Application limits and features are tested
here. The application must successfully
execute all scenarios before it is ready for
general customer availability. After all, the
scenarios are a part of the requirement
document and measure success.
Application testing represents the bulk of
the testing done by industry. Unlike the
internal and unit testing, which are
programmed, these test are usually driven
by scripts that run the system with a
collection of parameters and collect results.
In the past, these scripts may have been
written by hand but in many modern
systems this process can be automated.
Most current applications have graphical
user interfaces (GUI). Testing a GUI to
assure quality becomes a bit of a problem.
Most, if not all, GUI systems have event
loops. The GUI event loop contains signals
for mouse, keyboard, window, and other
related events. Associated with each event
are the coordinates on the screen of the
event. The screen coordinates can be
related back to the GUI object and then the
event can be serviced. Unfortunately, if
some GUI object is positioned at a different
location on the screen, then the
coordinates change in the event loop.
Logically the events at the new coordinates
should be associated with the same GUI
object. This logical association can be
accomplished by giving unique names to all
of the GUI objects and providing the unique
names as additional information in the
events in the event loop. The GUI
application reads the next event off of the
event loop, locates the GUI object, and
services the event. The events on the event
loop are usually generated by human
actions such as typing characters, clicking
mouse buttons, and moving the cursor. A
simple modification to the event loop can
journal the events into a file. At a later time,
this file could be used to regenerate the
events, as if the human was present, and
place them on the event loop. The GUI
application will respond accordingly. A
tester, using the GUI, now executes a
scenario. A journal of the GUI event loop
from the scenario is captured. At a later
time the scenario can be repeated again
and again in an automated fashion. The
ability to repeat a test is key to automation
and stress testing.
Stress testing deals with the quality of the
application in the environment. The idea is
to create an environment more demanding
of the application than the application
would experience under normal workloads.
This is the hardest and most complex
category of testing to accomplish and it
requires a joint effort from all teams. A test
environment is established with many
testing stations. At each station, a script is
exercising the system. These scripts are
usually based on the regression suite. More
and more stations are added, all
simultaneous hammering on the system,
until the system breaks. The system is
repaired and the stress test is repeated
until a level of stress is reached that is
higher than expected to be present at a
customer site. Race conditions and memory
leaks are often found under stress testing. A

39
race condition is a conflict between at least
two tests. Each test works correctly when
done in isolation. When the two tests are
run in parallel, one or both of the tests fail.
This is usually due to an incorrectly
managed lock. A memory leak happens
when a test leaves allocated memory
behind and does not correctly return the
memory to the memory allocation scheme.
The test seems to run correctly, but after
being exercised several times, available
memory is reduced until the system fails.
Special methods exist to test non-functional
aspects of interface and interface. In
contrast to functional testing, which
establishes the correct operation of the
interface (correct in that it matches the
expected behavior defined in the design
requirements), non-functional testing
verifies that the interface functions properly
even when it receives invalid or unexpected
inputs. Interface fault injection, in the form
of fuzzing, is an example of non-functional
testing. Non-functional testing, especially
for interface, is designed to establish
whether the device under test can tolerate
invalid or unexpected inputs, thereby
establishing the robustness of input
validation routines as well as error-handling
routines. Various commercial non-
functional testing tools are linked from
the interface fault injection page; there are
also numerous open-source and free
interface tools available that perform non-
functional testing. Performance testing is
executed to determine how fast a system or
sub-system performs under a particular
workload. It can also serve to validate and
verify other quality attributes of the system,
such as scalability, reliability and resource
usage. Load testing is primarily concerned
with testing that can continue to operate
under a specific load, whether that is large
quantities of data or a large number
of users. This is generally referred to as
interface scalability. The related load testing
activity of when performed as a non-
functional activity is often referred to
as endurance testing. Volume testing is a
way to test functionality. Stress testing is a
way to test reliability. Load testing is a way
to test performance. There is little
agreement on what the specific goals of
load testing are. The terms load testing,
performance testing, reliability testing, and
volume testing, are often used
interchangeably. In counterpoint, some
emerging interface disciplines such
as extreme programming and the agile
interface development movement, adhere
to a "test-driven interface development"
model. In this process, unit tests are written
first, by the interface engineers (often
with pair programming in the extreme
programming methodology). Of course
these tests fail initially; as they are expected
to. Then as code is written it passes
incrementally larger portions of the test
suites. The test suites are continuously
updated as new failure conditions and
corner cases are discovered, and they are
integrated with any regression tests that
are developed. Unit tests are maintained
along with the rest of the interface source
code and generally integrated into the build
process (with inherently interactive tests
being relegated to a partially manual build
acceptance process). The ultimate goal of
this test process is to achieve continuous
deployment where interface updates can be
published to the public frequently.

40
Phase 5
Advertisement and Promotion
The last phase of the project is planned
after a long survey and market analysis.
Many analysts were contacted in order to
provide a precise and highly efficient
marketing strategy. Web advertising is the
continuing process to promote a website to
bring more visitors to the website. Many
techniques such as website or interface
content development scenario, search
engine optimization (also known as SEO),
and search engine submission used increase
the traffic to a site. SEO is one of the most
effective ways to promote and increase
traffic on your portal hence it was teams
top priority to exploit SEO on a larger scale.
Search engine optimization (SEO) is the
process of improving the volume or quality
of traffic to a web site or a webpage (such
as a blog) from search engines via "natural"
or one can definitely say un-paid ("organic"
or "algorithmic") search results as opposed
to other forms of search engine
marketing (SEM) which may deal with paid
inclusion. The theory is that the earlier (or
higher) a site appears in the search results
list, the more visitors it will receive from the
search engine. SEO may target different
kinds of search, including image
search, local search, video search and
industry-specific vertical search engines.
This gives a web site web presence. As
an Internet marketing strategy, SEO
considers how search engines work and
what people search for. Optimizing a
website primarily involves editing its
content and HTML and associated coding to
both increase its relevance to specific
keywords and to remove barriers to
the indexing activities of search engines.
The acronym "SEO" can refer to "search
engine optimizers," a term adopted by an
industry of consultants who carry out
optimization projects on behalf of clients,
and by employees who perform SEO
services in-house. Search engine optimizers
may offer SEO as a stand-alone service or as
a part of a broader marketing campaign.
Because effective SEO may require changes
to the HTML source code of a site, SEO
tactics may be incorporated into web
site development anddesign. The term
"search engine friendly" may be used to
describe web site designs, menus, content
management systems, images,
videos, shopping carts, and other elements
that have been optimized for the purpose
of search engine exposure.
Another class of techniques, known as
Social Media Marketing will also be
deployed soon. SMM involves promoting a
business on social networking sites such as
facebook, orkut, twitter etc. which are a
store house of over 700 million potential
users collectively across the globe.
OnScience team was all into the SMM
analysis and optimization.

41
A web marketing strategy for OnScience (figure 6.1)
Strategy planning scenario for the promotion (figure 6.2)

42
The marketing strategy and promotions are
yet to be applied on a real time basis since
the current status of the project puts it
under interface testing phase, i.e. phase IV.
Marketing strategies are wide in nature and
can be taken or deployed with a wide range
of key notes. OnScience is a platform which
will most likely attract user group of
students, researchers, pharmacists, drug
designing firms, bioinformatics research
centers and biotechnology related group,
chemoinformatics department and various
research institutes. People associated with
science in any form will have to do with this
portal and thus will prove its worth at a very
satisfactory level by giving its best.
Result and Discussion
The first three phases of the project were
successfully completed, tested and
implemented on the system centroid. The
project provided the team members an
extraordinary sense of project management
skill and how to handle situations under
tremendous work load when the deadlines
are too steep. Working under the guidance
of mentors from Massachusetts Institute of
Technology, Harvard and other prestigious
institutes gave the team members
enormous amount of courage and a positive
energy to work ahead on the similar
projects ahead in future. The project
development provided the team a sound
knowledge of languages which were used
so far in the development. A lot of
advanced softwares and tools were used to
generate data, design and layouts. The
knowledge was tremendous and will help
all of the members in further assignments.
Currently the interface is put up under the
phase IV, i.e. testing phase where the
testing team is performing widespread test
using various sets of input data and other
data sets applicable. Testing is part which
yields as good result as much as they are
employed in the project. The longer an
interface is put to test; the better is the
output scenario. The fifth phase of the
project is the marketing strategy and
planning the promotion. There is a lot of
analysis yet to be performed on the
marketing part since the testing part will
take almost 2 to 3 months from now on.
Once the interface is ready to be uploaded
there will a marketing strategy implicated
and the product will be on the World Wide
Web. The overall budget involved in the
project till the phase IV completion includes
the cost of hardware and software, cost of
hiring engineers and interns, cost of
building and resources (i.e. electricity and
water), cost of conveyance made, cost of
software testing by commercial
corporations and many more. The project
involved a widespread use of languages and
therefore many experts in different
languages were involved in the project
which produced a great chance for the
naïve developers to have hands on
experience by working with the numero
unos. Overall, it was a great learning
opportunity and lot many lessons were
taken including team work, planning and
strategy development, debugging and most
importantly being a patient learner
throughout the project duration.

43
Future Aspects
OnScience is a project and a step with a
vision, a vision to get into every minds
associated with scientific world. The current
movements are just the seeding of the idea
and a pioneering step. Once the interface is
uploaded on the web there will a lot of
feedback inputs to the server and
comments will be given in order to provide
better scientific information. There are
certain key points which must be seen as a
object of future advancements and
prospects. First, to place before the general
public the grand results of Scientific Work
and Scientific Discovery. Also to urge the
claims of Science to a more general
recognition in Education and in Daily Life.
And, Secondly, to aid scientific men
themselves, by giving early information of
all advances made in any branch of Natural
knowledge throughout the world, and by
affording them an opportunity of discussing
the various Scientific questions which arise
from time to time. There is certain planning
done by the team in order to attain as per
planned:
 Podcasts of the books and journals
can be included
 Scientific videos and animations
 Interactive flash demonstration to
understand biological process
 It will promote a new community of
free lancing scientists ready to offer
their help and consultancy online
 Attractive subscriptions can be
designed with the consideration of
waived charges for students and
learning class of users
 A central resource center with the
combined availability of all the scientific
portals resources and features, e.g.
nature, pubmed central, bioinformation,
cell, swissprot, scribd, YouTube and
many more clubbed together to make
the life easier for life-science
researchers
At the same time new ideologies we must
know that if Public sector corporations are
run with a sole objective to generate
awareness and provide a service to the
public. This service will need to meet the
needs of the less well off in society or help
improve the ability of the economy to
function: e.g. cheap and accessible web
services in future for researchers.
OnScience is having the same motive and
each and every member is deeply
motivated to put forth all they can in order
to make this service of prime importance
for its users and to provide a widespread
awareness of the new and resourceful web
based mantra called OnScience.

44
References
Ajax: the definitive guide, Anthony T. Holdener -
2008 - 957 pages
Apache security, Ivan Ristic - 2005 - 396 pages
Asp: Webster's Quotations, Facts and Phrases,
Inc Icon Group International - 2008 - 73 pages
Beginning PHP and MySQL: from Novice to
Professional, W. Jason Gilmore - 2008 - 1044
pages
DBMS: The complete practical approach, Sharad
Maheshwari, Ruchin Jain - 2005 - 536 pages
Flash 8: projects for learning animation and
interactivity, Rich Shupe, Robert Hoekman -
2006 - 340 pages
Fundamentals of OOP and data structures in
Java, Richard Wiener, Lewis J. Pinson - 2000 -
463 pages
HTML: Complete Concepts and Techniques,
Gary B. Shelly, Denise M. Woods - 2008 - 384
pages
HTML Validation – htmlvalidation.com
JavaScript: the complete reference, Thomas A.
Powell, Fritz Schneider - 2004 - 948 pages
JavaScript: the missing manual, David Sawyer
McFarland - 2008 - 528 pages
PHP for the World Wide Web, Larry Edward
Ullman - 2004 - 450 pages
Pro VB 2008 and the .NET 3.5 Platform, Andrew
Troelsen - 2008 - 1377 pages
Programming PHP, Rasmus Lerdorf, Kevin
Tatroe, Peter MacIntyre - 2006 - 521 pages
Programming ASP.NET, Jesse Liberty, Dan
Hurwitz - 2006 - 930 pages
SQL, the complete reference, James R. Groff,
Paul N. Weinberg - 2002 - 1050 pages
SQL: access to SQL server, Susan Sales Harkins,
Martin W. P. Reid - 2002 - 698 pages
Support Materials for User Interface Develop.,
Gary Perlman, CARNEGIE-MELLON UNIV
PITTSBURGH ... - 1988 - 38 pages
The book of Visual Basic 2005: NET insight for
classic VB developers, Matthew MacDonald -
2006 - 490 pages
The Apache modules book: application
development with Apache, Nick Kew - 2007 -
558 pages
The Flash: the secret of Barry Allen, Geoff
Johns, Howard Porter, Livesay – 2005
User interface development, Gary Perlman,
Carnegie-Mellon University ... - 1989 - 160
pages
Windows multi-DBMS programming: using C++,
Visual Basic, ODBC, Ken North - 1995 - 757
pages
W3SCHOOLS Official Website
XML: Visual QuickStart Guide, Kevin Howard
Goldberg - 2008 - 269 pages

45
The Team
The team members for the project OnScience

Project On-Science

More Related Content

Viewers also liked (19)

Similar to Project On-Science (20)

More from Amrit Ravi (7)

Recently uploaded (20)

Project On-Science