Intelligent Lost and Found System

Using Natural Language Processing

GRADUATE PROJECT REPORT

Submitted to the Faculty of

the Department of Computing Sciences
Texas A&M University-Corpus Christi
Corpus Christi, Texas

In Partial Fulfillment of the Requirements for the Degree of

Master of Science in Computer Science

By

Rahul Yerramsetti
Summer 2018

Committee Members

Dr. Dulal Kar

Committee Chairperson

Dr. Mamta Yadav

Committee Member
 i

ABSTRACT

An Intelligent Lost and Found System is designed and developed in this project
using Natural Language Processing (NLP) techniques to address the problem of
polysemy in it and is implemented as a highly scalable web service. In general, a

Lost and Found system is implemented with the help of human management into it
for correlating the found items with those of the lost ones, as the existing systems
have not yet been developed to correlate the objects automatically on their own due

to the problem of polysemy in the system data records. The existing systems can
only assist humans in managing such a system but cannot implement it completely
on their own. The proposed system is capable enough to handle this problem with

ease and can be implemented without any human effort for managing it. This can
be achieved by using the NLP techniques. When an item is found by an individual,
he/she can report it to the Intelligent Lost and Found system with its complete

details so that it can be handed over to that individual who lost it. The information
of the reported found items is hidden from other users to tackle the problem of
multiple claims for the object. The system also incorporates a design to preserve

the privacy of the user details from other users using it with the help of an efficient
request handling mechanism. When a lost item is reported to the system by an
individual with its complete details, the system finds a match to this lost item from

its repository of found items and vice versa. The matching is done on the basis
of finding ontological relationships among the object names, similarities among the
colors and performing Semantic analysis using NLP techniques on their descriptions

to obtain various properties about them. When a good match is found the individuals
are communicated about it through their mails.
 ii

TABLE OF CONTENTS

CHAPTER Page

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Background and Rationale . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Software Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Natural-language processing . . . . . . . . . . . . . . . . . . . 5
1.2.2 Latent Semantic analysis . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Topic modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4 Latent Dirichlet allocation . . . . . . . . . . . . . . . . . . . . 7
1.2.5 Crowdsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.6 Message-oriented middleware . . . . . . . . . . . . . . . . . . . 8
1.2.7 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.8 Hibernate ORM Framework . . . . . . . . . . . . . . . . . . . . 9

2 NARRATIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 SYSTEM DESIGN AND ARCHITECTURE . . . . . . . . . . . . . . . . 14

3.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Database (MySQL) . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Back-End (Java-subsystem) . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Front-End (Web-pages) . . . . . . . . . . . . . . . . . . . . . . 16
 iii

CHAPTER Page

3.2.4 Message-oriented middleware . . . . . . . . . . . . . . . . . . . 17

3.2.5 NLP Python-Subsystem (NLTK) . . . . . . . . . . . . . . . . . 17
3.3 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Work-flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Tools Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Code Templates/Snippets . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Controller Class . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2 Service Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3 DAO Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.4 Entity Mapping Class . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.5 RPC via Middle-ware Class . . . . . . . . . . . . . . . . . . . . 35

5 TESTING AND RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6 CONCLUSION AND FUTURE ENHANCEMENTS . . . . . . . . . . . . 59

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
 iv

LIST OF TABLES

TABLE Page

1 A survey on User Experience . . . . . . . . . . . . . . . . . . . . . . 58

 v

LIST OF FIGURES

FIGURE Page

1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Use Case Diagram for Intelligent Lost and Found System . . . . . . . 18

3 Class Diagram for Intelligent Lost and Found System . . . . . . . . . 20

4 Work-flow diagram for Lost Item Entry. . . . . . . . . . . . . . . . . 23

5 Work-flow diagram for Found Item Entry. . . . . . . . . . . . . . . . 25

6 Work-flow diagram for Claiming Found Record from Matching list . . 26

7 Work-flow diagram for Dealing with Claim Requests . . . . . . . . . 27

8 Sample code snippet of the Controller Class . . . . . . . . . . . . . . 30

9 Sample code snippet of a Service layer interface . . . . . . . . . . . . 31

10 Sample code snippet of a Service class . . . . . . . . . . . . . . . . . 32

11 Sample code snippet of a DAO interface . . . . . . . . . . . . . . . . 33

12 Sample code snippet of a DAO class . . . . . . . . . . . . . . . . . . 33

13 Code snippet of a Entity Mapping class . . . . . . . . . . . . . . . . 35

14 Code snippet implementing the RPC message pattern on a Java client 36

15 User Interface for Home Page of the application . . . . . . . . . . . . 37

16 Scenario of Reporting a Found item into the system (Case: 1) . . . . 38

17 Processing of the submitted Found Record Details (Case: 1) . . . . . 39

18 Confirmation Page with Tracking ID . . . . . . . . . . . . . . . . . . 39

19 Confirmation email with Tracking ID . . . . . . . . . . . . . . . . . . 40

 vi

FIGURE Page

20 Scenario of Reporting a Lost item into the system . . . . . . . . . . . 40

21 Processing of the submitted Lost Record Details . . . . . . . . . . . . 41

22 Confirmation email with Tracking ID . . . . . . . . . . . . . . . . . . 41

23 Confirmation Page with a Matching Result . . . . . . . . . . . . . . 42

24 Details of the Found Item (Case: 1) . . . . . . . . . . . . . . . . . . 43

25 Scenario of Reporting another Found item into the system (Case: 2) 43

26 Processing of the submitted Found Record Details . . . . . . . . . . 44

27 Confirmation Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

28 Confirmation email with Tracking ID . . . . . . . . . . . . . . . . . . 45

29 Email notification to similar Lost record user . . . . . . . . . . . . . 45

30 Scenario of Reporting another Found item into the system (Case: 3) 46

31 Processing of the submitted Found Record Details . . . . . . . . . . 46

32 Confirmation Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

33 Confirmation email with Tracking ID . . . . . . . . . . . . . . . . . . 47

34 Details of the Found item (case: 3) . . . . . . . . . . . . . . . . . . . 48

35 Tracking of Lost item status to View Found Matches . . . . . . . . . 48

36 Lost Item Tracking details and Navigation . . . . . . . . . . . . . . . 49

37 Details of the tracked Lost Item . . . . . . . . . . . . . . . . . . . . . 49

38 Viewing Found Matches . . . . . . . . . . . . . . . . . . . . . . . . . 50

39 Found Item Details (Case: 1) . . . . . . . . . . . . . . . . . . . . . . 51

40 Found Item Details (Case: 2) . . . . . . . . . . . . . . . . . . . . . . 51

 vii

FIGURE Page

41 Claiming the Found Item . . . . . . . . . . . . . . . . . . . . . . . . 52

42 Email Notification to Found item user about new Claim . . . . . . . 52

43 Tracking of Found Item status to view the claim . . . . . . . . . . . 53

