Tucson Police Department Agenda

1
Tucson Police Department Agenda
Sgt. Jennifer Schroeder, T.P.D.

• Accomplishments of the last two years
• Collaborative opportunities
• TPDs Commitment to COPLINK and
• plans for the future
• Interest fostered by COPLINK extending
• through all levels of LE

2
TPDs Commitment to COPLINK

• Deployment at TPD-High Priority
• Committing up to 245,000 additional funding to
  fully deploy Concept Space and integrate with
  COPLINK Database
• Forming partnerships with other agencies

3
TPD Deployment

• COPLINK Team ready to implement
• Additional development to fully operationalize
  and provide live update capability complete
• Full Deployment subject to TPD upgrade timeline

4
TPD Upgrade

• TPD adding better hardware and upgrading software
  in preparation for Y2K
• Real-time update strategy was designed for use on
  new system that includes upgrade from Oracle 6 to
  Oracle 7.3

5
TPD Upgrade Timeline

• Initially was scheduled for completion July 1999
• Now scheduled for December 1999
• Test RMS system to be available by beginning
  November 1999
• Deployment of COPLINK can effectively begin when
  test RMS is running

6
Test TPD System

• Will allow phased deployment/testing on new
  hardware
• Network configuration can be tested and refined
• Installation management issues can be refined
• Can begin training and use of system -- System
  will be a reality to users

7
Full Deployment

• By December 1999, testing will be complete on
  both the new TPD RMS and the TPD COPLINK system
• Final build process will occur, adding real-time
  updates to RMS information
• Rollout of interface and training will already
  have begun, so users will be live on the system
  already

8
Concept Space Deployment

• TPD has committed approximately 245,000 to
  deploy Concept Space at TPD
• This includes deployment, user evaluations,
  refinement based on real-life usage
• Integration of the COPLINK Concept Space and
  COPLINK Database

9
Concept Space Timeline

• Initial deployment, user studies, January 2000
• Refinement, modification, integration
• Deployment of fully integrated system by May 2000

10
COPLINK Interest
Interest at all levels Municipal, County, State,
Federal
11
COPLINK Interest Other Agencies

• Municipal Phoenix Police Department, Mesa,
  Avondale, Chandler, Glendale, Peoria, Paradise
  Valley, Scottsdale, Tempe
• County Maricopa County Sheriffs Office, Pima
  County Sheriffs Office

12
COPLINK Interest Other Agencies

• Federal High Intensity Drug Trafficking Area
  (HIDTA) Center
• State Government Information Technology Agency,
  Arizona Criminal Justice Commission
• State Law Enforcement Arizona DPS

13
Partnerships

• National Institute of Justice
• University of Arizona AI Group
• Phoenix Police Department

14
Next Presentation Link
15
AI Lab Research Overview

• Hsinchun Chen
• Director, AI Lab
• McClelland Professor of MIS

16
AI Lab Summary

• Research areas digital libraries, data mining,
  intelligent retrieval, and knowledge management
• Funding NSF, DARPA, NIJ, NIH, NLM, HP, IBM, SAP,
  etc
• UA/MIS Top 5 in nation, 30M funding
• AI Lab 7M funding, 35 members, 1M in computing
  equipment

17
Major AL Lab Projects

• NSF Digital Library Initiative 2,
  High-Performance Digital Library Classification
  Systems
• NSF CISE, Collaborative Visualization
• DARPA Information Management, Interspace
  Semantic Interoperability
• NIH NLM, Concept Mapping for Medical Informatics

18
Major AL Lab Research Directions

• Go deep! (Deep Semantic Parsing)
• Get personal! (Spiders/Agents)
• Get pretty! (Visualization)
• Go international! (Multilingual)
• Go to applications! (Law Enforcement, Medicine,
  Business Intelligence)

19
Next Presentation Link
20
COPLINK Project StatusOverview

• Homa Atabakhsh, Ph.D.
• University of Arizona, MIS Dept.
• COPLINK Project Manager

21
Design Criteria

• Platform independent, portable
  not all agencies use same HW/OS
• Stable and scalable (possibility for system
  expansion)
• Intuitive and easy to use UI
• Strong performance and response time
• Industry strength applications TCP/IP, Java,
  Oracle
• Low cost maintenance and training

22
Design Architecture

• Design Criteria gt
• Three-tier architecture was proposed
• Java front-end,
• Middle ware application server (OAS),
• Back-End Oracle Relational Database Management
  System

23
Project Components

