I spent a bit of time this week writing as second draft of a paper for DH2022 after receiving feedback from Marc. This one targets ‘short papers’ (500-750 words) and I managed to get it submitted before the deadline on Friday. Now I’ll just need to see if it gets accepted – I should find out one way or the other in February. I also made some further tweaks to the locution search for the Anglo-Norman Dictionary, ensuring that when a term appears more than once the result is repeated for each occurrence, appearing in the results grouped by each word that matches the term. So for example ‘quatre tempres, tens’ now appears twice, once amongst the ‘tempres’ and once amongst the ‘tens’ results.
I also had a chat with Heather Pagan about the Irish Dictionary eDIL (http://www.dil.ie/) who are hoping to rework the way they handle dates in a similar way to the AND. I said that it would be difficult to estimate how much time it would take without seeing their current data structure and getting more of an idea of how they intend to update it, and also what updates would be required to their online resource to incorporate the updated date structure, such as enhanced search facilities and whether further updates to their resource would also be part of the process. Also whether any back-end systems would also need to be updated to manage the new data (e.g. if they have a DMS like the AND).
Also this week I helped out with some issues with the Iona place-names website just before their conference started on Thursday. Someone had reported that the videos of the sessions were only playing briefly and then cutting out, but they all seemed to work for me, having tried them on my PC in Firefox and Edge and on my iPad in Safari. Eventually I managed to replicate the issue in Chrome on my desktop and in Chrome on my phone, and it seemed to be an issue specifically related to Chrome, and didn’t affect Edge, which is based on Chrome. The video file plays and then cuts out due to the file being blocked on the server. I can only assume that the way Chrome accesses the file is different to other browsers and it’s sending multiple requests to the server which is then blocking access due to too many requests being sent (the console in the browser shows a 403 Forbidden error). Thankfully Raymond at Arts IT Support was able to increase the number of connections allowed per browser and this fixed the issue. It’s still a bit of a strange one, though.
I also had a chat with the DSL people about when we might be able to replace the current live DSL site with the ‘new’ site, as the server the live site is on will need to be decommissioned soon. I also had a bit of a catch-up with Stevie Barrett, the developer in Celtic and Gaelic, and had a video call with Luca and his line-manager Kirstie Wild to discuss the current state of Digital Humanities across the College of Arts. Luca does a similar job to me at college-level and it was good to meet him and Kirstie to see what’s been going on outside of Critical Studies. I also spoke to Jennifer Smith about the Speak For Yersel project, as I’d not heard anything about it for a couple of weeks. We’re going to meet on Monday to take things further.
I spent the rest of the week working on the radar diagram visualisations for the Historical Thesaurus, completing an initial version. I’d previously created a tree browser for the thematic headings, as I discussed last week. This week I completed work on the processing of data for categories that are selected via the tree browser. After the data is returned the script works out which lexemes have dates that fall into the four periods (e.g. a word with dates 650-9999 needs to appear in all four periods). Words are split by Part of speech, and I’ve arranged the axes so that N, V, Aj and Av appear first (if present), with any others following on. All verb categories have also been merged.
I’m still not sure how widely useful these visualisations will be as they only really work for categories that have several parts of speech. But there are some nice ones. See for example a visualisation of ‘Badness/evil’, ‘Goodness, acceptability’ and ‘Mediocrity’ which shows words for ‘Badness/evil’ being much more prevalent in OE and ME while ‘Mediocrity’ barely registers, only for it and ‘Goodness, acceptability’ to grow in relative size EModE and ModE:
I also added in an option to switch between visualisations which use total counts of words in each selected category’s parts of speech and visualisations that use percentages. With the latter the scale is fixed at a maximum of 100% across all periods and the points on the axes represent the percentage of the total words in a category that are in a part of speech in your chosen period. This means categories of different sizes are more easy to compare, but does of course mean that the relative sizes of categories is not visualised. I could also add a further option that fixes the scale at the maximum number of words in the largest POS so the visualisation still represents relative sizes of categories but the scale doesn’t fluctuate between periods (e.g. if there are 363 nouns for a category across all periods then the maximum on the scale would stay fixed at 363 across all periods, even if the maximum number of nouns in OE (for example) is 128. Here’s the above visualisation using the percentage scale:
The other thing I did was to add in a facility to select a specific category and turn off the others. So for example if you’ve selected three categories you can press on a category to make it appear bold in the visualisation and to hide the other categories. Pressing on a category a second time reverts back to displaying all. Your selection is remembered if you change the scale type or navigate through the periods. I may not have much more time to work on this before Christmas, but the next thing I’ll do is to add in access to the lexeme data behind the visualisation. I also need to fix a bug that is causing the ModE period to be missing a word in its counts sometimes.
I spent a bit of time this week writing an abstract for the DH2022 conference. I wrote about how I rescued the data for the Anglo-Norman Dictionary in order to create the new AND website. The DH abstracts are actually 750-1000 words long so it took a bit of time to write. I have sent it on to Marc for feedback and I’ll need to run it by the AND editors before submission as well (if it’s worth submitting). I still don’t know whether there would be sufficient funds for me to attend the event, plus the acceptance rate for papers is very low, so I’ll just need to see how this develops.
Also this week I participated in a Zoom call for the DSL about user feedback and redeveloping the DSL website. It was a pretty lengthy call, but it was interesting to be a part of. Marc mentioned a service called Hotjar (https://www.hotjar.com/) that allows you to track how people use your website (e.g. tracking their mouse movements) and this seemed like an interesting way of learning about how an interface works (or doesn’t). I also had a conversation with Rhona about the updates to the DSL DNS that need to be made to improve the security or their email systems. Somewhat ironically, recent emails from their IT people had ended up in my spam folder and I hadn’t realised they were asking me for further changes to be made, which unfortunately has caused a delay.
I spoke to Gerry Carruthers about another new project he’s hoping to set up, and we’ll no doubt be having a meeting about this in the coming weeks. I also gave some advice to the students who are migrating the IJOSTS articles to WordPress too and made some updates to the Iona Placenames website in preparation for their conference.
For the Anglo-Norman Dictionary I fixed an issue with one of the textbase texts that had duplicate notes in one of its pages and then I worked on a new feature for the DMS that enables the editors to search the phrases contained in locutions in entries. Editors can either match locution phrases beginning with a term (e.g. ta*), ending with a term (e.g. *de) or without a wildcard the term can appear anywhere in the phrase. Other options found on the public site (e.g. single character wildcards and exact matches) are not included in this search.
The first time a search is performed the system needs to query all entries to retrieve only those that feature a locution. These results are then stored in the session for use the next time a search is performed. This means subsequent searches in a session should be quicker, and also means if the entries are updated between sessions to add or remove locutions the updates will be taken into consideration.
Search results work in a similar way to the old DMS option: Any matching locution phrases are listed, together with their translations if present (if there are multiple senses / subsenses for a locution then all translations are listed, separated by a ‘|’ character). Any cross references appear with an arrow and then the slug of the cross referenced entry. There is also a link to the entry the locution is part of, which opens in a new tab on the live site. A count of the total number of entries with locutions, the number of entries your search matched a phrase in and the total number of locutions is displayed above the results.
I spent the rest of the week working on the Speak For Yersel project. We had a Zoom call on Monday to discuss the mockups I’d been working on last week and to discuss the user interface that Jennifer and Mary would like me to develop for the site (previous interfaces were just created for test purposes). I spent the rest of my available time developing a further version of the grammar exercise with the new interface, that included logos, new fonts and colour schemes, sections appearing in different orders and an overall progress bar for the full exercise rather than individual ones for the questionnaire and the quiz sections.
I added in UoG and AHRC logos underneath the exercise area and added both an ‘About’ and ‘Activities’ menu items with ‘Activities’ as the active item. The active state of the menu wasn’t mentioned in the document but I gave it a bottom border and made the text green not blue (but the difference is not hugely noticeable). This is also used when hovering over a menu item. I made the ‘Let’s go’ button blue not green to make it consistent with the navigation button in subsequent stages. When a new stage loads the page now scrolls to the top as on mobile phones the content was changing but the visible section remained as it was previously, meaning the user had to manually scroll up. I also retained the ‘I would never say that!’ header in the top-left corner of all stages rather than having ‘activities’ so it’s clearer what activity the user is currently working on. For the map in the quiz questions I’ve added the ‘Remember’ text above the map rather than above the answer buttons as this seemed more logical and on the quiz the map pane scrolls up and scrolls down when the next question loads so as to make it clearer that it’s changed. Also, the quiz score and feedback text now scroll down one after the other and in the final ‘explore’ page the clicked on menu item now remains highlighted to make it clearer which map is being displayed. Here’s a screenshot of how the new interface looks:
I had an in-person meeting for the Historical Thesaurus on Tuesday this week – the first such meeting I’ve had since the first lockdown began. It was a much more enjoyable experience than Zoom-based calls and we had some good discussions about the current state of the HT and where we will head next. I’m going to continue to work on my radar chart visualisations when I have the time and we will hopefully manage to launch a version of the quiz before Christmas. There has also been some further work on matching categories and we’ll be looking into this in the coming months.
We also discussed the Digital Humanities conference, which will be taking place in Tokyo next summer. This is always a really useful conference for me to attend and I wondered about writing a paper about the redevelopment of the Anglo-Norman Dictionary. I’m not sure at this point whether we would be able to afford to send me to the conference, and the deadline for paper submission is the end of this month. I did start looking through these blog posts and I extracted all of the sections that relate to the redevelopment of the site. It’s almost 35,000 words over 74 pages, which shows you how much effort has gone into the redevelopment process.
I also had a meeting with Gerry Carruthers and others about the setting up of an archive for the International Journal of Scottish Theatre and Screen. I’d set up a WordPress site for this and explored how the volumes, issues and articles could be migrated over from PDFs. We met with the two students who will now do the work. I spent the morning before the meeting preparing an instruction document for the students to follow and at the meeting I talked through the processes contained in the document. Hopefully it will be straightforward for the students to migrate the PDFs, although I suspect it may take them an article or two before they get into the swing of things.
Also this week I fixed an issue with the search results tabs in the left-hand panel of the entry page on the DSL website. There’s a tooltip on the ‘Up to 1700’ link, but on narrow screens the tooltip was ending up positioned over the link, and when you pressed on it the code was getting confused as to whether you’d pressed on the link or the tooltip. I repositioned the tooltips so they now appear above the links, meaning they should no longer get in the way on narrow screens. I also looked into an issue with the DSL’s Paypal account, which wasn’t working. This turned out to be an issue on the Paypal side rather than with the links through from the DSL’s site.
I also had to rerun the varlist date scripts for the AND as we’d noticed that some quotations had a structure that my script was not set up to deal with. The expected structure is something like this:
<quotation>ou ses orribles pates paracrosçanz <varlist><ms_var id=””V-43aaf04a”” usevardate=””true””><ms_form>par acros</ms_form><ms_wit>BN</ms_wit><ms_date post=””1300″” pre=””1399″”>s.xiv<sup>in</sup></ms_date></ms_var></varlist> e par ateinanz e par encrés temptacions</quotation>
Where there is one varlist in the quotation, containing one or more ms_var tags. But the entry ‘purprestur’ has multiple separate varlists in the quotation:
<quotation>Endreit de purprestures voloms qe les nusauntes <varlist><ms_var id=””V-66946b02″”><ms_form>nusantes porprestures</ms_form><ms_wit>W</ms_wit><ms_date>s.xiv</ms_date></ms_var></varlist> soint ostez a coustages de ceux qi lé averount fet <varlist><ms_var id=””V-67f91f67″”><ms_form>des provours</ms_form><ms_wit>A</ms_wit><ms_date>s.xiv</ms_date></ms_var><ms_var id=””V-ea466d5e””><ms_form>des fesours</ms_form><ms_wit>W</ms_wit><ms_date>s.xiv</ms_date></ms_var><ms_var id=””V-88b4b5c2″” usevardate=””true””><ms_form>dé purpresturs</ms_form><ms_wit>M</ms_wit><ms_date post=””1300″” pre=””1310″”>s.xiv<sup>in</sup></ms_date></ms_var><ms_var id=””V-769400cd””><ms_form>des purpernours</ms_form><ms_wit>C</ms_wit><ms_date>s.xiv<sup>1/3</sup></ms_date></ms_var></varlist> </quotation>
I wasn’t aware that this was a possibility, so my script wasn’t set up to catch such situations. It therefore only looks at the first <varlist>. And the <ms_var> that needs to be used for dating isn’t contained in this, so gets missed. I therefore updated the script and have run both spreadsheets through it again. I also updated the DMS so that quotations with multiple varlists can be processed.
Also this week I updated all of the WordPress sites I manage and helped set up the Our Heritage, Our Stories site, and had a further discussion with Sofia about the conference pages for the Iona place-names project.
I spent the rest of the week continuing to work on the mockups for the Speak For Yerself project, creating a further mockup of the grammar quiz that now features all of the required stages. The ‘word choice’ type of question now has a slightly different layout, with buttons closer together in a block, and after answering the second question there is now an ‘Explore the answers’ button under the map. Pressing on this loads the summary maps for each question, which are not live maps yet, and underneath the maps is a button for starting the quiz. There isn’t enough space to have a three-column layout for the quiz so I’ve placed the quiz above the summary maps. The progress bar also gets reinstated for the quiz and I’ve added the text ‘Use the maps below to help you’ just to make it clearer what those buttons are for. The ‘Q1’, ‘Q2’ IDs will probably need to be altered as it just makes it look like the map refers to a particular question in the quiz, which isn’t the case. It’s possible to keep a map open between quiz questions, and when you press an answer button the ones you didn’t press get greyed out. If your choice is correct you get a tick, and if not you get a cross and the correct answer gets a tick. The script keeps track of what questions have been answered correctly in the background and I haven’t implemented a timer yet. After answering all of the questions (there doesn’t need to be 6 – the code will work with any number) you can finish the section, which displays your score and the ranking. Here is a screenshot of how the quiz currently looks:
I came down with some sort of stomach bug on Sunday and was off work with it on Monday and Tuesday. Thankfully I was feeling well again by Wednesday and managed to cram quite a lot into the three remaining days of the week. I spent about a day working on the Data Management Plan for the new Curious Travellers proposal, sending out a first draft on Wednesday afternoon and dealing with responses to the draft during the rest of the week. I also had some discussions with the Dictionaries of the Scots Language’s IT people about updating the DNS record regarding emails, responded to a query about the technology behind the SCOTS corpus, updated the images used in the mockups of the STAR website and created the ‘attendees only’ page for the Iona Placenames conference and added some content to it. I also had a conversation with one of the Books and Borrowing researchers about trimming out the blank pages from the recent page image upload, and I’ll need to write a script to implement this next week.
My main task of the week was to develop a test version of the ‘where is the speaker from?’ exercise for the Speak For Yersel project. This exercise involves the user listening to an audio clip and pressing a button each time they hear something that identifies the speaker as being from a particular area. In order to create this I needed to generate my own progress bar that tracks the recording as it’s played, implement ‘play’ and ‘pause’ buttons, implement a button that when pressed grabs the current point in the audio playback and places a marker in the progress bar, and implement a means of extrapolating the exact times of the button press to specific sections of the transcription of the audio file so we can ascertain which section contains the feature the user noted.
It took quite some planning and experimentation to get the various aspects of the feature working, but I managed to complete an initial version that I’m pretty pleased with. It will still need a lot of work but it demonstrates that we will be able to create such an exercise. The interface design is not final, it’s just there as a starting point, using the Bootstrap framework (https://getbootstrap.com), the colours from the SCOSYA logo and a couple of fonts from Google Fonts (https://fonts.google.com). There is a big black bar with a sort of orange vertical line on the right. Underneath this is the ‘Play’ button and what I’ve called the ‘Log’ button (but we probably want to think of something better). I’ve used icons from Font Awesome (https://fontawesome.com/) including a speech bubble icon in the ‘log’ button.
As discussed previously, when you press the ‘Play’ button the audio plays and the orange line starts moving across the black area. The ‘Play’ button also turns into a ‘Pause’ button. The greyed out ‘Log’ button becomes active when the audio is playing. If you press the ‘Log’ button a speech bubble icon is added to the black area at the point where the orange ‘needle’ is.
For the time being for each click the script looks through the transcript data to find an entry where the click time is between the entry’s start and end times. A tally of clicks for each transcript entry is then stored. This then gets outputted in the footer so you can see how things are getting worked out. This is of course just test data – we’ll need smaller transcript areas for the real thing. Currently nothing gets submitted to the server or stored – it’s all just processed in the browser. I’ve tested the page out in several browsers in Windows, on my iPad and on my Android phone and the interface works perfectly well on mobile phone screens. Below is a screenshot showing audio playback and four linguistic features ‘logged’:
Also this week I had a conversation with the editor of the AND about updating the varlist dates. I also updated the DTD to allow the new ‘usevardate’ attribute to be used to identify occasions where a varlist date should be used as the earliest citation date. We also became aware that a small number of entries in the online dictionary are referencing an old DTD on the wrong server so I updated these.
I was back at work this week after having a lovely holiday in Northumberland last week. I spent quite a bit of time in the early part of the week catching up with emails that had come in whilst I’d been off. I fixed an issue with Bryony Randall’s https://imprintsarteditingmodernism.glasgow.ac.uk/ site, which was put together by an external contractor, but I have now inherited. The site menu would not update via the WordPress admin interface and after a bit of digging around in the source files for the theme it would appear that the theme doesn’t display a menu anywhere, that is the menu which is editable from the WordPress Admin interface is not the menu that’s visible on the public site. That menu is generated in a file called ‘header.php’ and only pulls in pages / posts that have been given one of three specific categories: Commissioned Artworks, Commissioned Text or Contributed Text (which appear as ‘Blogs’). Any post / page that is given one of these categories will automatically appear in the menu. Any post / page that is assigned to a different category or has no assigned category doesn’t appear. I added a new category to the ‘header’ file and the missing posts all automatically appeared in the menu.
I also updated the introductory texts in the mockups for the STAR websites and replied to a query about making a place-names website from a student at Newcastle. I spoke to Simon Taylor about a talk he’s giving about the place-name database and gave him some information on the database and systems I’d created for the projects I’ve been involved with. I also spoke to the Iona Place-names people about their conference and getting the website ready for this.
I also had a chat with Luca Guariento about a new project involving the team from the Curious Travellers project. As this is based in Critical Studies Luca wondered whether I’d write the Data Management Plan for the project and I said I would. I spent quite a bit of time during the rest of the week reading through the bid documentation, writing lists of questions to ask the PI, emailing the PI, experimenting with different technologies that the project might use and beginning to write the Plan, which I aim to complete next week.
The project is planning on running some pre-digitised images of printed books through an OCR package and I investigated this. Google owns and uses a program called Tesseract to run OCR for Google Books and Google Docs and it’s freely available (https://opensource.google/projects/tesseract). It’s part of Google Docs – if you upload an image of text into Google Drive then open it in Google Docs the image will be automatically OCRed. I took a screenshot of one of the Welsh tour pages (https://viewer.library.wales/4690846#?c=&m=&s=&cv=32&manifest=https%3A%2F%2Fdamsssl.llgc.org.uk%2Fiiif%2F2.0%2F4690846%2Fmanifest.json&xywh=-691%2C151%2C4725%2C3632) and cropped the text and then opened it in Google Docs and even on this relatively low resolution image the OCR results are pretty decent. It managed to cope with most (but not all) long ‘s’ characters and there are surprisingly few errors – ‘Englija’ and ‘Lotty’ are a couple and have been caused by issues with the original print quality. I’d say using Tesseract is going to be suitable for the project.
I spent a bit of time working on the Speak For Yersel project. We had a team meeting on Thursday to go through in detail how one of the interactive exercises will work. This one will allow people to listed to a sound clip and then relisten to it in order to click whenever they hear something that identifies the speaker as coming from a particular location. Before the meeting I’d prepared a document giving an overview of the technical specification of the feature and we had a really useful session discussing the feature and exactly how it should function. I’m hoping to make a start on a mockup of the feature next week.
Also for the project I’d enquired with Arts IT Support as to whether the University held a license for ArcGIS Online, which can be used to publish maps online. It turns out that there is a University-wide license for this which is managed by the Geography department and a very helpful guy called Craig MacDonell arranged for me and the other team members to be set up with accounts for it. I spent a bit of time experimenting with the interface and managed to publish a test heatmap based on data from SCOSYA. I can’t get it to work directly with the SCOSYA API as it stands, but after exporting and tweaking one of the sets of rating data as a CSV I pretty quickly managed to make a heatmap based on the ratings and publish it: https://glasgow-uni.maps.arcgis.com/apps/instant/interactivelegend/index.html?appid=9e61be6879ec4e3f829417c12b9bfe51 This is just a really simple test, but we’d be able to embed such a map in our website and have it pull in data dynamically from CSVs generated in real-time and hosted on our server.
Also this week I had discussions with the Dictionaries of the Scots Language people about how dates will be handled. Citation dates are being automatically processed to add in dates as attributes that can then be used for search purposes. Where there are prefixes such as ‘a’ and ‘c’ the dates are going to be given ranges based on values for these prefixes. We had a meeting to discuss the best way to handle this. Marc had suggested that having a separate prefix attribute rather than hard coding the resulting ranges would be best. I agreed with Marc that having a ‘prefix’ attribute would be a good idea, not only because it means we can easily tweak the resulting date ranges at a later point rather than having them hard-coded, but also because it then gives us an easy way to identify ‘a’, ‘c’ and ‘?’ dates if we ever want to do this. If we only have the date ranges as attributes then picking out all ‘c’ dates (e.g. show me all citations that have a date between 1500 and 1600 that are ‘c’) would require looking at the contents of each date tag for the ‘c’ character which is messier.
A concern was raised that not having the exact dates as attributes would require a lot more computational work for the search function, but I would envisage generating and caching the full date ranges when the data is imported into the API so this wouldn’t be an issue. However, there is a potential disadvantage to not including the full date range as attributes in the XML, and this is that if you ever want to use the XML files in another system and search the dates through it the full ranges would not be present in the XML so would require processing before they could be used. But whether the date range is included in the XML or not I’d say it’s important to have the ‘prefix’ as an attribute, unless you’re absolutely sure that being able to easily identify dates that have a particular prefix isn’t important.
We decided that prefixes would be stored as attributes and that the date ranges for dates with a prefix would be generated whenever the data is exported from the DSL’s editing system, meaning editors wouldn’t have to deal with noting the date ranges and all the data would be fully usable without further processing as soon as it’s exported.
Also this week I was given access to a large number of images of registers from the Advocates Library that had been digitised by the NLS. I downloaded these, batch processed them to add in the register numbers as a prefix to the filenames, uploaded the images to our server, created register records for each register and page records for each page. The registers, pages and associated images can all now be accessed via our CMS.
My final task of the week was to continue work on the Anglo-Norman Dictionary. I completed work on the script identifies which citations have varlists and which may need to have their citation date updated based on one of the forms in the varlist. What the script does is to retrieve all entries that have a <varlist> somewhere in them. It then grabs all of the forms in the <head> of the entry. It then goes through every attestation (main sense and subsense plus locution sense and subsense) and picks out each one that has a <varlist> in it.
For each of these it then extracts the <aform> if there is one, or if there’s not then it extracts the final word before the <varlist>. It runs a Levenshtein test on this ‘aform’ to ascertain how different it is from each of the <head> forms, logging the closest match (0 = exact match of one form, 1 = one character different from one of the forms etc). It then picks out each <ms_form> in the <varlist> and runs the same Levenshtein test on each of these against all forms in the <head>.
If the score for the ‘aform’ is lower or equal to the lowest score for an <ms_form> then the output is added to the ‘varlist-aform-ok’ spreadsheet. If the score for one of the <ms_form> words is lower than the ‘aform’ score the output is added to the ‘varlist-vform-check’ spreadsheet.
My hope is that by using the scores we can quickly ascertain which are ok and which need to be looked at by ordering the rows by score and dealing with the lowest scores first. In the first spreadsheet there are 2187 rows that have a score of 0. This means the ‘aform’ exactly matches one of the <head> forms. I would imagine that these can safely be ignored. There are a further 872 that have a score of 1, and we might want to have a quick glance through these to check they can be ignored, but I suspect most will be fine. The higher the score the greater the likelihood that the ‘aform’ is not the form that should be used for dating purposes and one of the <varlist> forms should instead. These would need to be checked and potentially updated.
The other spreadsheet contains rows where a <varlist> form has a lower score than the ‘aform’ – i.e. one of the <varlist> forms is closer to one of the <head> forms than the ‘aform’ is. These are the ones that are more likely to have a date that needs updated. The ‘Var forms’ column lists each var form and its corresponding score. It is likely that the var form with the lowest score is the form that we would need to pick the date out for.
In terms of what the editors could do with the spreadsheets: My plan was that we’d add an extra column to note whether a row needs updated or not – maybe called ‘update’ – and be left blank for rows that they think look ok as they are and containing a ‘Y’ for rows that need to be updated. For such rows they could manually update the XML column to add in the necessary date attributes. Then I could process the spreadsheet in order to replace the quotation XML for any attestations that needs updated.
For the ‘vform-check’ spreadsheet I could update my script to automatically extract the dates for the lowest scoring form and attempt to automatically add in the required XML attributes for further manual checking, but I think this task will require quite a lot of manual checking from the onset so it may be best to just manually edit the spreadsheet here too.
I spent a fair amount of time on the new ‘Speak for Yersel’ project this week, reading through materials produced by similar projects, looking into ArcGIS Online as a possible tool to use to create the map-based interface and thinking through some of the technical challenges the project will face. I also participated in a project Zoom call on Thursday where we discussed the approaches we might take and clarified the sorts of outputs the project intends to produce.
I also had further discussions with the Sofia from the Iona place-names project about their upcoming conference in December and how the logistics for this might work, as it’s going to be an online-only conference. I had a Zoom call with Sofia on Thursday to go through these details, which really helped us to shape up a plan. I also dealt with a request from another project that wants to set up a top-level ‘ac.uk’ domain, which makes three over the past couple of weeks, and make a couple of tweaks to the text of the Decadence and Translation website.
I had a chat with Mike Black about the new server that Arts IT Support are currently setting up for the Anglo-Norman Dictionary and had a chat with Eleanor Lawson about adding around 100 or so Gaelic videos to the Seeing Speech resource on a new dedicated page.
For the Books and Borrowing project I was sent a batch of images of a register from Dumfries Presbytery Library and I needed to batch process them in order to fix the lighting levels and rename them prior to upload. It took me a little time to figure out how to run a batch process in the ancient version of Photoshop I have. After much hopeless Googling I found some pages from ‘Photoshop CS2 For Dummies’ on Google Books that discussed Photoshop Actions (see https://books.google.co.uk/books?id=RLOmw2omLwgC&lpg=PA374&dq=&pg=PA332#v=onepage&q&f=false) which made me realise the ‘Actions’, which I’d failed to find in any of the menus, were available via the tabs on the right of the screen, and I could ‘record’ and action via this. After running the images through the batch I uploaded them to the server and generated the page records for each corresponding page in the register.
I spent the rest of the week working on the Anglo-Norman Dictionary, considering how we might be able to automatically fix entries with erroneous citation dates caused by a varlist being present in the citation with a different date that should be used instead of the main citation date. I had been wondering whether we could use a Levenshtein test (https://en.wikipedia.org/wiki/Levenshtein_distance) to automatically ascertain which citations may need manual editing, or even as a means of automatically adding in the new tags after testing. I can already identify all entries that feature a varlist, so I can create a script that can iterate through all citations that have a varlist in each of these entries. If we can assume that the potential form in the main citation always appears as the word directly before the varlist then my script can extract this form and then each <ms_form> in the <varlist>. I can also extract all forms listed in the <head> of the XML.
So for example for https://anglo-norman.net/entry/babeder my script would extract the term ‘gabez’ from the citation as it is the last word before <varlist>. It would then extract ‘babedez’ and ‘bauboiez’ from the <varlist>. There is only one form for this entry: <lemma>babeder</lemma> so this would get extracted too. The script would then run a Levenshtein test on each possible option, comparing them to the form ‘babeder’, the results of which would be:
The script would then pick out ‘babedez’ as the form to use (only one character different to the form ‘babeder’) and would then update the XML to note that the date from this <ms_form> is the one that needs to be used.
With a more complicated example such as https://anglo-norman.net/entry/bochet_1 that has multiple forms in <head> the test would be run against each and the lowest score for each variant would be used. So for example for the citation where ‘buchez’ is the last word before the <varlist> the two <ms_form> words would be extracted (huchez and buistez) and these plus ‘buchez’ would be compared against every form in <head>, with the overall lowest Leveshtein score getting logged. The overall calculations in this case would be:
bochet = 2
boket = 4
bouchet = 2
bouket = 4
bucet = 2
buchet = 1
buket = 3
bokés = 5
boketes = 5
bochésç = 6
buchees = 2
bochet = 3
boket = 5
bouchet = 3
bouket = 5
bucet = 3
buchet = 2
buket = 4
bokés = 6
boketes = 6
bochésç = 7
buchees = 3
bochet = 5
boket = 5
bouchet = 5
bouket = 5
bucet = 4
buchet = 4
buket = 4
bokés = 6
boketes = 4
bochésç = 8
buchees = 4
Meaning ‘buchez’ would win with a score of 1 and in this case no <varlist> form would therefore be marked. If the main citation form and a varlist form both have the same lowest score then I guess we’d set it to the main citation form ‘winning’, although in such cases the citation could be flagged for manual checking. However, this algorithm does entirely depend on the main citation form being the word before the <varlist> tag and the editor confirmed that this is not always the case, but despite this I think the algorithm could correctly identify the majority of cases, and if the output was placed in a CSV it would then be possible for someone to quickly check through each citation and tick off those that should be automatically updated and manually fix the rest. I made a start on the script that would work through all of the entries and output the CSV during the remainder of the week, but didn’t have the time to finish it. I’m going to be on holiday next week but will continue with this when I return.
I had two Zoom calls on Monday this week. The first was with the Burns people to discuss the launch of the website for the ‘letters and poems’ part of ‘Editing Burns’, to complement the existing ‘Prose and song’ website (https://burnsc21.glasgow.ac.uk/). The new website will launch in January with some video content and blogs, plus I will be working on a content management system for managing the network of Burns’ letter correspondents, which I will put together some time in November, assuming the team can send me on some sample data by then. This system will eventually power the ‘Burns letter writing trail’ interactive maps that I’ll create for the new site sometime next year.
My second Zoom call was for the Books and Borrowing project to discuss adding data from a new source to the database. The call gave us an opportunity to discuss the issues with the data that I’d highlighted last week. It was good to catch up with the team again and to discuss the issues with the researcher who had originally prepared the spreadsheet containing the data. We managed to address all of the issues and the researcher is going to spend a bit of time adapting the spreadsheet before sending it to me to be batch uploaded into our system.
I spent some further time this week investigating the issue of some of the citation dates in the Anglo-Norman Dictionary being wrong, as discussed last week. The issue affects some 4309 entries where at least one citation features the form only in a variant text. This means that the citation date should not be the date of the manuscript in the citation, but the date when the variant of the manuscript was published. Unfortunately this situation was never flagged in the XML, and there was never any means of flagging the situation. The variant date should only ever be used when the form of the word in the main manuscript is not directly related to the entry in question but the form in the variant text is. The problem is it cannot be automatically ascertained when the form in the main manuscript is the relevant one and when the form in the variant text is as there is so much variation in forms.
For example, the entry https://anglo-norman.net/entry/bochet_1 there is a form ‘buchez’ in a citation and then two variant texts for this where the form is ‘huchez’ and ‘buistez’. None of these forms are listed in the entry’s XML as variants so it’s not possible for a script to automatically deduce which is the correct date to use (the closest is ‘buchet’). In this case the main citation form and its corresponding date should be used. Whereas in the entry https://anglo-norman.net/entry/babeder the main citation form is ‘gabez’ while the variant text has ‘babedez’ and so this is the form and corresponding date that needs to be used. It would be difficult for a script to automatically deduce this. In this case a Levenstein test (which test how many letters need to be changed to turn one string into another) could work, but this would still need to be manually checked.
The editor wanted me to focus on those entries where the date issue affects the earliest date for an entry, as these are the most important as the issue results in an incorrect date being displayed for the entry in the header and the browse feature. I wrote a script that finds all entries that feature ‘<varlist’ somewhere in the XML (the previously exported 4309 entries). It then goes through all attestations (in all sense, subsense and locution sense and subsense sections) to pick out the one with the earliest date, exactly as the code for publishing an entry does. What it then does is checks the quotation XML for the attestation with the earliest date for the presence of ‘<varlist’ and if it finds this it outputs information for the entry, consisting of the slug, the earliest date as recorded in the database, the earliest date of the attestation as found by the script, the ID of the attestation and then the XML of the quotation. The script has identified 1549 entries that have a varlist in the earliest citation, all of which will need to be edited.
However, every citation has a date associated with it and this is used in the advanced search where users have the option to limit their search to years based on the citation date. Only updating citations that affect the entry’s earliest date won’t fix this, as there will still be many citations with varlists that haven’t been updated and will still therefore use the wrong date in the search. Plus any future reordering of citations would require all citations with varlists to be updated to get entries in the correct order. Fixing the earliest citations with varlists in entries based on the output of my script will fix the earliest date as used in the header of the entry and the ‘browse’ feature only, but I guess that’s a start.
Also this week I sorted out some access issues for the RNSN site, submitted the request for a new top-level ‘ac.uk’ domain for the STAR project and spent some time discussing the possibilities for managing access to videos of the conference sessions for the Iona place-names project. I also updated the page about the Scots Dictionary for Schools app on the DSL website (https://dsl.ac.uk/our-publications/scots-dictionary-for-schools-app/) after it won the award for ‘Scots project of the year’.
I also spent a bit of time this week learning about the statistical package R (https://www.r-project.org/). I downloaded and installed the package and the R Studio GUI and spent some time going through a number of tutorials and examples in the hope that this might help with the ‘Speak for Yersel’ project.
For a few years now I’ve been meaning to investigate using a spider / radar chart for the Historical Thesaurus, but I never found the time. I unexpectedly found myself with some free time this week due to ‘Speak for Yersel’ not needing anything from me yet so I thought I’d do some investigation. I found a nice looking d3.js template for spider / radar charts here: http://bl.ocks.org/nbremer/21746a9668ffdf6d8242 and set about reworking it with some HT data.
My idea was to use the chart to visualise the distribution of words in one or more HT categories across different parts of speech in order to quickly ascertain the relative distribution and frequency of words. I wanted to get an overall picture of the makeup of the categories initially, but to then break this down into different time periods to understand how categories changed over time.
As an initial test I chose the categories 02.04.13 Love and 02.04.14 Hatred, and in this initial version I looked only at the specific contents of the categories – no subcategories and no child categories. I manually extracted counts of the words across the various parts of speech and then manually split them up into words that were active in four broad time periods: OE (up to 1149), ME (1150-1449), EModE (1450-1799) and ModE (1800 onwards) and then plotted them on the spider / radar chart, as you can see in this screenshot:
You can quickly move through the different time periods plus the overall picture using the buttons above the visualisation, and I think the visualisation does a pretty good job of giving you a quick and easy to understand impression of how the two categories compare and evolve over time, allowing you to see, for example, how the number of nouns and adverbs for love and hate are pretty similar in OE:
but by ModE the number of nouns for Love have dropped dramatically, as have the number of adverbs for Hate:
We are of course dealing with small numbers of words here, but even so it’s much easier to use the visualisation to compare different categories and parts of speech than it is to use the HT’s browse interface. Plus if such a visualisation was set up to incorporate all words in child categories and / or subcategories it could give a very useful overview of the makeup of different sections of the HT and how they develop over time.
There are some potential pitfalls to this visualisation approach, however. The scale used currently changes based on the largest word count in the chosen period, meaning unless you’re paying attention you might get the wrong impression of the number of words. I could change it so that the scale is always fixed as the largest, but that would then make it harder to make out details in periods that have much fewer words. Also, I suspect most categories are going to have many more nouns than other parts of speech, and a large spike of nouns can make it harder to see what’s going on with the other axes. Another thing to note is that the order of the axes is fairly arbitrary but can have a major impact on how someone may interpret the visualisation. If you look at the OE chart the ‘Hate’ area looks massive compared to the ‘Love’ area, but this is purely because there is only one ‘Love’ adjective compared to 5 for ‘Hate’. If the adverb axis had come after the noun one instead the shapes of ‘Love’ and ‘Hate’ would have been more similar. You don’t necessarily appreciate on first glance that ‘Love’ and ‘Hate’ have very similar numbers of nouns in OE, which is concerning. However, I think the visualisations have a potential for the HT and I’ve emailed the other HT people to see what they think.
This was a four-day week for me as I’d taken Friday off. I went into my office at the University on Tuesday to have my Performance and Development Review with my line-manager Marc Alexander. It was the first time I’d been at the University since before the summer and it felt really different to the last time – much busier and more back to normal, with lots of people in the building and a real bustle to the West End. My PDR session was very positive and it was great to actually meet a colleague in person again – the first time I’d done so since the first lockdown began. I spent the rest of the day trying to get my office PC up to date after months of inaction. One of the STELLA apps (the Grammar one) had stopped working on iOS devices, seemingly because it was still a 32-bit app, and I wanted to generate a new version of it. This meant upgrading MacOS on my dual-boot PC, which I hadn’t used for years and was very out of date. I’m still not actually sure whether the Mac I’ve got will support a version of MacOS that will allow me to engage in app development, as I need to incrementally upgrade the MacOS version, which takes quite some time, and by the end of the day there were still further updates required. I’ll need to continue with this another time.
I spent quite a bit of the remainder of the week working on the new ‘Speak for Yersel’ project. We had a team meeting on Monday and a follow-up meeting on Wednesday with one of the researchers involved in the Manchester Voices project (https://www.manchestervoices.org/) who very helpfully showed us some of the data collection apps they use and some of the maps that they generate. It gave us a lot to think about, which was great. I spent some further time looking through other online map examples, such as the New York Times dialect quiz (https://www.nytimes.com/interactive/2014/upshot/dialect-quiz-map.html) and researching how we might generate the maps we’d like to see. It’s going to take quite a bit more research to figure out how all of this is going to work.
Also this week I spoke to the Iona place-names people about how their conference in December might be moved online and fixed a permissions issue with the Imprints of New Modernist Editing website and discussed the domain name for the STAR project with Eleanor Lawson. I also had a chat with Luca Guariento about the restrictions we have on using technologies on the servers in the College of Arts and how this might be addressed.
I also received a spreadsheet of borrowing records covering five registers for the Books and Borrowing project and went through it to figure out how the data might be integrated with our system. The biggest issue is figuring out which page each record is on. In the B&B system each borrowing record must ‘belong’ to a page, which in turn ‘belongs’ to a register. If a borrowing record has no page it can’t exist in the system. In this new data only three registers have a ‘Page No.’ column and not every record in these registers has a value in this column. We’ll need to figure out what can be done about this, because as I say, having a page is mandatory in the B&B system. We could use the ‘photo’ column as this is present across all registers and every row. However, I noticed that there are multiple photos per page, e.g. for SL137144 page 2 has 2 photos (4538 and 4539) so photo IDs don’t have a 1:1 relationship with pages. If we can think of a way to address the page issue then I should be able to import the data.
Finally, I continued to work on the Anglo-Norman Dictionary project, fixing some issues relating to yoghs in the entries and researching a potentially large issue relating to the extraction of earliest citation dates. Apparently there are a number of cases when the date for a citation that should be used is not the date as coded in the date section of the citation’s XML, but should instead be a date taken from a manuscript containing a variant form within the citation. The problem is there is no flag to state when this situation occurs, instead it occurs whenever the form of the word in the citation is markedly different within the citation but similar in the variant text. It seems unlikely that an automated script would be able to ascertain when to use the variant date as there is just so much variation between the forms. This will need some further investigation, which I hope to be able to do next week.
I then spent some time investigating why part of speech in the <senseInfo> element of senses sometimes used underscores and other times used spaces. This discrepancy was messing up the numbering of senses, as this depends on the POS, with the number resetting to 1 when a new POS is encountered. If the POS is sometimes recorded as ‘p.p._as_a.’ (for example) and other times as ‘p.p. as a.’ then the code thinks these are different parts of speech and resets the counter to 1. I looked at the DTD, which sets the rules for creating or editing the XML files and it uses the underscore form of POS. However, this rule only applies to the ‘type’ attribute of the <pos> element and not to the ‘pos’ attribute of the <senseInfo> element. After investigating it turned out that these ‘pos’ attributes that the numbering system relies on are not manually added in by the editors, but are added in by my scripts at the point of upload. The reason I set up my script to add these in is because the old systems also added these in automatically during the conversion of the editors’ XML into the XML published via the old Dictionary Management System. However, this old system refactored the POS, replacing underscores with spaces and thus storing two different formats of POS within the XML. My upload scripts didn’t do this but instead kept things consistent, and this meant that when an entry was edited to add a new sense the new sense was added with the underscore form of POS, but the existing senses still had the space form of POS.
There were two possible ways I could fix this, I could either write a script that regenerates the <senseInfo> pos for every sense and subsense in every entry, replacing all existing ‘pos’ with the value of the preceding <pos type=””> (i.e. removing all old space forms of POS and ensuring all POS references were consistent); or I could adapt my upload script so that the assignment of <senseInfo> pos treats both ‘underscore’ and ‘space’ versions as the same. I decided on the former approach and wrote a script to first identify and then update all of the dictionary entries.
The script goes through each entry and finds all that have a <senseInfo> pos with a space in. There are 2,538 such entries. I then adapted the script so that for each <senseInfo> in an entry all spaces are changed to underscores and the result is then compared with the preceding <pos> type. I set the script to output content if there was a mismatch between the <senseInfo> pos and the <pos> type, because when I set the script to update it will use the value from <pos> type, so as to ensure consistency. The script identified 41 entries where there was a mismatch between <senseInfo> pos and the preceding <pos> type. These were often due to a question mark being added to the <senseInfo> pos, e.g. ‘a. as s. ?’ vs ‘a._as_s._’, but there were also some where the POS was completely different, e.g. ‘sbst. inf.’ and ‘v.n.’. I spoke to the editor Geert about this and it turned out that these were due to a locution being moved in the XML without having the pos value updated. Geert fixed these and I ran the update to bring all of the POS references into alignment.
My final AND task was to look into some issues regarding the variant and deviant section of the entry (where alternative forms of the headword are listed). Legiturs in this section were not getting displayed, plus there were several formatting issues that needed addressed, such as brackets not appearing in the right place and line breaks not worked as they should. This was a very difficult task to tackle as there is so much variety to the structure of this section, and the XML is not laid out in the most logical of manners, for example references are not added as part of a <variant> or <deviant> tag but are added after the corresponding tag as a sibling <varref> element. This really complicates navigating through the variants and deviants as there may be any number of varrefs at the same level. However, I managed to address the issues with this section, ensuring the legiturs appeared, repositioning semi-colons outside of the <deviant> brackets, ensuring line breaks always occur when a new POS is encountered and don’t occur anywhere else, ensuring multiple occurrences of the same POS label don’t get displayed and fixing the issue with double closing brackets sometimes appearing. It’s likely that there will be other issues with this section, as the content and formatting is so varied, but for now that’s all issues sorted.
The only other project I worked for this week was the Iona place-names project, for which I helped the RA Sofia with the formatting of this month’s ‘name of the month’ feature (https://iona-placenames.glasgow.ac.uk/names-of-the-month/). Next week I’ll continue with the outstanding AND tasks, of which there are still several.
I continued with the import of new data for the Dictionary of the Scots Language this week. Raymond at Arts IT Support has set up a new collection and had imported the full-text search data into the Solr server, and I tested this out via the new front-end I’d configured to work with the new data source. I then began working on the import of the bibliographical data, but noticed that the file exported from the DSL’s new editing system didn’t feature an attribute denoting what source dictionary each record is from. We need this as the bibliography search allows users to limit their search to DOST or SND. The new IDs all start with ‘bib’ no matter what the source is. I had thought I could use the ‘oldid’ to extract the source (db = DOST, sb = SND) but I realised there are also composite records where the ‘oldid’ is something like ‘a200’. In such cases I don’t think I have any data that I can use to distinguish between DOST and SND records. The person in charge of exporting the data from the new editing system very helpfully agreed to add in a ‘source dictionary’ attribute to all bibliographical records and sent me an updated version of the XML file. Whilst working with the data I realised that all of the composite records are DOST records anyway, so I didn’t need the ‘sourceDict’ attribute, but I think it’s better to have this explicitly as an attribute as differentiating between dictionaries is important.
I imported all of the bibliographical records into the online system, including the composite ones as these are linked to from dictionary entries and are therefore needed, even though their individual parts are also found separately in the data. However, I decided to exclude the composite records from the search facilities, otherwise we’d end up with duplicates in the search results. I updated the API to use the new bibliography tables and I updated the new front-end so that bibliographical searches use the new data. One thing that needs some further work is the display of individual bibliographies. These are now generated from the bibliography XML via an XSLT whereas previously they were generated from a variety of different fields in the database. The display doesn’t completely match up with the display on the live and Sienna versions of the bibliography pages and I’m not sure exactly how the editors would like entries to be displayed. I’ll need further input from them on this matter, but the import of data from the new editing system has now been completed successfully. I’d been documenting the process as I worked through it and I sent the documentation and all scripts I wrote to handle the workflow to the editors to be stored for future use.
I also worked on the Books and Borrowing project this week. I received the last of the digitised images of borrowing registers from Edinburgh (other than one register which needs conservation work), and I uploaded these to the project’s content management system, creating all of the necessary page records. We have a total of 9,992 page images as JPEG files from Edinburgh, totalling 105GB. Thank goodness we managed to set up an IIIF server for the image files rather than having to generate and store image tilesets for each of these page images. Also this week I uploaded the images for 14 borrowing registers from St Andrews and generated page records for each of these.
I had a further conversation with GIS expert Piet Gerrits for the Iona project and made a couple of tweaks to the Comparative Kingship content management systems, but other than that I spent the remainder of the week returning to the Anglo-Norman Dictionary, which I hadn’t worked on since before Easter. To start with I went back through old emails and documents and wrote a new ‘to do’ list containing all of the outstanding tasks for the project, some 20 items of varying degrees of size and intricacy. After some communication with the editors I began tackling some of the issues, beginning with the apparent disappearance of <note> tags from certain entries.
In the original editor’s XML (the XML as structured before uploaded into the old DMS) there were ‘edGloss’ notes tagged as ‘<note type=”edgloss” place=”inline”>’ that were migrated to <edGloss> elements during whatever processing happened with the old DMS. However, there were also occasionally notes tagged as ‘<note place=”inline”>’ that didn’t get transformed and remained tagged as this.
I’m not entirely sure how or where, but at some point during my processing of the data these ‘<note place=”inline”>’ notes have been lost. It’s very strange as the new DMS import script is based entirely on the scripts I wrote to process the old DMS XML entries, but I tested the DMS import by uploading the old DMS XML version of ‘poer_1’ to the new DMS and the ‘<note place=”inline”>’ have been retained, yet in the live entry for ‘poer_1’ the <note> text is missing.
I searched the database for all entries where the DMS XML as exported from the old DMS system contains the text ‘<note place=”inline”>’ and there are 323 entries, which I added to a spreadsheet and sent to the editors. It’s likely that the new XML for these entries will need to be manually corrected to reinstate the missing <note> elements. Some entries (as with ‘poer_1’) have several of these. II still have the old DMS XML for these so it is at least possible to recover the missing tags. I wish I could identify exactly when and how the tags were removed, but that would quite likely require many hours of investigation, as I already spent a couple of hours trying to get to the bottom of the issue without success.
Moving on to a different issue, I changed the upload scripts so that the ‘n’ numbers are always fully regenerated automatically when a file is uploaded, as previously there were issues when a mixture of senses with and without ‘n’ numbers were included in an entry. This means that any existing ‘n’ values are replaced, so it’s no longer possible to manually set the ‘n’ value. Instead ‘n’ values for senses within a POS will always increment from 1 depending on the order they appear in the file, with ‘n’ being reset to 1 whenever a new POS is encountered.
Main senses in locutions were not being assigned an ‘n’ on upload, and I changed this so that they are assigned an ‘n’ in exactly the same way as regular main senses. I tested this with the ‘descendre’ entry and it worked, although I encountered an issue. The final locution main sense (to descend to (by way of inheritance)) had a POS of ‘sbst._inf.’ In its <senseInfo> whereas it should have been (based on the POS of the previous two senses) ‘sbst. Inf.’. The script was therefore considering this to be a new POS and gave the sense an ‘n’ of 1. In my test file I updated the POS and re-uploaded the file and the sense was assigned the correct value of 3 to its ‘n’, but we’ll need to investigate why a different form of POS was recorded for this sense.
I also updated the front-end so that locution main senses with an ‘n’ now have the ‘n’ displayed, (e.g. https://anglo-norman.net/entry/descendre) and wrote a script that will automatically add missing ‘n’ attributes to all locution main senses in the system. I haven’t run this on the live database yet as I need further feedback from the editors before I do. As the week drew to a close I worked on a method to hide sense numbers in the front-end in case where there was only one sense in a part of speech, but I didn’t manage to get this completed and will continue with it next week.