44 Found Item Tracking Navigation Screen . . . . . . . . . . . . . . . . 53

45 Details of the Current Found Item . . . . . . . . . . . . . . . . . . . 54

46 Viewing claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

47 Details of the claimer’s lost record . . . . . . . . . . . . . . . . . . . 55

48 Claim Accepted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

49 Contact Details of Lost Item user shared with Found Item user . . . 56

50 Contact Details of Found item user shared with Lost Item user . . . 56
 1

CHAPTER 1

INTRODUCTION
Many valuable items are lost by people in their day to day life, which are
found by someone else. Though, they are interested in returning the found items to

the appropriate owners there is no such mechanism to facilitate this. To build and
establish such a system to the open public would require lot of costs in employing
people for its maintenance. The Intelligent Lost and Found system is a solution to

deal with these situations in a cost effective and accurate way. The Intelligent Lost
and Found system is a Web Service which can relate a found item to a lost item that
is reported to the system using Natural Language Processing techniques without any

human intervention into it. This is a complete automatic system and is designed to
provide privacy to the user details in it.

1.1 Background and Rationale

The current Lost and Found systems are being maintained at organizational

levels with human workforce involved in managing it. Most of the items can’t be
properly related or found in a timely manner when organization levels are huge.
These include places like Airports, Theme parks, Shopping malls, Universities, Public

Transportation Services etc. Many of these items which were unclaimed are never
reported to be lost and are sold in huge auctions by these organizations. Below are
the details about how it is implemented across various organizational levels.

(i) Airports and Airlines:

The Lost and Found Systems are maintained at various airports and almost by
all the airlines. They collect the lost items by the passengers in the airports
 2

and store them so that they can be handed over to those passengers who lost
them upon their claims. This service is maintained by sorting and categorizing

the items found by the authorities manually. This manual sorting again can
also cause ambiguity as it is person specific to classify the item. Although they
might have an web interface to the world it satisfies only the communication

needs of the system. These systems are not capable enough to automate this
process. There are many challenges and issues face when implementing these
services. It is a challenging job for the authorities to communicate about the

lost items with passengers from different parts of the world. It involves lot of
time constraints, as all these items needs to be sorted and identified manually,
in the meanwhile the passengers might need to leave the place to catch their

flights to reach their destination. Therefore, the processing time is a crucial

factor in this scenario.

(ii) Theme Parks:

Theme Parks also maintain lost and found services at massive scale. Many
items are lost by public in the theme parks. These are collected and maintained
by them for about 30 days, which are later sold in auctions. The biggest

problem in this scenario is maintaining such huge system. The major problem
lies in its effective identification of its properties during its recognition which is
done manually. In this process many fine distinguishing features of the items

are overlooked, in-turn which again cause further delays during the claiming
process of the object. This is crucial because there can be similar items that

are lost but may have very fine distinguishing characters between them. The
persons sorting and categorizing these may not have an idea on the already
existing objects in the entire system.
 3

(iii) Public Services:

Public Services like Metro Bus and Rail services etc also maintain Lost and
Found Systems. Many commuters forget their things during their travel, these
items are safely stored and managed so that they can be given to the people

who lost them. The challenge in this scenario is collection of the lost items and
its features identification to sort it.

(iv) Offices and Educational Institutions:

Many Private and Public Offices, Schools, Universities also implement these
lost and found services at their organizational level. The challenge in these
scenarios is maintaining communication across its organization to maintain this

system. To face this challenge these systems are decentralized at departmental

levels. So at times it could be hard for the user to know where his lost item
was found. Handling Multiple claims about a found object is another challenge

in this scenario.

(v) Available Crowd Sourced Applications:

One of the most popular available crowd sourced application for Lost and Found

System is Craigslist. It is a web application which can be used to communicate

to people as a social media application about their lost or found items. There
is no privacy provided in this system. The contact details of the users open to

the public. This system is general used to report lost pets. There are many
other such similar applications having the problems like lack of privacy to the
user details and multiple claims. Most of these systems work on the principle

of categorization of the reported object to a class manually. This can in-turn

cause ambiguity during categorization as it is person specific and not bound
 4

by any rules.

To overcome the above mentioned problems at various organizational levels,

the Lost and Found Systems can be automated with the help of Natural Language

Understanding and crowd-sourcing. This opens the service for use to the open public
rather than an organizational implementation there by expanding its scope of usage.
It could provide fast and accurate results in relating objects and can also handle

large volume of objects and regions. The maintenance of such system would be easy
and cost effective.
The proposed system does this using Natural Language Processing (NLP).

Natural language Processing [6] helps the system in understanding the actual mean-
ing of the textual data given by the users. This in-turn helps in correlating the lost
and found object together based on their relativeness in object names, descriptions,

time, locations etc. Ontological mapping [1] is applied on the object names to iden-
tify their object roots, semantic analysis [5] is done on the descriptions entered by
the users to identify their properties of the objects and correlate them together.

The Natural Language Processing System is implemented using Python pro-

gramming language to utilize the rich NLTK library for Natural Language Process-
ing. The remaining part of the system is developed in Java using the Spring MVC,

Hibernate ORM Frameworks to implement the system as a web service by utilizing

the advantages of Dependency Injection, Aspect Oriented Programing and Object

Relational Mapping offered by them. The Java based system is connected to the
Python based NLP system using a Message-oriented middleware technology [4] Rab-
bitMQ which further makes the system more scalable. The database is maintained

using MySQL and is connected using the Hibernate ORM framework.

 5

1.2 Software Literature

1.2.1 Natural-language processing

Natural-language processing (NLP) [10] is an area of computer science and

artificial intelligence concerned with the interactions between computers and hu-
man (natural) languages. In particular it is concerned with programming computers

to efficiently process and analyze large amounts of natural language data. Chal-
lenges in natural-language processing involve speech recognition, natural-language
understanding, and natural-language generation. In this project we concentrate on

natural-language understanding. It deals with machine reading comprehension. Nat-

ural language understanding is considered an AI-hard problem. It involves converting
chunks of text into more formal representations such as first-order logic structures

that are easier for computer programs to manipulate. Natural-language understand-

ing involves the identification of the intended semantic of a word or a phrase out of the
multiple possible semantics. There is considerable commercial interest in this field

because of its application to news-gathering, text categorization, voice-activation,

archiving, and large-scale content analysis.

1.2.2 Latent Semantic analysis

Latent semantic analysis (LSA) [7] is a technique in natural language process-

ing, in particular distributional semantics, of analyzing relationships between a set

of documents and the terms they contain by producing a set of concepts related to
the documents and terms. LSA assumes that words that are close in meaning will
occur in similar pieces of text (the distributional hypothesis). A matrix containing

word counts per paragraph (rows represent unique words and columns represent each
 6

paragraph) is constructed from a large piece of text and a mathematical technique

called singular value decomposition (SVD) is used to reduce the number of rows