• COPLINK Database Application
• Shantel Ekman
• Emily Werner
• Harsh V. Gupta
• COPLINK Concept Space Application
• Harsh Gupta
• User Interface and Evaluations
• Rosie Hauck User Interface Evaluations
• Dan Chen Interface Coding
• Distributed COPLINK
• Chris Boarman

24
Relationship between Components
COPLINK Concept Space Application
COPLINK Database Application
- GUI - GUI - User Evaluations - User
Evaluations - Distributed Application -
Distributed Application
25
Data Base Design and Testing Background

• COPLINK Database application provides the user
  with
• An easy-to-use and intuitive interface for
  retrieving and analyzing information
• The integration of different databases for info
  sharing
• Performance and flexibility (i.e., portable to
  different agencies)

26
Data Base Design and Testing Goals and Status

• Design and develop database refresh strategy to
  allow frequent updates to the database and
  provide current data
• Stress testing of the database and OAS Test
  loads that simulate simultaneous users requesting
  info from database

27
Concept Space Background

• Analysis Tool
• Finds relationships between entities in the
  database (e.g. people, locations, incidents)
• Shows these relationships to users in an
  easy-to-use graphical user interface

28
Concept Space Goals and Status

• Goal Allow the user to do fast and accurate
  analysis of the data
• The new GUI is robust
• Future Goals
• Deployment at TPD
• Fully integrate COPLINK Concept Space application
  with COPLINK Database application
• Adapt to other law enforcement agencies

29
User Interface and User Evaluations

• User Interface (GUI)
• Robust, easy-to-use and intuitive
• Categorizes information for better organization
  of the information
• Object-oriented (modular, easily enhanced),
  portable and web-based Java
• User Evaluations
• Conduct thorough user testing
• Study the technological impact on users

30
Distributed COPLINK Background

• Goal Develop a prototype system to allow
  multiple agencies with similar implementations of
  COPLINK to share information
• Communication between physically separated
  databases

31
Distributed COPLINK Status

• The distributed COPLINK system has been shown to
  be feasible
• Has been tested on three COPLINK nodes using
  different versions of data sets from TPD
• Future Test between Tucson and Phoenix

32
COPLINK Components
COPLINK Concept Space Application
COPLINK Database Application
- GUI - GUI - User Evaluations - User
Evaluations - Distributed Application -
Distributed Application
33
Next Presentation
34
COPLINK Database Design Presentation

• Harsh Gupta
• Research Assistant
• October 20, 1999

35
Agenda

• Overview of Application Architecture
• Design Improvements
• Performance and Stress Testing

36
Search Sequence
37
Three Tier Architecture
Listener Dispatcher
Server Processes
Server Processes
Java URL Classes
PL/SQL Cartridges
.
.
PL/SQL Cartridges
PL/SQL Cartridges
PL/SQL Cartridges
.
Connection to DB
Connection to DB
Query Results
Requests
Database
Summary Views
38
Three Tier Architecture

• Front End User Interface
• JAVA Platform independent!
• Web Based Thin Client
• Set of screens based on five search categories
• Formats the information in a very intuitive/user
  friendly fashion

39
Three Tier Architecture

• Middleware Oracle Application Server (OAS)
• Supports multi-platforms
• Can work with non-Oracle Databases
• Responsible for
• Communication between interface and database
• Query distribution
• Load balancing

40
Three Tier Architecture

• Back-End Database
• Oracle 8 Server
• Back-End consists of data maintained in clusters,
  tables, indicies and views
• Stored Procedures (handle application queries)

41
Scalability
Clients
Middleware
Databases
42
Portability
Stored Procedures
Stored procedures work on views
Views
Views
Views
Standard views remain same
Tables
Tables
Underlying tables can be mapped to standard views
Tables
Tables
Tables
43
Initial Testing Problems

• Long wait for some queries
• Various reasons including
• Front-End Undesired timeout
• Middleware Multiple connections
  
  for the same query
• Back-End Needs more optimization

44
Design Improvements

• Redesigned front end Java connection classes
• Upgraded the current version of OAS from 3.0 to
  4.0 and Reconfigured
• Backend Design Modified
• Logical and Physical Database structure
• Oracle Instance re-configuration
• Query Analysis

45
Logical design changes
Regular Tables data access time consuming
Person Based Queries
Incident Based Queries
46

Logical design changes
Clustered Tables Faster access to data
Person Based Queries
Incident Based Queries
Initial Query
BUFFER
Subsequent queries from Buffer
Incident Cluster
Person Cluster
47
Oracle Instance re-configuration Larger Buffer!
Instance
System Global Area (SGA)
Shared Pool
Library Cache
Redo log buffer
Database Buffer Cache
Data Dictionary Cache
48
Stress Testing Overview

