DATABASE INTERFACE
The data entry workflow consists of three steps:
- Choose what you want to add or check (4 key entities: person, activity, work, place)
- Check if the record already exists in the database (searching by name/title)
- Add or edit the data
In the first step, you can choose between four key entities: person, activity, work, or place. Each entity has its own form and data structure.
In the second step, you can check if the record already exists in the database by searching for the name or title (the fetch field is automatically updated depending on which entity you chose in step 1).
In the third step, you can either add or edit the data.
If the record exists, you can edit it: the form automatically appears below, prefilled with the existing data (and with a summary table on the left side of the screen).
If the record does not exist, you can add a new one by filling out the form. The form will dynamically change based on the entity you selected in the first step.
There are few validation rules and check lists implemented:
- When fetching data (Step 2): a datalist function automatically shows records matching the name/title (also partial)
- Dates: the recommended format is DD-MM-YYYY, if the input is MM-YYYY or only YYYY there will be an alert (are you sure you want to submit a partial date?); any other format will not be accepted (error message).
- Place names: the datalist function will show places matching the name (also partial) and will suggest the closest match (based on place_name field in table "places", i.e. places that have been fully registered already).
- for debugging/exploring purposes: there are many logs, documenting each step (in the console for the javascript; in the google app for the google app script)
- relationships: if you add a work/activity departing from a person, relationship_type is controlled by an array created by me (i.e. you need to choose one of the existing terms)
- factoids now work
- If I mention a new person in a factoid, I'm prompted to record it in the people db
- automatic WikidataID for person_name works well
- graph visualisation is messy, attempting to show entities, factoids, and relationships (so a kitchen sink approach to networks/knowledge/whatever), but it allowed testing the endpoints and mapping the json in a decent way for d3.js viz
OPEN PROBLEMS FOR THE GROUP
- Data modelling questions: relationships / factoids / both (i.e. now there are relationships between pepole-activity-work-place + factoids)?
- theoretically, I could easily implement Geonames identifiers, fetching also country/lat/long (but it requires an account, and I don't want to expose my username on Github for long term; hence, not working right now)
- fetching RISM identifiers: is more complicated, it is possible to fetch MARC XML and then parse, apparently the API should give also JSON-LD but it is not so clear - but there are also ambiguities about names, etc. which could be problematic with automatic fetch and we would need to implement more controls...
- not a problem, but probably consider whether to reduce the alerts (and what to keep in console, what in alerts)
NEXT ON CHIARA TODO (TOTRY...):
- add zotero validation/linking
- consider whether to have more tables showing more data/related data/entitities, i.e. think about how to show records/relationships
- check if I can reduce my own code and use a google form for adding data instead (and my code will remain only for edit/viewing data eventually)
Step 1: What do you want to add or check
Do you want to check/add/edit a record about a person, an activity, a work, or a place?
Click on one of the following buttons to begin.
Step 2: Check if record already exists
Step 3: Add or edit data
On the left column, you see any record which we have for this person/activity/work/place. You can modify them in the right part of the screen.
In case we do not have any record, add a new one.