while preserving the similarity structure among columns. Words are then compared
by taking the cosine of the angle between the two vectors (or the dot product between
the normalizations of the two vectors) formed by any two rows. Values close to 1

represent very similar words while values close to 0 represent very dissimilar words.

1.2.3 Topic modeling

In machine learning and natural language processing, a topic model [1] is a

type of statistical model for discovering the abstract topics that occur in a collection
of documents. Topic modeling is a frequently used text-mining tool for discovery
of hidden semantic structures in a text body. Intuitively, given that a document

is about a particular topic, one would expect particular words to appear in the
document more or less frequently: ”dog” and ”bone” will appear more often in
documents about dogs, ”cat” and ”meow” will appear in documents about cats, and

”the” and ”is” will appear equally in both. A document typically concerns multiple
topics in different proportions; thus, in a document that is 10 percent about cats

and 90 percent about dogs, there would probably be about 9 times more dog words
than cat words. The ”topics” produced by topic modeling techniques are clusters of
similar words [2]. A topic model captures this intuition in a mathematical framework,

which allows examining a set of documents and discovering, based on the statistics
of the words in each, what the topics might be and what each document’s balance
of topics is.

Topic models are also referred to as probabilistic topic models, which refers to
statistical algorithms for discovering the latent semantic structures of an extensive
 7

text body. In the age of information, the amount of the written material we encounter
each day is simply beyond our processing capacity. Topic models can help to organize

and offer insights for us to understand large collections of unstructured text bodies.
Originally developed as a text-mining tool, topic models have been used to detect
instructive structures in data such as genetic information, images, and networks.

1.2.4 Latent Dirichlet allocation

In natural language processing, Latent Dirichlet allocation (LDA) [1] is a

generative statistical model that allows sets of observations to be explained by un-

observed groups that explain why some parts of the data are similar. For example,
if observations are words collected into documents, it posits that each document is
a mixture of a small number of topics and that each word’s creation is attributable

to one of the document’s topics. LDA is an example of a topic model and was first
presented as a graphical model for topic discovery by David Blei, Andrew Ng, and
Michael I. Jordan in 2003.

In LDA, each document may be viewed as a mixture of various topics where

each document is considered to have a set of topics [3] that are assigned to it via

LDA. This is identical to probabilistic latent semantic analysis (pLSA), except that
in LDA the topic distribution is assumed to have a sparse Dirichlet prior. The sparse
Dirichlet priors encode the intuition that documents cover only a small set of topics

and that topics use only a small set of words frequently. In practice, this results
in a better disambiguation of words and a more precise assignment of documents
to topics. LDA is a generalization of the pLSA model, which is equivalent to LDA

under a uniform Dirichlet prior distribution.

 8

1.2.5 Crowdsourcing

Crowdsourcing is a sourcing model in which individuals or organizations ob-

tain goods and services, including ideas and finances, from a large, relatively open
and often rapidly-evolving group of Internet users; it divides work between partici-

pants to achieve a cumulative result.

1.2.6 Message-oriented middleware

Message-oriented middleware (MOM) [4] is software or hardware infrastruc-

ture supporting sending and receiving messages between distributed systems. MOM
allows application modules to be distributed over heterogeneous platforms and re-
duces the complexity of developing applications that span multiple operating systems

and network protocols. The middleware creates a distributed communications layer

that insulates the application developer from the details of the various operating
systems and network interfaces. APIs that extend across diverse platforms and net-

works are typically provided by MOM. MOM provides software elements that reside
in all communicating components of a client/server architecture and typically sup-
port asynchronous calls between the client and server applications. MOM reduces

the involvement of application developers with the complexity of the master-slave

nature of the client/server mechanism.
The main reasons for using a message-based communications protocol include

its ability to store (buffer), route, or transform messages while conveying them from
senders to receivers. Another advantage of messaging provider mediated messaging
between clients is that by adding an administrative interface, you can monitor and

tune performance. Client applications are thus effectively relieved of every problem
except that of sending, receiving, and processing messages. It is up to the code
 9

that implements the MOM system and up to the administrator to resolve issues like
interoperability, reliability, security, scalability, and performance.

1.2.7 Spring Framework

The Spring Framework is an application framework and inversion of control

container for the Java platform. The framework’s core features can be used by any

Java application, but there are extensions for building web applications on top of the
Java EE (Enterprise Edition) platform. Although the framework does not impose
any specific programming model, it has become popular in the Java community as

an addition to, or even replacement for the Enterprise JavaBeans (EJB) model. The
Spring Framework is open source.
Central to the Spring Framework is its inversion of control (IoC) container,

which provides a consistent means of configuring and managing Java objects using
reflection. The container is responsible for managing object lifecycles of specific
objects: creating these objects, calling their initialization methods, and configuring

these objects by wiring them together.

Objects can be obtained by means of either dependency lookup or dependency

injection. Dependency lookup is a pattern where a caller asks the container object
for an object with a specific name or of a specific type. Dependency injection is
a pattern where the container passes objects by name to other objects, via either

constructors, properties, or factory methods.

1.2.8 Hibernate ORM Framework

Hibernate ORM is an object-relational mapping tool for the Java program-

ming language. It provides a framework for mapping an object-oriented domain

 10

model to a relational database. Hibernate handles object-relational impedance mis-

match problems by replacing direct, persistent database accesses with high-level

object handling functions.

Hibernate is free software that is distributed under the GNU Lesser General
Public License 2.1. Hibernate’s primary feature is mapping from Java classes to

database tables, and mapping from Java data types to SQL data types. Hibernate
also provides data query and retrieval facilities. It generates SQL calls and relieves
the developer from the manual handling and object conversion of the result set.
 11

CHAPTER 2

NARRATIVE
2.1 Problem statement

Many objects are lost and found by people on a daily basis. Implementing an

efficient lost and found system is a tough challenge to organizations as they require
human effort to classify and relate the lost item with an found item. The existing
software systems can’t handle this all alone due to the problem of polysemy in data

records of the objects. The people who report lost objects to the system may use a
different words to describe them and the person who found it may use some other
terminology to identify the same object. The existing software systems are not

adequate enough to handle this problem that raised due to polysemy. This problem
of polysemy cannot be completely solved even with the intervention of humans into
the systems. In general Lost and Found Systems are implemented using the principle

of categorization. The humans find the correlation and categorization a difficult task
and ambiguous though the existing software systems are used. Therefore, a complete
automatic Intelligent Lost and Found System is build in this project to handle these

situation.

2.2 Motivation

Items are lost and found by people in their daily life. Among these, there
can be objects of greater significance like certificates, memories, other valuables

etc. Though people who find these objects wants to return them there is no proper
mechanism to facilitate this accurately with privacy. This project has been designed
to serve as a medium to facilitate this need.
 12

2.3 Objective

The main objectives in building such a system that can understand the natural

language semantics and interact as a web-service are making the system modularized,
scalable, facilitate cross platform integration of the system components. The design
involves cross platform communications among various components of the system