• Determining a baseline (benchmark) for existing
  system
• Test system under different controlled conditions
• Track performance behavior
• Information to be used for further tuning

49
Stress Testing Components

• Automatic Test Generator
• Can create any number of test queries
• Multi-threaded Java User Application
• Simulates users querying the database
• Can simulate to any number of users constantly
  making queries

50
Stress Testing Results

• 150 simultaneous users testing
• Testing up to 4 to 6 times actual number of users
• No wait time between queries
• Significant stress on OAS proved very stable
• Back-End Complete Performance check
• Remarkable decrease in query response time!

51
Thanks!
52
Next Presentation
53
COPLINKConcept Space

• Harsh Gupta
• Research Assistant
• October 20, 1999

54
COPLINK Concept Space

• Analysis Tool
• Provides associations between search terms
• More specific users investigators, detectives,
  analysts
• With COPLINK Database Application it makes a more
  powerful and complete solution

55
Search Sequence
Enter one or more search terms
Get associations between terms
Add/Delete terms for further analysis
Get detailed information on term(s)
Get more associations!
56
Architecture
Java URL Classes
Query Results
Summary Views
57
Database Design

• Relevant information extracted from Coplink
  database
• Comparatively fewer tables 4-5
• Contains
• Key words
• Associations
• Stored Procedures

58
Database Creation Process
Loaded in Oracle tables
COPLINK Database
Output flat file
Processing Associations
Extracted information as flat files
59
Future Integration
Common Interface
60
Thanks!
61
Next Presentation
62
COPLINK
Tucson Police Department
The University of Arizona
Integrating Law Enforcement Databases In a Secure
Web-Based Intranet
63
COPLINK Database User Evaluation

• Rosie Hauck
• Research Associate
• Artificial Intelligence Lab

64
User Centered Design Model for COPLINK
Implementation
Task Analysis/ Functional Analysis
Prototyping
Evaluation
Requirements specification
Conceptual design/ Formal design
65
Purpose of Research Study

• Conduct a evaluation of the COPLINK DB
• Looking at aspects of usability
• Use feedback to continue the development efforts
• Compare to current TPD systems
• RMS
• ELVIS (Mug shot DB)
• Gangs

66
Research Strategy

• Experimental Design
• Comparison between RMS and COPLINK DB
• Want real work to evaluate
• Data Collection
  Quantitative and Qualitative
• Questionnaires
• In-Depth Interviews
• Direct observation

67
Participants

• 52 Law Enforcement Personnel
• Job classifications
• Sergeants 13
• Detectives 50
• Crime analysts 13
• Patrol Officers 24
• Police units
• Homicide, Adult Sex Assault, Aggravated Assault,
  Auto Theft, Robbery, Burglary, Gangs, Patrol,
  General Crime
• Comfort level with computers
• Very comfortable 10 , Comfortable 48, Neither
  30, Uncomfortable 10, Very uncomfortable 2

68
Data Collection

• Demographic information
• RMS questionnaire on perceived usability
• COPLINK DB
• Introduction/Training
• Trials (at least 2 searches)
• COPLINK Questionnaire
• Final interview

69
Results

• Usability Questionnaire
• Comparison between RMS and COPLINK DB
• Statistical analysis
• Interviews
• Finding general themes
• Suggestions for further system development

70
Defining usability

• Effectiveness
• Impact on Job Performance Productivity
• Accuracy of system
• Effectiveness of information
• Ease of Use
• Effort to use system to learn
• Navigation through the system
• Efficiency
• Interface design
• Speed
• Ability to find info and info organization

71
Questionnaire ResultsEfficiency
Scale 1 Strongly disagree 5 Strongly
agree
Statistically different (p lt 0.00)
72
Questionnaire ResultsEase of Use
Scale 1 Strongly disagree 5 Strongly
agree
Statistically different (p lt 0.00)
73
Questionnaire ResultsEffectiveness
Scale 1 Strongly disagree 5 Strongly
agree
Statistically different (p lt 0.00)
74
Interview Results

• Participants asked to
• Comment on the COPLINK DB system
• Compare RMS to COPLINK DB
• General Themes
• Speed
• Ease of use
• Interface
• Information

75
Interview Theme Speed

• 100 quicker
• Speed is the main strength
• Lead to more work efficiencies
• Saves time
• Get information quicker

76
Interview Theme Ease of Use

