Your SlideShare is downloading. ×
Public Safety Mashups to Support Policy Makers || Choennie
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Public Safety Mashups to Support Policy Makers || Choennie

384
views

Published on

Published in: Design

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
384
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 26-06-09
  • 26-06-09 If it appears that some parts are becoming safer than others, resources can be moved from one to the other. Statistical data provides insights into why areas are becoming safer while others are not. There is a lot of data on safety, primarily coming from surveys and operational databases. Problem: maintained by many different organisations (Statistics Neth, Just, Internal Affairs (Police) Policy makers have to put in a lot of effort to get the data they need. They have to phone, email people, who have to make time to find what they need. They might not be there, wait for people to return calls. Often weeks go by. We developed a tool that does all this. It collects the data they need in their day-to-day work to that they have it ready when they need it. It is extensible and easily updatable. It also contains what we call “contextual data”, data that is not about safety itself, but still related in some way. Like demographics.
  • 26-06-09 If it appears that some parts are becoming safer than others, resources can be moved from one to the other. Statistical data provides insights into why areas are becoming safer while others are not. There is a lot of data on safety, primarily coming from surveys and operational databases. Problem: maintained by many different organisations (Statistics Neth, Just, Internal Affairs (Police) Policy makers have to put in a lot of effort to get the data they need. They have to phone, email people, who have to make time to find what they need. They might not be there, wait for people to return calls. Often weeks go by. We developed a tool that does all this. It collects the data they need in their day-to-day work to that they have it ready when they need it. It is extensible and easily updatable. It also contains what we call “contextual data”, data that is not about safety itself, but still related in some way. Like demographics.
  • 26-06-09 If it appears that some parts are becoming safer than others, resources can be moved from one to the other. Statistical data provides insights into why areas are becoming safer while others are not. There is a lot of data on safety, primarily coming from surveys and operational databases. Problem: maintained by many different organisations (Statistics Neth, Just, Internal Affairs (Police) Policy makers have to put in a lot of effort to get the data they need. They have to phone, email people, who have to make time to find what they need. They might not be there, wait for people to return calls. Often weeks go by. We developed a tool that does all this. It collects the data they need in their day-to-day work to that they have it ready when they need it. It is extensible and easily updatable. It also contains what we call “contextual data”, data that is not about safety itself, but still related in some way. Like demographics.
  • 26-06-09 When we started out, we did a number of workshops with our intended users, where we demoed prototypes of the interface and asked for feedback. Some 800 indicators from some thirty sources from a dozen organisations. Privacy. – small numbers – personal accounts, logged: mandatory by law. But we also came up with our own list of requirements. We have to maintain this, so it had to be extensible and easy to update. That means that we needed to be able to connect every imaginable source, whatever its specs. Also: meta data. Exensive information about what numbers mean, where they come from, what methods used, etc.
  • 26-06-09 When we started out, we did a number of workshops with our intended users, where we demoed prototypes of the interface and asked for feedback. Some 800 indicators from some thirty sources from a dozen organisations. Privacy. – small numbers – personal accounts, logged: mandatory by law. But we also came up with our own list of requirements. We have to maintain this, so it had to be extensible and easy to update. That means that we needed to be able to connect every imaginable source, whatever its specs. Also: meta data. Exensive information about what numbers mean, where they come from, what methods used, etc.
  • 26-06-09 When we started out, we did a number of workshops with our intended users, where we demoed prototypes of the interface and asked for feedback. Some 800 indicators from some thirty sources from a dozen organisations. Privacy. – small numbers – personal accounts, logged: mandatory by law. But we also came up with our own list of requirements. We have to maintain this, so it had to be extensible and easy to update. That means that we needed to be able to connect every imaginable source, whatever its specs. Also: meta data. Exensive information about what numbers mean, where they come from, what methods used, etc.
  • 26-06-09 When we started out, we did a number of workshops with our intended users, where we demoed prototypes of the interface and asked for feedback. Some 800 indicators from some thirty sources from a dozen organisations. Privacy. – small numbers – personal accounts, logged: mandatory by law. But we also came up with our own list of requirements. We have to maintain this, so it had to be extensible and easy to update. That means that we needed to be able to connect every imaginable source, whatever its specs. Also: meta data. Exensive information about what numbers mean, where they come from, what methods used, etc.
  • 26-06-09 When we started out, we did a number of workshops with our intended users, where we demoed prototypes of the interface and asked for feedback. Some 800 indicators from some thirty sources from a dozen organisations. Privacy. – small numbers – personal accounts, logged: mandatory by law. But we also came up with our own list of requirements. We have to maintain this, so it had to be extensible and easy to update. That means that we needed to be able to connect every imaginable source, whatever its specs. Also: meta data. Exensive information about what numbers mean, where they come from, what methods used, etc.
  • 26-06-09 Leg plaatje uit Transformation layer: consistency checks Sources: no PKs, only connectable by period/region Meta data
  • 26-06-09 To make things a little less abstract, I will show some screens from our interface., in which the user finds out something about a hot topic at this moment, loitering youth.
  • 26-06-09
  • 26-06-09
  • Transcript

    • 1. EGOVIS – Sept 2010 Public Safety Mashups to Support Policy Makers Sunil Choenni Rotterdam University/ WODC
    • 2. Content
      • Introduction
      • Measuring Safety
      • Architecture Design & Implementation
      • Creating Mashups
      • Conclusions & further Research
    • 3. Introduction
      • Policy makers have a need for statistical insight into public safety at different levels, such as regional and national
      • Data wrt public safety are collected by different organisations and published on different websites.
      • Integrating these data may increase the insight in public safety
    • 4. Introduction
      • Goal: provide policy makers a tool such that they may create mashups, i.e., able to combine data from different sources and create their own content.
      • requirement: avoid undesired effects
      • violation of privacy
      • misinterpretation of statistics
      • disclosure of the identity of a group of individuals
    • 5. Approach
      • How to Measure Safety
      • - broad and subjective notion
      • - searched for variables that are useful to make safety operational
      • To find out the Information Need of Policy Makers
    • 6. Measuring Safety
      • Phenomena and variables related to public safety
      • Have exploited literature on criminology and public safety
      • Have exploited domain knowledge and databases
      • Phenomena related to Public Safety (about 1500 variables)
      • Crime – registered crime, victims, preventive measures
      • Enforcement – police contacts, suspects, solved crime
      • Sanction – fines, imprisonments, judicary cases
      • Police & justice resources - prison capacity, police officers
    • 7. Information Need
      • By means of two workshops: about 30 people participated ranging from junior policy makers to directors
      • Some individual meetings after the workshops
      • Results
      • Three types of questions
      • Contextual data is required as well
      • Requirements to the tool
    • 8. Three types of questions
      • Simple queries . For example,how many people in a region within a time period responded in a specific way to a specific survey question?
      • Context of a quantifier . For example, how does the growth or decline of a specific figure in a geographical region relate to another figure? For example, a growth in bicycle thefts in a neighbourhood can turn into a relative decline when local population growth exceeds.
      • Similarity queries , i.e. looking for regions that share in some respect the same context. After querying for a specific data set in which some numbers stand out in some way, the user can query for other regions that show similar numbers or trends.
    • 9. Requirements
      • rules & regulations wrt privacy should be respected (in agreement with our requirement)
      • Help required in interpreting statistics/result
      • Interaction with the tool
      • Possibility to add new data and questions
      • Architecture design focussed on
      • Extensibility and flexibility
      • User friendly interfaces
    • 10. mashed up data defined mashup store/ retrieve data source data Data Warehouse Interface Layer Presentation module Mashup module ETL process set queries query results translator 1 translator 2 translator n mashup_to_sQL Data access layer
    • 11. Architecture
      • Data is stored aggregated at police region level in DW
      • Each region is distinguished by a regionid in DW
      • Mashup module contains click and drag facilities and menus to define a mashup
      • Presentation Module has the capability to present the output as tables, graphs, figures, …
      • For interpretation purposes: how a result is obtained? E.g. is the result based on survey or register data, the meaning of a unit in which a number is expressed
      Vul titel presentatie in | Vul datum in
    • 12. Architecture: to prevent violation of privacy
      • only attributes are stored in the system that are in line with Dutch Personal Data Protection Act, i.e., no data wrt someone religion or life conviction, political conviction, health, sexual orientation
      • only aggregated data are stored
      • Mashups that contains results that may violate the privacy are not shown by the presentation module
      • ( e.g. if there are only 2 convicted persons for a crime type X, this is not shown. Also if there are 90 % of the people in a region involved in crime, this is not shown as well
      • - ( An extensive explanation module to facilitate interpretation)
      Vul titel presentatie in | Vul datum in
    • 13. Creating Mashups
      • User selects indicator from a tree,
      • looks at meta data,
      • selects a period,
      • selects a region level,
      • and selects a presentation form
    • 14. Vul titel presentatie in | Vul datum in
    • 15. Conclusion & further research
      • To meet the practical need of policy makers we implemented a tool that facilitates to create mashups. Currently the tool is used at our department.
      • avoid undesired effects
      • Extensible
      • rich set of presentation capabilities
      • Further research
      • evaluation
      • Scalability, google like engine
      • (adding more resources -  information overload?)
    • 16.
      • Provide citizens to create their own mashups i.e., combine different data sources focussed towards Rotterdam to create their own content.
      • However,
      • More data (locally focussed)
      • Wide variety of structured data such as sensor data
      • (tid, pid, objectid)
      • Added value different types of data , such as semi-structured data and unstructured data ( social media)
      Other applications: Rotterdam Open Data