between Java and Python. At the component level we have the challenge of building
an ontological root relating system among the items, getting the proper contextual
meaning of the descriptions using semantic analysis and topic modeling, establishing

other spatial-temporal correlations among the data records on properties like loca-
tion, time, date, colour etc. The next level of challenge involves in implementing the
NLP system in Python (due to the rich available NLTK library) and its integration

with the Java-based systems (to resolve the issues of high scalability, modularization,
security and ease in project maintenance) on a webserver. The other main challenge
which we need to address in this project is to get precise correlation search results

along with privacy to the user details.

2.4 Scope

The effort involved in designing this project is a kind of new step into building

a commercially scalable cloud based Natural Language Understanding systems. The

main theme is building systems that could better understand the human words.
In specific this project has a lot of significance when commercialized into cloud-

based pay as you use model software. It can be used by various Airports around
the world, Airline Companies, Cruise Ships, Rental Cars, Theme Parks like Disney,
Metro Transport services, Schools and Universities, Offices and in many public places.
 13

All this could be implemented with least cost and very little human effort.
 14

CHAPTER 3

SYSTEM DESIGN AND ARCHITECTURE

3.1 System Architecture

The system architecture is designed keeping in view of making the system

modularized, scalable and facilitating cross platform integration of components be-

tween Java and Python subsystems.
Modern Java Frameworks such as Spring MVC and Hibernate ORM are used

to implement MVC architecture, Inversion of Control using Dependency Injection,

Aspect Oriented Programming and O/R Mappings in the system design. Using these
frameworks we can achieve a good modularized and easy to maintain system design.

Figure 1: System Architecture.

Message-oriented middleware like RabbitMQ is used for cross platform in-

tegration of system components. This enables the Java components in the system

to communicate with the Python components in a synchronized message queuing

patterns.
 15

3.2 System Components

The entire system is made of five main components as follows:

3.2.1 Database (MySQL)

MySQL database is used for storing information records of the users. Using
a secure DAO(Data Access Object) layer the information is communicated in both

directions with application with the help an Object-relational mapping (ORM) tool
hibernate.

3.2.2 Back-End (Java-subsystem)

The Back-End part of the application is implemented on Apache Tomcat

server and is developed usign Java based Spring MVC and Hibernate ORM Frame-
works. The Spring Model-View-Controller (MVC) framework is designed around a

DispatcherServlet that dispatches requests to handlers, with configurable handler

mappings, view resolution, locale and theme resolution as well as support for up-
loading files. The DispatcherServlet is the key componenet that facilitates the spring

framework to implement the concept of Dependency Injection to achieve a modular-

ized design of the application. The default handler is based on the @Controller and
@RequestMapping annotations, offering a wide range of flexible handling methods.

A key design principle in Spring MVC is the Open for extension, closed for modi-
fication principle. High flexible data-binding is offered by spring. This framework
consists of three main components: a Controller, a Model Map and a ViewResolver.

Objects form the backbone of a application in Spring and are managed by the Spring
IoC (Inversion of Control) container are called Beans. In Spring Framework, a Bean
is an object that is managed (instantiated, assembled) and maintained by a Spring
 16

IoC container. Spring Beans are defined using a Spring configuration file or by an-
notations, instantiated by the Spring container and are injected into the application.

Spring Beans need not to be Java Beans always. Compared to Java Beans, Spring
Beans may not implement java.io.Serializable Interface and can have arguments in
constructor etc.

Spring’s view resolution is extremely flexible. A Controller is typically re-

sponsible for preparing a model Map with data and selecting a view name and it
can also write directly to the response stream and complete the request. View name

resolution is highly configurable through file extension or Accept header content type
negotiation, through Bean names, properties file, or even a custom ViewResolver im-
plementation. The model (the M in MVC) is a Map interface, which allows for the

complete abstraction of the view technology. You can integrate directly with tem-
plate based rendering technologies such as JSP, Velocity and Freemarker, or directly

generate XML, JSON, Atom, and many other types of content. The model Map is
simply transformed into an appropriate format, such as JSP request attributes, a
Velocity template model etc.

3.2.3 Front-End (Web-pages)

The Front-End part of the application is a client side web-interface. It is built

using JSP, JavaScript, JSTL and other technologies. It represents the ViewResolver

layer in MVC architecture. It incorporates typical validation expressions to check

and assist the user in filling various forms in the application.
 17

3.2.4 Message-oriented middleware

The RabbitMQ is used as a Message-oriented middleware in this application.

It plays an crucial role in cross platform integration of the Java based back-end
system with the Python-subsystem that consists of the NLP implementations in a

synchronized message queuing pattern.

It uses the Advanced Message Queuing Protocol (AMQP) for communica-
tion with other components of the system. It works on the mechanism of Remote

Procedure Calls (RPC). The defining features of AMQP [4] are message orientation,
queuing, routing (including point-to-point and publish-and-subscribe), reliability and
security. It is a wire-level protocol. A wire-level protocol is a description of the for-

mat of the data that is sent across the network as a stream of bytes. Consequently,
any tool that can create and interpret messages that conform to this data format can
inter-operate with any other compliant tool irrespective of implementation language.

3.2.5 NLP Python-Subsystem (NLTK)

This component of the system is also implemented on the server and is com-
municated with the Java Back-end System with the help of RabbitMQ MOM. This

component houses the real power of resolving the polysemy problem in the applica-
tion. It uses advanced NLP techniques like Latent Semantic analysis, Named Entity
Recognition, Parts of Speech Tagging (POS) [9] [8], etc for processing information

given by the user to obtain its inner meaning. We have used the Natural Language
Toolkit (NLTK 3) library for implementing the NLP Subsystem. It contains over
50 corpora and lexical resources such as WordNet, along with a suite of text pro-

cessing libraries for classification, tokenization, stemming, tagging, parsing, semantic

reasoning, etc.
 18

3.3 System Design

Unified Modelling Language is used to represent the design of the system

software. The main aim of the UML diagrams is to help users understand about
interaction between different components of the application.

3.3.1 Use Case Diagram

Use case diagram consists of the actors and the use cases. Actor represents

the role played by the user or any external system whereas the use cases describe the
functionality of the application.
Figure 2 shows the use case diagram for the Lost and Found System. It

consists of two actors i.e., Lost Item User and Found Item User. It is made up of
six use cases Search Lost Item, Search Found Item, Report Lost Item, Report Found
Item, Claim Match Item and Accept Request.

Figure 2: Use Case Diagram for Intelligent Lost and Found System.

1. Search Lost Item: This use case represents the actions of searching and retriev-
ing the details of the queried Lost Record.
 19

2. Search Found Item: This use case represents the actions of searching and re-
trieving the details of the queried Found Record.

3. Report Lost Item: This use case represents the actions of saving the Lost record

and then matching it with the relevant Found Records using the designed NLP
based mechanism in the database.

