We have asked the researchers to reflect on this.

From the team's session notes:

It might be useful to have separate categories for Space/place. Ideally, this could be done on several levels: Poitiers  Monastery of Holy Cross at Poitiers  oratory at the Monastery of Holy Cross at Poitiers.

Question sent to the team on February 7th:

Distinguishing between different types of locations (e.g. political or clergical areas, buildings, general descriptors like "a cave") can help to make sense of this. We can also think of a "journey" as a kind of location onto itself. I think the primary use of locations will be as something tied to actions, so think of what information you would be adding here.

Letters often traveled via a route.

Add a new data model that at least marks the beginning and the end of a route.

Also add mode of travel (e.g. on foot, on camelback)?

Also add waypoints?

• Deploy the application
• Set up group permissions for researchers
• Add user accounts

(Discussed at the structuuroverleg of March 6th, 2024)

When we start to implement user authentication, we should set this op generically in such a way that we can use it in other, future cookiecutter-based applications.

We can take iAnalyzer as an example, where SAML is also implemented.

Berit indicated that she would be able help to extract the backend/Django part from iAnalyzer and turn it into a package.

Expand the list of action roles with "instigator"

The team felt there should be a layer in between individual (or 'atomic') actions performed on individual letters ('writing', 'delivering' etc.) and the overall grouping of all data in case studies (or 'sagas').

Actions should be grouped in a new category called 'Episodes' (vel sim.), which should in turn be grouped into 'Case Studies'.

When the application is published or otherwise ready to be cited/referenced, we should add it to Zenodo.

Since sources may contradict each other, each field of information about an entity show allow:

• multiple values
• any number of source references per value

The latter is already true in the database but can't be filled in in the admin form (references are only shown for people, letters, and actions).

However, the relationship between Field models and entities needs to be adjusted so we can add multiple values for each property.

Allowing contradictions will allow researchers to fill in data for a source, without conflicting with the work of other researchers (who are logging the same entry from a different source).

