-
Notifications
You must be signed in to change notification settings - Fork 0
Data Model
At its heart, GaNCH is a proxy, fetching data from another source on behalf of the user.
To this end, there are a series of data objects maintaining local information used to query Wikidata via its Query Service
Queries are the main data object in GaNCH, and are used to fetch data about organizations from Wikidata, and store the responses. Queries consist of a request, which is a SPARQL query to be sent to the Wikidata Query Service (WQS), and a response, received as JSON and stored as text. In addition, queries have a title, to be used as a display label, and a scope, as we emit queries covering counties, regions (as defined by the Georgia Emergency Management Agency) and the state as a whole. Much of the site’s layout is designed around creating, reading, updating and deleting these queries.
Queries belong to the user who created them.
The basic lifecycle of a query begins with the storing of the SPARQL query (as the request), the title and scope, along with the ID of the user creating the object. When the object is saved to the database, a background job is launched transmitting the query to the Wikidata Query Service, and when the response is returned, it is added to the query and saved. In addition, the time of the query is logged and stored as part of the object.
On the page, a particular query response is parsed and used to generate both a map and a table of the results. Links to an organization’s data record in Wikidata are also added.
For convenience during project setup, we have a series of Rake tasks that can be run to generate county and region queries as batches, using lists of county/region identifiers stored in lib/data. The query for the State of Georgia as a whole, being a single query, can be created manually.
The title field is used in generating easy-to-remember links to query display pages. Thus “GEMA Region 4” can be found at /region/gema-region-4. See the routing table in routes.rb for more information.
Recipients must belong to a user, must contain an organization name, and an email address.
Recipients are generated from processing query responses, over the entire set of queries. They are displayed in a table at /recipients, to authenticated users only.
If found, phone numbers and other contact information is stored in the Recipient record.
Above the table listing the recipients found in Wikidata, there is a link to launch a batch email, sending a reminder notice to recipients urging them to ensure their organization’s information is up-to-date. There is a confirmation modal to prevent accidental activation of this feature, as once it is started it cannot be undone.
During processing of this job, duplicate emails are filtered out. This is to prevent spamming addressees.
Originally, the design of this application was to break up email blasts by region or even county, but we soon learned that there were many duplicate emails within the overall set, as one person was overseeing various organizations. To prevent spamming these people with multiple emails, we generated this unique list across all queries.
We generate emails reminding stakeholders to update their Wikidata entries to facilitate emergency response and disaster management. The recipient_mailer folder holds these templates. These emails are generated when an admin user initiates the ‘send reminders’ job on the recipients page.
Authenticated users are created via a signup page, which should only be made available when maintainers wish to have new users entering the system. Users enter a name, email address and a password, the latter of which is stored as an encrypted hash in the database. Existing users can login via a login page, and once authenticated their user id will be fetched via a secure session parameter. Authenticated users are permitted various actions not seen by unauthenticated visitors. This includes the creation and updating of queries, and viewing the list of recipients for email reminders.
New users will receive a welcome email upon successful signup. This signup is logged, both in the Rails logs and in the sent mail of the ‘reply to’ address configured in Action Mailer for this mail’s controller
There is no password recovery logic or other self-management facilities, as this site is intended to see minimal administration. As admin users can create new users, those responsible for your site should occasionally visit the /users page to see if there have been any changes. (If you’d like notification of a new user sign up, simply add a bcc field to the user_mailer’s welcome_email method.)