4. Report Found Item: This use case represents the actions of saving the Found
record and then matching it with the relevant Lost Records using the designed
NLP based mechanism in the database.

5. Claim Match Item: This use case represents the action of claiming a matched
Found item by the Lost Item user. This claim appears as a request to the

Found Item User which he/she can accept or decline it.

6. Accept Request: This use case represents the action of Accepting or Declining
the Claim Request by the Found Item User. If user Accepts the claim request,
the contact details of Requester are exchanged with Accepting User through

email. If the Request is Declined No Contact details will be exchanged.

3.3.2 Class Diagram

The relationship between different classes and objects can be shown using a

class diagram. The arrows are used to illustrate the relationship between different
classes.
Figure. 3 shows the Class Diagram for the Intelligent Lost and Found System.

As the system is built using the Spring MVC and Hibernate ORM Frameworks
we have a three layered Class Diagram which includes the Presentation Layer, the
Service Layer and the Persistence Layer.
 20

Figure 3: Class Diagram for Intelligent Lost and Found System.

1. Presentation Layer:

This layer consists of the controllers that handles the incoming requests and

dispatches replies accordingly. In this architecture this layer consists of two

classes the Controller and the Rest Controller.

The Controller Class is the Classic controller which is annotated with the

@Controller annotation and is simply a specialization of the @Component class

and allows implementation classes to be autodetected through classpath scan-
ning. @Controller is typically used in combination with a @RequestMapping

annotation which is used for request handling methods. The request handling
method is annotated with @ResponseBody. This annotation enables automatic
serialization of the return object into the HttpResponse. The Controller class

acts as a classic Spring MVC handler to the basic Lost and Found web appli-
cation with JSP’s as view components.

The RestController class is a special simplified version of the controller. It

 21

includes the @Controller and @ResponseBody annotations and as a result,

simplifies the controller implementation. This controller is annotated with

the @RestController annotation, therefore the @ResponseBody isnt required.

Every request handling method of the controller class automatically serializes
return objects into HttpResponse. The RestController class acts a request

handler to the application that outputs its response as JSON or XML objects.

2. Service Layer:

The Service Layer Consists of the classes that hold the business logic of the

application. They act as mediating logic layer between the Controller and the
Data Repository. Here in this application we have a LostServiceImpl, Found-
ServiceImpl Classes which has methods that can fetch, save, perform matching

based on the system design principles using NLP in the application. They in-
tegrate with a NLP based Python subsystem system using a Message-oriented
middle-ware (RabbitMQ) for cross platform communication. The ReqServi-

ceImpl class has all the methods that deal with item claiming and information
dissipation for establishing a communication link between Lost Item user and a
Found Item User safeguarding privacy and security of the users in the systems.

3. Persistence Layer:

The Persistence Layer consists of all the classes that enable communication
between the application and the Database. It deals with storing and retrieving

data from a database. It consists of the DAO (Data Access Object) classes
that provides access to the database operations and Entity classes that fa-
cilitate Object Relational Mapping. The DAO classes handles the database

operation required to manipulate entity or object and the Entity classes map
 22

these Java Objects to database tables. This Persistence layer is responsible

for Persisting the POJO (Plain Old Java Objects) objects which are avail-

able to the service layer for processing. Here in this application Hibernate
ORM framework is used as a persistence provider.The LostDAO, FoundDAO,
ReqHandlDAO Classes in this layer provide access to database operations on

Lost, Found and Request tables in the database. The entity classes LostEntity,
FoundEntity and ReqEnitity map Java Objects with Lost, Found and Request
tables in the database. They consists of the Mappings, default constructors

and getter, setter methods for the attributes.

4. NLP Class:

This class is written in Python to utilize the benefit of NLTK(Natural Language

Toolkit) for natural language processing, achieve faster load free synchronized
execution via a Message-oriented middleware (MOM) like RabbitMQ. Various
NLP operations are applied on texts to obtain the root meaning of the item-

names (thereby avoiding the problem of polysemy) and extract properties of

the item mentioned by the user without ambiguity in the semantics of the
text. Various NLP techniques like Text cleaning, Lemitization, Stemming,

Spell Corrections, Topic Modeling, POS tagging( parts of speech tagging) and
NER (Named Entity Recognition) are used for analyzing text and extracting

their semantics. This class also contains the RPC functions to communicate
with the Java subsystem via MOM RabbitMQ using a Request/reply pattern.
 23

3.4 Work-flow

In this section, we explore the work-flow of the Intelligent Lost and Found

application. A workflow diagram depicts a series of steps/actions that define a job

or how work should be done, usually represented through a flowchart. A workflow
diagram visualizes how tasks will flow between resources, whether they’re machines

or people and what conditions allow the sequence to move forward. There are four
different work-flow paths in this project and they are discussed as follows.

(a) Lost Item Entry:

In this case we explore the workflow for saving a Lost Item record by a Lost
Item user (referred as the user in this case). The Lost Item user enters the lost
item record using the lost item form web-page.

Figure 4: Work-flow diagram for Lost Item Entry.

This data is stored in a lost item table and the user is notified about successful
saving of the record in the system through an email. He/She will be issued
 24

an Tracking ID through email once the record is successfully saved. Next, the
system performs a similarity matching of this lost item record with the found

item records in the database using Natural Language Processing, Ontology

mapping, color matching, etc., in the above specified fashion. It follows a
weighting schema for prioritizing the search results. The system displays the

matching results if any such similar found records existed in the system. The
user can view the details of the matching found records result list if any existed.
It is not recommended to claim for the object unless until the user finds an

legitimate match to his record as the found user who receives this request can
decline it and the user cannot claim another object if a more satisfying result
is found. He/She will be able to place the claim again either only after the

found user declines his/her claim or wait for other three days. Therefore, it is
advisable to wait for a week (depending upon how fast the lost item is reported

to the system) or so and claim the object using the tracking module. The user
will be notified through email when when a matching found record is entered
into system. He can view its details by using the tracking section with his ID.

He/She can view the matches in the tracking section and claim it if his/her lost
item appears to be found. The user will be notified about the status of his/her
claim record through email. If the Claim is accepted the contact details of the

Lost Item user will be exchanged with the Found Item user.

(b) Found Item Entry:

In this case we explore the workflow for saving a Found Item record by a Found

Item user (referred as the user in this case) . The Found Item user enters the
Found item record using the found item form web-page.
 25

Figure 5: Work-flow diagram for Found Item Entry.

This data is stored in a found item table and user is notified about the successful
saving of the record in the system through an email. He/She will be issued
an Tracking ID through email once the record is successfully saved. Next, the

system performs a similarity matching of this found item record with the lost
item records in the database using Natural Language Processing, Ontology
mapping, color matching, etc., in the above specified fashion. It follows a

weighting schema for prioritizing the search results. If any matching similar
lost records are found, the system then sends emails to matching Lost record
users. The Found Item user receives email when some lost item user claims