• Drop Senders, Addressees
• Drop Material
• Add designator (#57 )

Letter Actions should involve Packages rather than letters.

Packages contain 0 or more letters and/or 0 or more gifts.

This should describe letters that have been preserved, rather than letters that are described in narrative sources.

Suggestion to discuss further with the team:

• Rename Episode to Storyline(?)
• Rename EventDescription to Episode

(Note: from the presented notes, it appears that 'epistolary events' should refer to 'episodes', i.e. the collections of '(atomic) actions'.)

• The present box on the Role was not very useful because a single Epistolary Event could be broken up into several actions, and a person may well have been around for some but not all actions. With the new distinction between Epistolary Events + Letter Actions, this worry should be taken away.
• Add trigger field to indicate what triggered an epistolary event/episode: 'death of a bishop' etc. This should probably be a new model 'WorldEvent' or something like that.
• Add field related letters
• Add field keywords (Not sure whether this is a good idea, as a list of strings will be difficult to compare across events. Maybe we should use episodes for this)

- Add field relevant Latin terminology (Taken up in #21)
- Add field location/space (Taken up in #24)
- Add instigator field: useful for when a letter is sent, but not necessary written. (Taken up in #23 )

The backend is configured using settings.py. In production environments, we replace that file with the one in our deployment module.

However, some settings are going to be the same across development and production, like the list of Django apps. This can lead to errors when we inevitably forget to update the deployment module after a release.

We can define shared settings in a common_settings.py file and import them in both the development and production settings. See https://github.com/UUDigitalHumanitieslab/I-analyzer-django/pull/51 (private repository) for an example.

Currently, /api/graphql is exempt from CSRF.

We could solve this by sending CSRF-tokens along with every request, or by implementing a good user/permission system, which ensures that non-authenticated users are not able to query/mutate anything.

Show a basic "under construction" message in the frontend.

Not just in Agent, but also Location and Object.

• Add field gender
• Add field social status
• Add field occupation/office. This should be tied to a date (e.g. Boniface was only a bishop for part of his life).

I guess we might also add date of birth and date of death, allowing for the option unknown in case we don't have any clue.

• Change representation in Django Admin. Instead of "letter #57" there should be a name / one-line identifier so the team can quickly find/identify new letters, e.g. ('No. 60: Boniface to pope Zacharias in 578')
• Add sender
• Add addressee
• Add date
• Add type (e.g. 'friendship letter', 'consensus letter', 'royal order'). This could be an editable category in its own right?
• Instead of certainty, two new fields: historically_attested (letter features in actual, historical events vs. letter features in story/legend/fairytale) and mentioned: (letter is directly mentioned vs. existence of letter is implied/possible).

The LetterEventDate contains the basic data format for entering dates and includes a relation to letter actions.

We'll need to enter dates in other contexts, so it will be handy a DateField class in the core app that defines the format, global date range. We could also add some utility methods to the class to aggregate or display dates. Fields like LetterEventDate can inherit this class.

How do we link events to one another? How do we express causation? Is a field associated_events enough, or do we explicitly want to mark how events are related?

Field.certainty is somewhat superfluous now we have DescriptionField.source_mention as well.

We can remove Field.certainty, but it would be good to have a new model HistoricalField for fields attached to HistoricalEntity. This HistoricalField model should have a field certainty instead.

In the data entry interface, the episode overview should display the location of the episode in the text.

Rename EpistolaryEvent to Episode

does not need immediate attention as this is a later stage of analysis.

A view has been added for this in user/views.py, and the frontend has a button in place that makes a call to its associated endpoint, but currently nothing happens.

Allow adding the latin terminology used for something.

This is relevant on a lot of levels, so it probably makes sense to add this to the Field model, but it can also make sense for some "objects" such as letters.

Ask the team members which fields should be recorded on a Source object.

Our base model Date allows entering historical dates as a range when the exact data is not known.

A model like Occupation describes a period of time, which is currently also encoded as a single Date. This looks sort of sensible in the admin form, because you can fill in something like "between 450 and 470", but that doesn't allow researchers to encode uncertainty. Are we certain that this person held the office in 451? Or do we just know that they held the office at some point between 450 and 470?

In cases like this, we should really have a DateRange model (which may consist of two Date instances). A researcher should be able to encode something like "this person took this office between 445 and 455, and had that occupation until 470".

After selecting a source, loggers should be able to select/create Episodes. For each episode, the logger then fills in a summary, and the episode components: agents, locations, objects.

When connecting Agents/Objects/Locations to an Event, the logger should be able to pick from all already added entities for the selected Source, or add new ones.

For the frontend: add a side menu where all Episodes, Agents, Locations and Objects are listed. Loggers are free to switch between the lists and add entities in the order they see fit.

#36 introduces a data model for man-made "structures" which can range from towns to desks, and which can contain (or be contained by) other structures.

The model includes a draft division of structures into different levels (town, road, building, etc.), but we want to check if this works for the researchers and how they conceptualise spaces.

Data entry flow -- how would a research assistant enter new data into the database, starting from the sources.

1. Source overview => user selects/adds source
2. Entity overview (Agents / Objects / Places) => user selects/adds entity
3. Entity detail form => user enters details of agent/object/place as they occur in the source.
4. Uniquely identifiable: is the entity generic (e.g. 'a shepherd', 'a forest', 'a cask of beer') or unique identifiable ('St. Radegund', 'the monastery of Toulouse', 'the sceptre of Charlemagne')?
5. Link to existing records. (Should the research assistant do this, or will core team members do this?)

See photo below.

I am not sure how to implement the requested 'Social status' field on the Person model. We could use relative markers such as 'high'/'middle'/'low', but that feels too modern and not very insightful.

Presumably, social classes such as 'nobility', 'clergy', 'peasantry' are meant, but we should ask whether a fixed list will suffice or whether this is something they want to have control over.

This becomes relevant once we have more non-authentication routes.

• The user should be brought back to the page they were on when going through the logging flow.
• Route guards provide better UX.

It is difficult and annoying to work with an empty database.

At some point (when the data model is relatively stable), we might want to look into writing a short script that automatically adds a bunch of letters, persons, events etc.

The DIAPP (PortalDev) has an example of how to do this (using faker).

Separate the backend into apps to have smaller, more maintainable files.

E.g.

• core/shared
• person
• letter
• event

If we decide to build upon the ideas in #31 , we can split the models for Entities (Agents/Objects/Spaces) into two separate models: one for the entity as it is described in a particular source, and one for the actual historical entity that combines all source descriptions.

Allow logging something about the provenance of the information to the Field category

After #31 :

An example of how a detail page for an entity (e.g. St. Radegunde) would look after data from multiple sources has been logged. How are conflicting or corroborating data points represented? Also enable user to show/hide data from specific sources.

It's common that different settings connect to different models (in an applications where users have more to do) or that some things like changing your password/email have their own workflow for confirmation/verification.

So rather than using a single <form>, I usually to build a more modular settings menu.

For example, the user settings in LiNT are layed out like this:

My point is not about aesthetics, but the idea is to divide the page into several sections that can function as stand-alone components and use their own <form> (if applicable). For example, the change password option folds out into an old password / new password / repeat new password <form> that has its own submit event. This makes sense because (both here and in LiNT), changing your password connects to a different API endpoint from other settings.

Another advantage of dividing settings into several sub-components is that it's a component that can really grow out of control otherwise.

In this case, it would make sense to divide this page into the following sections:

• Username
• Personal details (i.e. first/last name)
• Email
• Password
• Delete account

Originally posted by @lukavdplas in #64 (comment)

It could be useful to have a larger field for an Event where Latin text can be pasted. This field could be hidden from database users, so there is no copyright infringement (is this even an issue?).

Ask whether this is a useful idea.

We should have a model for Groups of people. I guess users should also be allowed to indicate that individual Persons are part of a group.

Place (city, village)
Region (province, kingdom, Bavaria, bishopric)
Structure (castle, monastery, abbey)