• Easier to read/search
• User-friendly
• A lot easier to use
• I could use it without training

77
Interview Theme Interface

• Get bulk of information on one screen
• Less steps to get information
• Flexible to organize sort
• I like colors
• Navigation is easier

78
Interview Theme Information

• A lot more information than RMS
• Enter less information, the more you get
• More effective and efficient
• Interlink between information
• Ties information together

79
Interesting notes

• Notion of increased information
• More an issue of ability to access information in
  usable form
• Ability for all participants to use COPLINK
• COPLINK on the street - A different perspective
• At substations
• Identification purposes

80
Conclusions

• Results of study
• Support the design and functionality incorporated
  into COPLINK DB
• Shows the strengths of the system
• From an end user point of view
• As compared to currently available TPD systems
• Generate interest in COPLINK system

81
Future Directions

• Development of deployment plan
• Training issues
• Hardware requirements
• Emphasis on stress testing
• Refining functionality and design

82
COPLINK Concept Space Revisited
83
Results Qualitative Investigative Tasks

• Strengths
• Linking known information
• Finding associations with unknown information
• Summary information/quick picture
• Problem area
• Not a records management system

84
Results Qualitative Interface

• Strengths
• Organization and efficiency
• Less cognitive/memory overload
• Speed getting hits and mistakes less crucial
• Problem areas
• Entry format
• Misunderstandings of output
• Incomplete returns
• Updating data

85
Current Direction

• Modification of Interface
• Three-Phase Evaluation Plan
• Phase I - Internal usability and info
  verification
• Phase II - User evaluation sessions
• Phase III.A - Stress-testing (simulation)
• Phase III.B - Limited deployment testing
• Looking towards integration with the DB system

86

• Questions?

87
Next Presentation
88
Coplink Refresh Strategy

• Shantel Ekman
• Emily Werner
• October 20, 1999

89
Material to be Covered

• Background Information
• Previous Database Setup
• Problems
• The Refresh Solution

90
Background Information

• Combination of TPDs
• Record Management System (RMS)
• Gang Database and
• Elvis system (mugshots)
• Small set of denormalized tables from the three
  databases
• Refresh involves only the Record Management System

91
Bulk Load

• A bulk load is a loading process in which the
  data is loaded all at one point and then remains
  static until reloaded.

92
Bulk Load

• Copy RMS data
• Run a series of scripts containing PL/SQL Blocks
• Information is populated to Coplink tables
• Result Static Coplink database

93
Bulk Load Diagram
Coplink Tables
Copy of RMS tables
DATA
PL/SQL Blocks
DATA
DATA
DATA
DATA
DATA
DATA
94
Bulk Load Problems
Once loaded the data was static

• Usefulness
• Reliability
• Reload strains

95
Additional Problem

• RMS maintains its database relationships using a
  set of twelve random characters
• Oracle Web Application Server would have problems
  with some of the characters in these sets

96
Refresh Strategy

• To allow the system to be refreshed more
  frequently, the back-end database had to be
  redesigned. This is referred to as the Refresh
  Strategy.

97
Base Design Elements

• Source Table
• Triggers
• Snapshots
• Stored PL/SQL procedures

98
Source Table

• Gateway to record where data came from and when
  it entered the system
• Developed in response to Character key problems
• Provides for a global primary key
• Tracking of data back to original source

99
Source Table Example

• All primary keys are directly loaded into the
  Source table

100
Source Table Use
Original Table
Source
Originalpk
Originalpk
Coplinkpk
DATA
Internal Coplink Table
Coplinkpk
DATA
101
Triggers

• Triggers are a form of stored PL/SQL code that is
  implicitly fired (executed) by Oracle when a
  triggering event occurs, no matter which user is
  connected or which application is being used.

102
Using Triggers

• Automatically populate the change from one table
  to another table
• Done when an insert, update or delete occurs
• Controlled by Oracle and becomes part of the
  transaction

103
Trigger Example
RMS Tables
TRIGGER
Primary Key
DATA
Primary Key Procedure Insert Procedure Update
Procedure Delete Procedure
Coplink Tables
New Primary Key
DATA
104
Problem

• Since a trigger is considered part of the
  transaction
• And the trigger would have to fire over a network
  connection
• If the network connection fails, the transaction
  would fail to be processed on the RMS system

105
Snapshots

• A snapshot is a local copy of table data
  originating from one or more remote master
  tables. An application can query the data in a
  snapshot, but cannot insert, update, or delete
  rows in the snapshot.

106
Using Snapshots