their object. The Found Item user can view these claim request using the
tracking system with the help of his ID. The user then examines the lost item

record of the claimer and accepts the request if it is legitimate or else declines
it. If the Claim is accepted the contact details of the Found Item user will be
exchanged with the Lost Item user.
 26

(c) Claiming Found Record from Matching list:

Figure 6: Work-flow diagram for Claiming Found Record from Matching list.

In this case we explore the workflow for Claiming Found Record from Matching
list by a Lost Item user (referred as the user in this case) . When a Lost Item
user receives email about a new match being found, he/she opens the tracking

system and enter his/her Tracking ID to view the Found Matching records.
The user examines each found record in detail and claims it if finds that it is
his/her lost item. A claim request will be placed by him/her to the Found Item

user. When the Found Item user accepts this request the contact details of the
Lost Item user will be exchanged with the Found Item user.
 27

(d) Dealing with Claim Requests:

Figure 7: Work-flow diagram for Dealing with Claim Requests.

In this case we explore the workflow for Dealing with Claim Requests by a
Found Item user (referred as the user in this case) . When a Found Item user

receives email about a new claim request placed he opens the tracking system
and enter his Tracking ID to view the Claim requests. The user then examines
the lost item record of the claimer and accepts the request if it is legitimate or

else declines it. If the Claim is accepted the contact details of the Found Item
user will be exchanged with the Lost Item user.
 28

CHAPTER 4

IMPLEMENTATION
4.1 Tools Used

The system is implemented using Java and Python Languages. RabbitMQ

Message-oriented middle-ware is used to communicate between both these subsys-

tems. The following are software tools and requirements used for developing this
project.

(a) IDE: NetBeans, Spyder;

(b) Database: MySQL;

(c) Platform: Java EE, Python, Erlang;

(d) Frameworks: Spring Framework, Hibernate Framework;

(e) Web Technologies: JavaScript, jQuery, CSS, Bootstrap, XML, JSTL, HTML;

(f) NLP Libraries: NLTK;

(g) Server: Apache Tomcat;

(h) Message-oriented middle-ware: RabbitMQ;

(i) Browser: Mozilla Firefox;

4.2 Code Templates/Snippets

The Spring Web MVC framework provides Model-View-Controller (MVC) ar-

chitecture and ready components that can be used to develop flexible and loosely
 29

coupled web applications. The MVC pattern results in separating the different as-
pects of the application (input logic, business logic, and UI logic), while providing a

loose coupling between these elements.

• The Model encapsulates the application data and in general, they will consist
of POJO.

• The View is responsible for rendering the model data and in general it generates
HTML output that the client’s browser can interpret.

• The Controller is responsible for processing user requests and building an ap-

propriate model and passes it to the view for rendering.

The Spring Web model-view-controller (MVC) framework is designed around

a DispatcherServlet that handles all the HTTP requests and responses. On Recieve-
ing an incoming HTTP request the DispatcherServlet consults the HandlerMapping
to call the appropriate Controller. The Controller takes the request and calls the

appropriate service methods based on used GET or POST method. The service
method will set model data based on defined business logic and returns view name
to the DispatcherServlet. The DispatcherServlet will take help from ViewResolver to

pickup the defined view for the request.Once view is finalized, the DispatcherServlet
passes the model data to the View which is finally rendered on the browser.
The code templates of the main structural components explaining the concept

of Dependency Injection which have been implemented in this project are discussed
below.
 30

4.2.1 Controller Class

The Controller class is responsible for processing the user requests, building

an appropriate model and passing it to the view component for rendering.

Below Figure 8 is a code snippet (part of it) of the controller class used in

this application. The @Controller annotation defines the class as a Spring MVC con-
troller. Here, the first usage of @RequestMapping indicates that all handling methods
on this controller are relative to the /lnfbase path. Next annotation @RequestMap-

ping is responsible for handing the /showsortedcases path call by implementing the
CustomersCases method. We inject the Statservice to this controller class using the
@Autowired annotation. This annotation allows Spring to resolve and inject collab-

orating Beans into your Bean. Next we get the Sorted Cases from the StatService
class, which is added to the model and forwarded to the view component.

Figure 8: Sample code snippet of the Controller Class.

 31

4.2.2 Service Class

The Service layer contains all the business logic of the application. The Ser-

vice layer consists of an interface and its implementing class that contains various
methods which define the services offered by the application. This layer implements

a Service Facade design pattern into the application architecture. This design helps
to address the problem of coupling the core service logic to contracts and implemen-
tation resources that inhibit its evolution and negatively impact service consumers.

This is achieved by treating each service as an independent product and is deployed

as an isolated package which contributes to service autonomy. In this way it acts
as an Intermediate layer for custom business logic. It is also used to integrate data

from multiple sources (DAO/repositories). The annotation @Service is used to mark

the class as a service provider. Spring context will autodetect these classes when
component scanning is done. In Figure 9, a code snippet of the Service interface

StatService is defined and is implemented in Figure 10 by a Service class StatSer-

viceImpl. In Figure 10, @Service annotation is used to mark StatServiceImpl as a
Service class, the next annotation @Autowired is used to inject the DAO layer class

StatDAOImpl. The @Transactional annotation later used enables the transactional

support i.e., it automatically begins and end a transaction for your Hibernate code,
without the need for explicitly doing this in the code.

Figure 9: Sample code snippet of a Service layer interface.

 32

Figure 10: Sample code snippet of a Service class.

4.2.3 DAO Class

The DAO (Data Access Object) class is responsible for interacting with un-
derlying Database. Our DAO needs a Hibernate SessionFactory to communicate to
the database via the Hibernate framework and the Hibernate SessionFactory needs

a Data Source which defines the database connections. All these dependencies are
wired together using the Dependency Injection. In Figure 11, we have a code snippet
of a DAO interface StatDAO which is implemented in the following Figure 12 by a

DAO class StatDAOImpl . We see that in Figure 11 @Repository annotation is used

to mark StatDAOImpl as a class that fulfills the role or stereotype (also known as
Data Access Object or DAO) of a repository. Among the uses of this marker is the

automatic translation of exceptions. The next annotation @Autowired is used to

inject the SessionFactory. The SessionFactory is a factory for Session objects that
 33

contains all Database related property details pulled from either hibernate.cfg.xml
file or hibernate.properties file.

Figure 11: Sample code snippet of a DAO interface.

Figure 12: Sample code snippet of a DAO class.

 34

Next, the HQL(Hibernate Query Language) query is executed using the cus-
tomers entity mapping class. The obtained results are then returned to the Service

Layer Class.

4.2.4 Entity Mapping Class

The entire concept of Hibernate is to take the values from Java class attributes

and persist them to a database table. The Entity Mapping Class helps Hibernate
in determining how to pull the values from the classes and map them with table
and associated fields. To implement an efficient mapping these classes are written

