-
Notifications
You must be signed in to change notification settings - Fork 1
Features
Features are any distinct aspect of the source code and related objects built for WikiframeVG and can be thought of as functional units.
Description: Allows SPARQL queries stored in the application database to include filter tags ( ~[filt-tag-name]~ ) that are dynamically replaced in the stored SPARQL code with a corresponding property value, prior to submitting the query to the Wikidata query service. Filters and their values are stored in a separate configuration table in the application back-end, and can be modified without changing source code.
components:
- back-end table "discover_filter". Stores the unique name of the filter tag used to insert the Wikidata property value at runtime. Accessed using the Django admin application.
- back-end table "discover_wdquery". Stores the SPARQL statements. Accessed using the admin application.
- sparql.py.
- web_models.'get_'. These functions retrieve SPARQL datasets and present them as python objects to Django templates.
Supporting Requirements: FR001 BR002
Description: This page provides an introduction to the Discovery tool in main body of the page. In the right-side panel, one or more charts will display statistics about UNLV holdings cataloged in Wikidata, such as the percentage distribution of resources based on entity type: human, collection, corporate body, etc.
Components:
- SPARQL queries for each chart, saved in the discover_wdquery table.
- sparql.py
- web_methods.py
- The external JavaScript library, Chart.js.
Supporting Requirements: FR001, FR011, FR013
Description: The Search engine retrieves in-scope Wikidata entities and maps the semantic relationships between them using shared property values. These results are rendered in list and graph form for every search against a Wikiframe application class. Currently, users initiate searches by typing keywords or key phrases that Wikidata uses to scan item labels and item descriptions for matches. Users can also select from a validated list of relevant facet values and combine those selections with keywords prior to search. Wikiframe supports one facet per application class: occupations for people; subjects for collections; subjects for oral histories; and instance-of for corporate bodies. Once a result set is returned, users can interact with the graph to perform new searches for a given entity or semantic relationship. Alternately the user can filter by one or more Subjects on the "Search by Subjects" page by selecting one or more subjects returned from keyword search. The selections are used to load the Collections_filtered page with all results available for the selected subjects. Processing done with the search engine also keeps the Search History Queue up to date.
Components:
- web_methods.reduce_search_results
- forms.SearchForm, forms.NodeSelectForm, and forms.RestrictSubjectForm.
- views.process_search
- other views.'process_' functions.
- mappings.py
- All application classes found in models.py, which interact with wikidata cached in the database back-end.
Supporting Requirements: FR003..., FR004, FR014, FR015
Description: This feature is presented to the user as four distinct tabs, one for each application class. Each landing page provides the keyword search bar and the search history queue select box, and there are context-appropriate instructions and suggestions for searching. Selected images relevant to each application class show under the controls. After the user performs a initial search, the graph of the results appears in enlarged view. The user must close the enlarged view to see both the result list alongside the fully interactive graph with its interactive search tools. Users have three options for accessing properties for a result: by hovering over its node in the graph; by clicking the 'full item details' hyperlink in the graph tooltip; by clicking the 'details' hyperlink for a result in the list.
Components:
- base_people.html, base_collections.html, base_orals.html, base_corps.html
- base_people_filtered.html, base_collections_filtered.html, base_orals_filtered.html, base_corps_filtered.html
- views.people, views.collections, views.oralhistories, views.corpbodies, views.item.
- views.process_search
- static/graph_functions.js
- static/filtered_head.js
- web_methods.'get_images_' functions
Requirements: FR003..., FR005, FR006, FR012...
This feature has been replaced by the faceted search capability for all application classes.
Description: The tools returns a master list of main subjects (P921) applied to items in the UNLV scope. This list can be searched, and its elements selected, to create filters of collections, oral histories, or corporate bodies.
NOTE: This feature currently works for collections only (version: dev.16). Support for displaying oral histories and corporate bodies will be included in a future release.
Components:
- forms.RestrictSubjectForm
- forms.SearchForm
- views.subjects
- views.subjects_filtered
Supporting Requirements: FR004, FR006, FR007
Description:This internal application service caches wikidata in the application database about People, Corporate Bodies, Collections, and Oral Histories. The cache is updated on a once-per-day schedule (see Automated Scheduler Utility). This improves application performance and reduces the load on the Wikidata SPARQL endpoint. The utility may also be run from the utilities page, accessible by administrators. Note that some queries are sent in real-time to the Wikidata query service based on user workflows.
Components:
- db.'cache_' functions.
- models.py - all application classes.
Supporting Requirements: FR004, FR006, TR001, TR004
Description: Wikiframe logs all errors in the system to the issue.log file, stored in the site directory. Since log files can become prohibitively long over time, the log rotation utility creates a new issue.log file once per day and saves the prior day's log file to issue.log.1. This process is repeated for a week's worth of logs, resulting in issue.log and issue.log.1 - issue.log.6
Components:
- logs.py
Supporting Requirements:
Description: The scheduler is built into Wikiframe and can run any function or method as a job. The scheduler currently runs on a daily cycle and tracks time on a per-minute basis. It runs all jobs currently in the scheduler queue that are scheduled to run at the given minute. The scheduler does not support future-day scheduling, e.g., run this job on May 2, 2024 at 9 am. The outcomes of all job runs are logs in the file, scheduler.log.
Components:
- wf_sched.py
- apps.py
- [app directory/scheduler.log
Supporting Requirements:
Description: captures information on both handled and unhandled exceptions. Exception information is written to the issue.log file in the website application directory.
Components:
- [app directory]/issue.log
- wd_utils.catch_err
Supporting Requirements: TR003
Description: The graph engine shows graphed links between related entities returned from a search. The links should correspond to one or more Wikidata properties, which the user selects in the interface before loading the graph view. For each discovery tool, there is a default property used to show links automatically after search results in a given tool are returned. However, the user can select one more other relationship properties to use in the graph. The properties provided depend on the given tool.
Components:
- graph.py
- The Vis.js external library
- graph_functions.js
- on-page JavaScript for rendering graph node property tooltips.
Supporting Requirements: FR003... TR002
Description: this will be a separate tab that can also be called from other tabs, e.g., Subjects. the top half of the panel will show all resources related to a given subject(s) inside UNLV's scope selected by the user. The bottom half will allow the user to query Wikidata outside of UNLV's scope to look for works (and possibly other resources) related to the selected subject(s).
Components: TBD
Supporting Requirements: FR015...
Description: For in-scope Wikidata entries that include coordinate or other spatial data (e.g., geonames URIs), this feature presents search results on a map as points/pins. The points should be labeled and interactive, so that users can navigate to item records. If date data is also included in the entry, the map will provide a time scale presentation. If the item data is faceted, a separate map layer and color theme are added to the map for each facet value, e.g., by type of organization on the Corporate Bodies page.
The present iteration of this feature does not support timescale, only labels for pins. Labels are zoom-dependent and only show at higher zoom levels. Also note that a given search result set may have both items with location data and items without. Consequently, some results may not render on the map.
Components:
- geog.py
- geog_functions.js
Supporting Requirements: FR008...
Description: The history queue keeps track of the three most recent searches the user has performed. Users access their history in the select box control underneath the keyword search bar. Once a historical search is reloaded, it becomes the most recent search and shows in the top of the search queue.
Components:
- Django session object
- forms.py
- queue_mgr.py
- views.verify_session
Supporting Requirements: FR014.
Description: this feature allows users to download the results of a given search operation. Currently available formats are JSON and CSV.
Components: TBD.
- views.process search
- views.create_download_file
Supporting Requirements: FR002