• Maintain a separate copy of the RMS tables that
  are used
• Oracle would update the copy through snapshot
  refresh
• Solves the problem of losing data as the result
  of network failure

107
Snapshot Diagram
RMS Tables
Snapshot of RMS Tables
Primary Key
Primary Key
DATA
DATA
TRIGGER
Coplink Tables
New Primary Key
DATA
108
Problems

• Oracle currently does not support the application
  of triggers on snapshots
• Structure was maintained
• For future use when Oracle does support triggers
  on Snapshots
• Still good design for the system

109
Snapshot Procedures(Stored PL/SQL Procedures)

• A group of procedures were written to simulate
  the idea of a snapshot system so that triggers
  could be used. These procedures are referred to
  as Snapshot Procedures.

110
Purpose of procedures

• Execution of procedures would
• Fetch a list of changes made to the targeted RMS
  tables.
• Perform the changes to Snapshot copies
• Delete the changed item from the list

111
Additional Objects

• There is a need to collect the RMS table changes.
• Local triggers on the RMS tables
• Snapshot log to store changes

T3
T2
T1
Trigger
T4
T5
Trigger
Trigger
LOG
112
Complete Refresh System
Coplink DB
TPDs RMS
Source
Snapshot Procedure
T2
T3
T1
Snapshot Table
Trigger
Snapshot Table
Snapshot Table
LOG
113
Complete Refresh Strategy
Coplink DB
Source
Trigger
Snapshot Table
Coplink Table
Snapshot Table
Coplink Table
Snapshot Table
Coplink Table
114
Benefits of Refresh Strategy

• More frequent updates
• Primary key problems solved
• Procedure can be placed in a queue or run when
  necessary
• Incoming data can be tracked
• Minimal hit on TPDs RMS, most processing on
  Coplink machine

115
Summary

• Previous system of bulk loading
• Problems
• Refresh solution

116
Questions?
117
Next Presentation
118
Internet Spiders

• David Hendriawan
• (Spider Group)
• October 20, 1999

119
Agenda

• Internet Spiders Overview
• Demonstration
• Competitive Intelligence (CI) Spider
• Meta Spider
• Future Directions
• COPLINK Self-Organizing Map

120
What are Internet Spiders?

• Internet Spiders are small programs that crawl
  the web, jumping from one page to another by
  following Internet hyperlinks, to gather specific
  information.

Starting URL
Level 1
Level 2
121
Overall Architecture
122
Demonstration

• CI Spider
• Meta Spider

123
Future Directions

• Use of database or Intranet as the search space
• Constant monitoring of web sites
• Collaborative spiders for information sharing

124
COPLINK Self-Organizing Map

• Key Components
• Limit to a subset of documents
• Select output terms (crime type, person,
  location, etc.)
• Color (serious, liquor, traffic, less serious)
• COPLINK SOM Demo

125
Next Presentation
126
Distributed Coplink

• Chris Boarman, AI Lab

127
Project Goals

• To allow multiple agencies with similar
  implementations of Coplink to share information
  between each agency
• DBMS platform independence

128
Description

• An expanded distributed system of multiple
  Coplink nodes includes a distributed version of
  the Coplink system, a modified set of queries
  that automatically query multiple Coplink nodes,
  and the underlying system architecture to support
  a distributed database system.

129
Description
Single Node Coplink Three-Tier Architecture
Java URL Classes
Query Results
Summary Views
130
Description
High Level Conceptual Diagram
Local Application Server
Sends Query Requests to

1
1
Client

1
Executes Stored Procedure in
1
Local Node Node
1
Queries Data From
Local Coplink Node
1
Queries Data From
Local Coplink Schema
1


Note The Node Manager and Coplink Schema
objects are part of a Coplink Node Instance
1..
Remote Coplink Schema
Remote Coplink Node(s)
131
Description
Distributed Coplink Three-Tier Architecture
(LOCAL)
(REMOTE)
Client
Client
Remote OAS
Local OAS
REMOTE Coplink Server Node
LOCAL Coplink Server Node
Coplink
Node
Coplink
Node
Schema
Schema
Manager
Manager
132
Technology
Networking Layers and Protocols
133
Technology

• Oracle application server
• Highly scalable, supports redirection
• Oracle enterprise database server
• PL/SQL (dynamic), security
• Java
• Networking
• Three-tier architecture
• Scalable in number of nodes

134
Current Status

• Prototype
• Fundamental infrastructure complete
• Four distributed procedures
• Number of nodes/servers used for prototype
  system 2
• Development and testing within secure LAN