in Plain Old Java Object (POJO) programming model. The POJO name is used
to emphasize that a given object is an ordinary Java Object, not a special object,
and in particular not an Enterprise JavaBean. Using Hibernate Annotations, all the

metadata is clubbed into the POJO Java file along with the code, which helps the user
understand the table structure and POJO simultaneously during the development.
In general it consists of the attributes relating to that of the columns in a table

declared private, have getter and setter methods and a default constructor.
In Figure 13, a code snippet of a Entity Mapping class is shown consisting

of the attributes mapping to the columns in the table, default constructor, getter
and methods. The @Entity annotation in Figure 13 is used to mark this class as an
entity Bean. The next annotation @Table allows to specify the details of the table

that will be used to persist the entity in the database. The @Id annotation is used to
annotate the primary key of a entity Bean and the @GeneratedValue annotation is
used to automatically assign the entity identifier using the IDENTITY column in the

following Figure 13. The next annotation @Column is used to specify the details of
the column to which a field will be mapped by explicitly specifying the name of the
 35

column in the table. Using these annotations together with the POJO programming
model the Customer Object is efficiently designed and mapped with the stat table

in the database.

Figure 13: Code snippet of a Entity Mapping class.

4.2.5 RPC via Middle-ware Class

This class is responsible for cross-platform communication using the Message-

oriented middleware via a Remote Procedure Call or RPC. In RPC a computer

program causes a procedure (subroutine) to execute in a different address space
(commonly on another computer), which is coded as if it were a normal (local) pro-

cedure call, without the programmer explicitly coding the details for the remote
 36

interaction. Here we use this pattern for cross platform integration among two dif-
ferent subsystems implemented on different platforms namely Java and Python. To

utilize this pattern we build a client and scalable RPC server. Here in this archi-
tecture the Java Subsystem acts as the client and the Python systems responses to
it as the RPC server. A client sends a request message and a server replies with a

response message. In order to receive a response we need to send a ’callback’ queue

address with the request. The Client class written in Java exposes a method named
call which sends an RPC request and blocks until the answer is received. The Python

RPC Server receives this request process it and sends back the result as a reply to
Java Client. The message communication takes place using the AMQP protocol in
the form of a String data-type. In Figure 14, a code snippet implement this RPC

message pattern for Cross Platform Integration is depicted.

Figure 14: Code snippet implementing the RPC message pattern on a Java client.
 37

CHAPTER 5

TESTING AND RESULTS

The application is tested to analyze its search accuracy and robustness in
correlating lost objects with that of the found ones by resolving the problem of

polysemy in it using NLP and observe its responsiveness. To do this four use cases
are fed to the system. Three different lost item records (Case: 1, Case: 2 , Case:
3) with similar properties and a found item record matching to one of the three lost

items (Case: 1) are entered into the system and tested for efficiency in correlating
the lost item records with found item record.

Figure 15: User Interface for Home Page of the application.

The UI for Home Page of the application is shown in Figure 15. First the
 38

found item is reported to the system by a Found Item user. The user clicks the
Found Image on the home page to navigate to the found form to fill the details.

Figure 16: Scenario of Reporting a Found Item into the system (Case: 1).

As shown in Figure 16, the user enters the details of the found item (assume
this entry as Case: 1), describes it in detail, uploads an image of the object and

submits his/her entry. Once these details are submitted, the system validates and
saves them in the database. Next, it processes (as shown in Figure 17) for finding a
Matching Lost record to the Found record and if a similar match is found, it notifies

the Lost Item user through their email about a new match being found.
 39

Figure 17: Processing of the submitted Found Record Details (Case: 1).

Figure 18: Confirmation Page with Tracking ID.

 40

Figure 19: Confirmation Email with Tracking ID.

Next, the lost item is reported to the system by a lost item user. As shown
in Figure 16, the user enters the details of the lost item, describes it in detail and
submits his/her entry.

Figure 20: Scenario of Reporting a Lost Item into the system.

 41

Figure 21: Processing of the submitted Lost Record Details.

Figure 22: Confirmation Email with Tracking ID.

 42

Once these details are submitted, the system validates and saves them in the
database. Next, it processes for finding a Matching Found Record to the Lost record

submitted (as shown in Figure 21) and if a similar match is found the lost record is
shown (Figure 23) which can be claimed (if that is the exact item which was lost). It
is not recommended to claim the object at this instant, if he/she is doubtful about

the shown object. The user can claim it later using the tracking system by giving
space for the found users to report more found items that could contain the lost users
item (exact item which was lost).

Figure 23: Confirmation Page with a Matching Result.

 43

Figure 24: Details of the Found Item (Case: 1)

Next, a new found item (Case: 2) similar to the lost item with similar item
name, slight variation in color, time, date and description is reported to the system

as shown in Figure 25.

Figure 25: Scenario of Reporting another Found Item into the system (Case: 2).
 44

Figure 26: Processing of the submitted Found Record Details.

Figure 27: Confirmation Page.

 45

Figure 28: Confirmation Email with Tracking ID.

Once these details are submitted, the system processes as shown in Figure 26
and finds a Matching Lost Record to the Found record submitted. When a match is

found, it notifies the Lost Item user through their email as shown in Figure 29.

Figure 29: Email notification to similar Lost record user.

Again, a new found item (Case: 3) similar to the lost item with similar item

name, slight variation in color, time, date and description is reported to the system
as shown in Figure 30.
 46

Figure 30: Scenario of Reporting another Found Item into the system (Case: 3).

Figure 31: Processing of the submitted Found Record Details.

 47

Figure 32: Confirmation Page.

Figure 33: Confirmation Email with Tracking ID.

Once the details in Figure 30 are submitted the system processes as shown
in Figure 31 and searches for a Match in Lost Records similar to the Found record

submitted, as there are no matches found to this found record among the lost records,
no further action is taken. Figure 34 shows the details of the submitted found Case:
3 from the tracking section.
 48

Figure 34: Details of the Found Item (Case: 3).

Now let us (representing the lost user) track the status of the submitted lost
item to see if any new matches are found similar to this record using the tracking

module as shown in Figures 35, 36 and 37.

Figure 35: Tracking of Lost Item status to View Found Matches.

 49

Figure 36: Lost Item Tracking details and Navigation.

Figure 37: Details of the tracked Lost Item.

 50

Figure 38: Viewing Found Matches.

Here, in Figure 38 we see that there are two matches found by the system

(Case: 1 , Case: 2) out of the submitted three records. The lost user examines each
of the matches in detail as shown in Figures 39 40 and claims the record if the Lost
user’s item existed among these matches.
 51

Figure 39: Found Item Details (Case: 1).

Figure 40: Found Item Details (Case: 2).

 52

Out of these two items, Found Item in Case: 1 shown in Figure 40 is claimed
by the Lost user. (as this is the item which we are looking for the system to show

up)

Figure 41: Claiming the Found Item.

An email notification is sent to the Found Item user about the claim request
of the Lost Item user as shown in Figure 42.

Figure 42: Email Notification to Found Item user about new Claim.
 53

The Found Item user views this claim request to take an action against it
using the tracking module as shown in Figures 43, 44, 45 and 46.

Figure 43: Tracking of Found Item status to view the claim.

Figure 44: Found Item Tracking Navigation Screen.

 54

Figure 45: Details of the Current Found Item.

Figure 46: Viewing claims.

 55

Figure 47: Details of the claimer’s Lost record.

Figure 48: Claim Accepted.

 56

Once the Found item user accepts the claim request (shown in Figure 47)
both their contact details are exchanged with one another through emails as shown

in Figures 49, 50.

Figure 49: Contact Details of Lost Item user shared with Found Item user.

Figure 50: Contact Details of Found Item user shared with Lost Item user.

In this testing scenario we have successfully tested the search efficiency of

the system in comparing the lost records with that of the found records. We have
efficiently resolved the problem of polysemy in the textual data records using NLP.
 57

Out of three similar found records submitted to the system against a lost record,
only two most similar records (Case: 1, Case: 2) have been found to be similar. One

of the record is efficiently discarded.

Both the Found records Case: 1 and Case: 2 are almost identical to the
submitted Lost Record. Their names represent the same entity i.e., a money carrying

case. Though they do not have the same colors, they are of a close range. The
interactive color picker in the UI helped tackling the issue of fuzziness in describing
the color by the user. Their descriptions are also almost similar, both are of the

same brand Tommy Hilfiger and both of them contained one $20 note and three $5
notes and found at library. Although, the Found item in Case: 2 had some extra
attributes into it, these were not considered by the filtering system as majority of the

properties matched with the lost Item described in Figure 20. The Case: 3 item was
discarded by the filtering system because even tough it had the same entity name

and brand name, its properties differed in other aspects as shown in Figure 37. It is
black in color which is not in close range to the lost item color (i.e., Brown). It was
found in a different location and none of the items in its description matched with

that of the items in the Lost record. Hence this item was rejected from the match
list. The system is also tested with many other use cases like (Cap, Hat), (Chain,
Necklace), (Book, Record), (Ring, Jewelery) etc and was found to be working with

good accuracy.

5.1 User Experience

A survey on user experience was performed for this application on the basis of
factors like User Interface Design, Application Responsiveness, System Performance,

Effectiveness and Information Detail. The survey was performed on 5 users on a

 58

score out of 10. The details about these ratings are shown in Table 5.1 as follows:

User 1 User 2 User 3 User 4 User 5 Avg

User Interface Design 9 8 9 9 9 8.8

Application Responsiveness 9 10 9 10 10 9.6

System Performance 10 10 9 10 10 9.8

Effectiveness 10 9 10 9 10 9.6

Information Detail 10 9 10 10 9 9.6

Overall Rating 9.48

Table 1. A survey on User Experience

 59

CHAPTER 6

CONCLUSION AND FUTURE ENHANCEMENTS

6.1 Conclusion

In this project an efficient Intelligent Lost and Found system was successfully

built as a web service addressing the problem of polysemy in it using NLP. It offers
a high degree of user privacy in its design. A complete automatic system that is
independent on humans intervention for management was built in this project. An

efficient architecture has been developed to take the advantage of the Java based
frameworks (Spring MVC, Hibernate ORM) in building an effective web service and
is integrated with a Python subsystem to utilize the rich NLP libraries of the NLTK

in building such a system.

The system was successfully tested against a variety combination of inputs
as discussed above. The system was very much efficient at resolving search results.

However, the system could have achieved more efficiency if customized NLTK learn-
ing models were used. This requires initial implementation of this prototype to
collect the data records so as to implement such models. The system could ad-

dress specific streamlined cases like correlating lost and found objects in motion like
trains, buses etc if this system was implemented at an organizational levels (Metro
Systems, Railways etc). Another important requirement for an effective experience

when implemented at a global scale is that it needs to be massively crowd sourced

and popular.
 60

6.2 Future Work

The application can further be improved and streamlined at results by using

customized NLP trained models. This can be only achieved once the application is
implemented and such data records are collected to build customized models. The
system can also be improved by adding Fuzzy Logic System to the location section

of the application. A mobile application extending the web service could be built to
reach more users.
 61

REFERENCES

[1] Adhitama, R., Kusumaningrum, R., and Gernowo, R. Topic labeling

towards news document collection based on latent dirichlet allocation and on-

tology. In 2017 1st International Conference on Informatics and Computational

Sciences (ICICoS) (Nov 2017), pp. 247–252.

[2] Du, L., Pate, J. K., and Johnson, M. Topic models with topic ordering
regularities for topic segmentation. In 2014 IEEE International Conference on

Data Mining (Dec 2014), pp. 803–808.

[3] Fang, Y., Huang, H., Jian, P., Xin, X., and Feng, C. Self-adaptive
topic model: A solution to the problem of rich topics get richer. China Com-
munications 11, 12 (Dec 2014), 35–43.

[4] Fernandes, J. L., Lopes, I. C., Rodrigues, J. J. P. C., and Ullah,

S. Performance evaluation of restful web services and amqp protocol. In 2013

Fifth International Conference on Ubiquitous and Future Networks (ICUFN)
(July 2013), pp. 810–815.

[5] Hussain, F., Qamar, U., and Zeb, S. A novel approach for searching

linguistic synonyms through parts of speech tagging. In 2016 IEEE/WIC/ACM

International Conference on Web Intelligence (WI) (Oct 2016), pp. 465–468.

[6] Shchitov, I., Lagutina, K., Lagutina, N., Paramonov, I., and Vasi-
lyev, A. A survey on thesauri application in automatic natural language pro-

cessing. In 2017 21st Conference of Open Innovations Association (FRUCT)

(Nov 2017), pp. 296–303.
 62

[7] Tu, H. T., Phan, T. T., and Nguyen, K. P. An adaptive latent semantic
analysis for text mining. In 2017 International Conference on System Science

and Engineering (ICSSE) (July 2017), pp. 588–593.

[8] Youzhi, Z. Research and implementation of part-of-speech tagging based on

hidden markov model. In 2009 Asia-Pacific Conference on Computational In-
telligence and Industrial Applications (PACIIA) (Nov 2009), vol. 2, pp. 26–29.

[9] Yuan, L. Improvement for the automatic part-of-speech tagging based on hid-

den markov model. In 2010 2nd International Conference on Signal Processing

Systems (July 2010), vol. 1, pp. V1–744–V1–747.

[10] Zhang, D. Y., Wang, D., Zheng, H., Mu, X., Li, Q., and Zhang, Y.
Large-scale point-of-interest category prediction using natural language process-

ing models. In 2017 IEEE International Conference on Big Data (Big Data)
(Dec 2017), pp. 1027–1032.