Week Beginning 6th September 2021

I spent more than a day this week preparing my performance and development review form.  It’s the first time there’s been a PDR since before covid and it took some time to prepare everything.  Thankfully this blog provides a good record of everything I’ve done so I could base my form almost entirely on the material found here, which helped considerably.

Also this week I investigated and fixed an issue with the SCOTS corpus for Wendy Anderson.  One of the transcriptions of two speakers had the speaker IDs the wrong way round compared to the IDs in the metadata.  This was slightly complicated to sort out as I wasn’t sure whether it was better to change the participant metadata to match the IDs used in the text or vice-versa.  It turned out to be very difficult to change the IDs in the metadata as they are used to link numerous tables in the database, so instead I updated the text that’s displayed.  Rather strangely, the ‘download plan text’ file contained different incorrect IDs.  I fixed this as well, but it does make me worry that the IDs might be off in other plain text transcriptions too.  However, I looked at a couple of others and they seem ok, though, so perhaps it’s an isolated case.

I was contacted this week by a lecturer in English Literature who is intending to put a proposal together for a project to transcribe an author’s correspondence, and I spent some time writing a lengthy email with home helpful advice.  I also spoke to Jennifer Smith about her ‘Speak for Yersel’ project that’s starting this month, and we arranged to have a meeting the week after next.  I also spent quite a bit of time continuing to work on mockups for the STAR project’s websites based on feedback I’d received on the mockups I completed last week.  I created another four mockups with different colours, fonts and layouts, which should give the team plenty of options to decide from.  I also received more than a thousand new page images of library registers for the Books and Borrowing project and processed these and uploaded them to the server.  I’ll need to generate page records for them next week.

Finally, I continued to make updates to the Textbase search facilities for the Anglo-Norman Dictionary.  I updated genre headings to make them bigger and bolder, with more of a gap between the heading and the preceding items.  I also added a larger indent to the items within a genre and reordered the genres based on a new suggested order.  For each book I included the siglum as a link through to the book’s entry on the bibliography page and in the search results where a result’s page has an underscore in it the reference now displays volume and page number (e.g. 3_801 displays as ‘Volume 3, page 801’).  I updated the textbase text page so that page dividers in the continuous text also display volume and page in such cases.

Highlighted terms in the textbase text page no longer have padding around them (which was causing what looked like spaces when the term appears mid-word).  The text highlighting is unfortunately a bit of a blunt instrument, as one of the editors discovered by searching for the terms ‘le’ and fable’:  term 1 is located and highlighted first, then term 2 is.  In this example the first term is ‘le’ and the second term is ‘fable’.  Therefore the ‘le’ in ‘fable’ is highlighted during the first sweep and then ‘fable’ itself isn’t highlighted as it has already been changed to have the markup for the ‘le’ highlighting added to it and no longer matches ‘fable’.  Also, ‘le’ is matching some HTML tags buried in the text (‘style’), which is then breaking the HTML, which is why some HTML is getting displayed.  I’m not sure much can be done about any of this without a massive reworking of things, but it’s only an issue when searching for things like ‘le’ rather than actual content words so hopefully it’s not such a big deal.

The editor also wondered whether it would be possible to add in an option for searching and viewing multiple terms altogether but this would require me to rework the entire search and it’s not something I want to tackle if I can avoid it.  If a user wants to view the search results for different terms they can select two terms then open the full results in a new tab, repeating the process for each pair of terms they’re interested in, switching from tab to tab as required. Next week I’ll need to rename some of the textbase texts and split one of the texts into two separate texts, which is going to require me to regenerate the entire dataset.

Week Beginning 23rd August 2021

This week I completed work on a first version of the textbase search facilities for the Anglo-Norman Dictionary.  I’ve been working on this over the past three weeks and it’s now fully operational, quick to use and does everything that was required of it.  I completed work on the KWIC ordering facilities, adding in a drop-down list that enables the user to order the results either by the term or any word to the left or right of the term.  When results are ordered by a word to the left or right of the search term that word is given a yellow highlight so you can easily get your eye on the word that each result is being ordered by.  I ran into a few difficulties with the ordering, for example accented initial characters were being sorted after ‘z’, and upper case characters were all sorted before lower case characters, but I’ve fixed these issues.  I also updated the textbase page so that when you load a text from the results a link back to the search results appears at the top of the page.  You can of course just use the ‘back’ button to return to the search results. Also, all occurrences of the search term throughout the text are highlighted in yellow.  There are possibly some further enhancements that could be made here (e.g. we could have a box that hovers on the screen like the ‘Top’ button that contains a summary of your search and a link back to the results, or options to load the next or previous result) but I’ll leave things as they are for now as what’s there might be good enough.  I also fixed some bugs that were cropping up, such as an exact search term not appearing in the search box when you return to refine your results (caused by double quotes needing to be changed to the code ‘%22’).

I then began thinking about the development of a proximity search for the textbase.  As with the old site, this will allow the user to enter two search terms and specify the maximum number of words before or after the first term the second one appears.  The results will then be displayed in a KWIC form with both terms highlighted.  It took quite some time to think through the various possibilities for this feature.  The simplest option from a technical point of view would be to process the first term as with the regular search, retrieve the KWIC for each result and then search this for the second term.  However, this wouldn’t allow the user to search for an exact match for the second term, or use wildcards, as the KWIC only contains the full text as written, complete with punctuation.  Instead I decided to make the proximity search as similar to and as consistent with the regular textbase search as possible.  This means the user will be able to enter the two terms with wildcards and two lists of possible exact matches will be displayed, from which the user can select term 1 and term 2.  Then at this point the exact matches for term 1 will be returned and in each case a search will be performed to see whether term 2 is found however number of words specified before or after term 1.  This will rely on the ‘word order’ column that I already added to the database, but will involve some complications when term 1 is near the very start or end of a page (as the search will then need to look at the preceding or following page).  I ran a few tests of this process directly via the database and it seemed to work ok, but I’ll just need to see whether there are any speed issues when running such queries on potentially thousands of results.

With this possible method in place I began working on a new version of the textbase search page that will provide both the regular concordance search and the new proximity search.  As with the advanced search on the AND website, these will be presented on one page in separate tabs, and this required much reworking of the existing page and processing scripts.  I had to ensure that HTML elements that previously used IDs but would need to be replicated in each tab and would therefore no longer be unique would still be valid.  This meant some major reworking of the genre and book selection options, both in the HTML and in the JavaScript that handles the selection and deselection.  I also had to ensure that the session variables relating to the search could handle multiple types of search and that links would return the user to the correct type of search.  By the end of the week I had got a search form for the proximity search in place, with facilities to limit the search to specific texts or genres and options to enter two terms, the maximum number of words between the terms and whether term 1 should appear before or after term 2 (or either).  Next week I’ll need to update the API to provide the endpoint to actually run such a search.

Also this week I had an email from Bryony Randall about her upcoming exhibition for her New Modernist Editing project.  The exhibition will feature a live website (https://www.blueandgreenproject.com/) running on a tablet in the venue and Bryony was worried that the wifi at the venue wouldn’t be up to scratch.  She asked whether I could create a version of the site that would run locally without an internet connection, and I spent some time working on this.

Looking at the source of the website it would appear to have been constructed using the online website creation platform https://www.wix.com/.  I’d never used this before, but it will have an admin interface where you can create and manage pages and such things.  The resulting website is integrated with the online Wix platform and (after a bit of Googling) it looked like there isn’t a straightforward way to export pages created using Wix for use elsewhere.  However, the site only consisted of 20 or so static pages (i.e. no interactive elements other than links to other pages) so I thought it would be possible to just save each page as HTML, go through each of the files and update the links and then the resulting pages could potentially run directly in a browser.  However, after trying this would I realised that there were some issues.  Looking at the source there are numerous references to externally hosted scripts and files, such as JavaScript files, fonts and images that were not downloaded when the webpage was saved and these would all be inaccessible if the internet connection was lost, which would likely result in a broken website.  I also realised that the HTML generated by WIX is a pretty horrible tangled mess, and getting this to work nicely would take a lot of work.  I therefore decided to just create a replica of the site from scratch using Bootstrap.

However, it was only after this point that I was informed that the local site would need to run on a tablet rather than a full PC.  The tablet is an Android one, which seriously complicates matters as unlike a proper computer, Android imposes restrictions on what you can and can’t do, and one of the things you can’t do is run locally hosted websites in the browser.  I tried several approaches to get my test site working on my Android phone and with all of the straightforward ways I can get the HTML file to load into the browser, but not any associated files – no images, stylesheets or JavaScript.  This is obviously not acceptable.  I did manage to get it to work, but only by using an app that runs a server on the device and by using absolute file references to the IP address the server app uses in the files (relative file references just did not work).  The app I used was called Simple HTTP Server (https://play.google.com/store/apps/details?id=jp.ubi.common.http.server) and once configured it worked pretty well.

I continued to work on my replica of the site, getting all of the content transferred over.  This took longer than I anticipated, as some of the pages are quite complicated (artworks including poetry, images, text and audio) but I managed to get everything done before the end of the week.  In the end it turned out that the wifi at the venue was absolutely fine so my replica site wasn’t needed, but it was still a good opportunity to learn about hosting a site on an Android device and to hone my Bootstrap skills.

Also this week I helped Katie Halsey of the Books and Borrowing project with a query about access to images, had a look through the final version of Kirsteen McCue’s AHRC proposal and spoke to Eleanor Lawson about creating some mockups of the interface to the STAR project websites, which I will start on next week.

Week Beginning 9th August 2021

I’d taken last week off as our final break of the summer, and we spent it on the Kintyre peninsula.  We had a great time and were exceptionally lucky with the weather.  The rains began as we headed home and I returned to a regular week of work.  My major task for the week was to begin work on the search facilities for the Anglo-Norman Dictionary’s textbase, a collection of almost 80 lengthy texts for which I had previously created facilities to browse and view texts.  The editors wanted me to replicate the search options that were available through the old site, which enabled a user to select which texts to search (either individual texts or groups of texts arranged by genre), enter a single term to search (either a full match or partial match at the beginning or end of a word), select a specific term from a list of possible matches and then view each hit via a keyword in context (KWIC) interface, showing a specific number of words before and after the hit, with a link through to the full text opened at that specific point.

This is a pretty major development and I decided initially that I’d have two major tasks to tackle.  I’d have to categorise the texts by their genre and I’d have to research how best to handle full text searching including limiting to specific texts, KWIC and reordering KWIC, and linking through to specific pages and highlighting the results.  I reckoned it was potentially going to be tricky as I don’t have much experience with this kind of searching.  My initial thought was to see whether Apache Solr might be able to offer the required functionality.  I used this for the DSL’s advanced search, which searches the full text of the entries and returns snippets featuring the word, with the word highlighted and the word then highlighted throughout the entry when an entry in the results is loaded (e.g. https://dsl.ac.uk/results/dreich/fulltext/withquotes/both/).  This isn’t exactly what is required here, but I hoped that there might be further options I can explore.  Failing that I wondered whether I could repurpose the code for the Scottish Corpus of Texts and Speech.  I didn’t create this site, but I redeveloped it significantly a few years ago and may be able to borrow parts from the concordance search. E.g. https://scottishcorpus.ac.uk/advanced-search/ and select ‘general’ then ‘word search’ then ‘word / phrase (concordance)’ then search for ‘haggis’ and scroll down to the section under the map.  When opening a document you can then cycle through the matching terms, which are highlighted, e.g. https://scottishcorpus.ac.uk/document/?documentid=1572&highlight=haggis#match1.

After spending some further time with the old search facility and considering the issues I realised there are a lot of things to be considered regarding preparing the texts for search purposes.  I can’t just plug the entire texts in as only certain parts of them should be used for searching – no front or back matter, no notes, textual apparatus or references.  In addition, in order to properly ascertain which words follow on from each other all XML tags need to be removed too, and this introduces issues where no space has been entered between tags but a space needs to exist between the contents of the tags, e.g. ‘dEspayne</item><item>La charge’ would otherwise become ‘dEspayneLa charge’.

As I’d need to process the texts no matter which search facility I end up using I decided to focus on this first, and set up some processing scripts and a database on my local PC to work with the texts.  Initially I managed to extract the page contents for each required page, remove notes etc and strip the tags and line breaks so that the page content is one continuous block of text.

I realised that the old search seems to be case sensitive, which doesn’t seem very helpful.  E.g. search for ‘Leycestre’ and you find nothing – you need to enter ‘leycestre’, even though all 264 occurrences actually have a capital L.  I decided to make the new search case insensitive – so searching for ‘Leycestre’, ‘leycestre’ or ‘LEYCESTRE’ will bring back the same results.  Also, the old search limits the keyword in context display to pages.  E.g. the first ‘Leycestre’ hit has no text after it as it’s the last word on the page.  I’m intending to take the same approach as I’m processing text on a page-by-page basis.  I may be able to fill out the KWIC with text from the preceding / subsequent page if you consider this to be important, but it would be something I’d have to add in after the main work is completed.  The old search also limits the KWIC to text that’s on the same line, e.g. in a search for ‘arcevesque’ the result ‘L’arcevesque puis metre en grant confundei’ has no text before because it’s on a different line (it also chops off the end of ‘confundeisun’ for some reason).  The new KWIC will ignore breaks in the text (other than page breaks) when displaying the context.  I also realised that I need to know what to do about words that have apostrophes in them.  The old search splits words on the apostrophe, so for example you can search for arcevesque but not l’arcevesque.  I’m intending to do the same.  The old search retains both parts before and after the apostrophe as separate search terms, so for example in “qu’il” you can search for “qu” and “il” (but not “qu’il”).

After some discussions with the editor, I updated my system to include textual apparatus, stored in a separate field to the main page text.  With all of the text extracted I decided that I’d just try and make my own system initially, to see whether it would be possible.  I therefore created a script that would take each word from the extracted page and textual apparatus fields and store this in a separate table, ensuring that words with apostrophes in them are split into separate words and for search purposes all non-alphanumeric characters are removed and the text is stored as lower-case.  I also needed to store the word as it actually appears in the text, the word order on the page and whether the word is a main page word or in the textual apparatus.  This is because after finding a word I’ll need to extract those around it for the KWIC display.  After running my script I ended up with around 3.5 million rows in the ‘words’ table, and this is where I ran into some difficulties.

I ran some test queries on the local version of the database and all looked pretty promising, but after copying the data to the server and running the same queries it appeared that the server is unusably slow.  On my desktop a query  to find all occurrences of ‘jour’, with the word table joined to the page table and then to the text table completed in less than 0.5 seconds but on the server the same query took more than 16 seconds, so about 32 times slower.  I tried the same query a couple of times and the results are roughly the same each time.  My desktop PC is a Core i5 with 32GB of RAM, and the database is running on an NVMe M.2 SSD, which no doubt makes things quicker, but I wouldn’t expect it to be 32 times quicker.

I then did some further experiments with the server.  When I query the table containing the millions of rows on its own the query is fast (much less than a second).  I added a further index to the column that is used for the join to the page table (previously it was indexed, but in combination with other columns) and then when limiting the query to just these two tables the query runs at a fairly decent speed (about 0.5 seconds).  However, the full query involving all three tables still takes far too long, and I’m not sure why.  It’s very odd as there are indexes on the joining columns and the additional table is not big – it only has 77 rows.  I read somewhere that ordering the results by a column in the joined table can make things slower, as can using descending order on a column, so I tried updating the ordering but this has had no effect.  It’s really weird – I just can’t figure out why adding the table has such a negative effect on the performance and I may end up just having to incorporate some of the columns from the text table into the page table, even though it will mean duplicating data.  I also still don’t know why the performance is so different on my local PC either.

One final thing I tried was to change the database storage type.  I noticed that the three tables were set to use MyISAM storage rather than InnoDB, which the rest of the database was set to.  I migrated the tables to InnoDB in the hope that this might speed things up, but it’s actually slowed things down, both on my local PC and the server.  The two-table query now takes several seconds while the three-table query now takes about the same, so is quicker, but still too slow.  On my desktop PC the speed has doubled to about 1 second.  I therefore reverted back to using MyISAM.

I decided to leave the issue of database speed at that point and to focus on other things instead.  I added a new ‘genre’ column to the texts and added in the required categorisation.  I then updated the API to add in this new column and updated the ‘browse’ and ‘view’ front-ends so that genre now gets displayed.  I then began work on the front-end for the search, focussing on the options for listing texts by genre and adding in the options to select / deselect specific texts or entire genres of text.  This required quite a bit of HTML, JavaScript and CSS work and made a nice change from all of the data processing.  By the end of the week I’d completed work on the text selection facility, and next week I’ll tackle the actual processing of the search, at which point I’ll know whether my database way of handling things will be sufficiently speedy.

Also this week I had a chat with Eleanor Lawson about the STAR project that has recently begun.  There was a project meeting last week that unfortunately I wasn’t able to attend due to my holiday, so we had an email conversation about some of the technical issues that were raised at the meeting, including how it might be possible to view videos side by side and how a user may choose to select multiple videos to be played automatically one after the other.

I also fixed a couple of minor formatting issues for the DSL people and spoke to Katie Halsey, PI of the Books and Borrowing project about the development of the API for the project and the data export facilities.  I also received further feedback from Kirsteen McCue regarding the Data Management Plan for her AHRC proposal and went through this, responding to the comments and generating a slightly tweaked version of the plan.

 

Week Beginning 26th July 2021

I returned to Glasgow for a more regular week of working from home, after spending a delightful time at my parents’ house in Yorkshire for the past two weeks.  I continued to work on the Comparative Kingship front-ends this week.  I fixed a couple of issues with the content management systems, such as ensuring that the option to limit the list of place-names by parish worked for historical parishes and fixing an issue whereby searching by sources was returning zero results.  Last week I’d contacted Chris Fleet at NLS Maps to ask whether we might be able to incorporate a couple of maps of Ireland that they host into our resource, and Chris got back to me with a very helpful reply, giving us permission to use the maps and also pointing out some changes to the existing map layers that I could make.

I updated the attribution links on the site, and pointed the OS six-inch map links to the NLS’s hosting on AWS.  I also updated these things on the other place-name resources I’ve created too.  We had previously been using a modern OS map layer hosted by the NLS, and Chris pointed out that a more up to date version could now be accessed directly from the OS website (see Chris’s blog post here: https://www.ordnancesurvey.co.uk/newsroom/blog/comparing-past-present-new-os-maps-api-layers).  I followed the instructions and signed up for an OS API key, and it was then a fairly easy process to replace the OS layer with the new one.  I did the same with the other place-name resources too, and its looks pretty good.  See for example how it looks on a map showing placenames beginning with ‘B’ on the Berwickshire site: https://berwickshire-placenames.glasgow.ac.uk/place-names/?p=results&source=browse&reels_name=B*#13/55.7939/-2.2884/resultsTabs-0/code/tileOS//

With these changes and the Irish historical maps in place I continued to work on the Irish front-end.  I added in the parish boundaries for all of the currently required parishes and also added in three-letter acronyms that the researcher Nick Evans had created for each parish.  These are needed to identify the parishes on the map, as full parish names would clutter things up too much.  I then needed to manually positing each of the acronyms on the map, and to do so I updated the Irish map to print the latitude and longitude of a point to the console whenever a mouse click is made.  This made it very easy to grab the coordinates of an ideal location for each acronym.

There were a few issues with the parish boundaries, and Nick wondered whether the boundary shapefiles he was using might work better.  I managed to open the parish boundary shapefile in QGIS, converted the boundary data to WGS84 (latitude / longitude) and then extracted the boundaries as a GeoJSON file that I can use with my system.  I then replaced the previous parish boundaries with the ones from this dataset, but unfortunately something was not right with the positioning.  The northern Irish ones appear to be too far north and east, with the boundary for BNT extending into the sea rather than following the coast and ARM not even including the town of Armoy, as the following screenshot demonstrates:

In QGIS I needed to change the coordinate reference system from TM65 / Irish Grid to WGS84 to give me latitude and longitude values, and I wondered whether this process had caused the error, therefore I loaded the parish data into QGIS again and added an OpenStreetMap base map to it too, and the issue with the positioning is still apparent in the original data, as you can see from the following QGIS screenshot:

I can’t quite tell if the same problem exists with the southern parishes.  I’d positioned the acronyms in the middle of the parishes and they mostly still seem to be in the middle, which suggests these boundaries may be ok, although I’m not sure how some could be wrong while others are correct as everything is joined together.  After consultation with Nick I reverted to the original boundaries, but kept a copy of the other ones in case we want to reinstate them in future.

Also this week I investigated a strange issue with the Anglo-Norman Dictionary, whereby a quick search for ‘resoler’ brings back an ‘autocomplete’ match, but then finds zero results if you click on it.  ‘Resoler’ is a cross-reference entry and works in the ‘browse’ option too.  It seemed very strange that the redirect from the ‘browse’ would work, and also that a quick search for ‘resolut’, which is another variant of ‘resoudre’ was also working.  It turns out that it’s an issue with the XML for the entry for ‘resoudre’.  It lists ‘resolut’ as a variant, but does not include ‘resoler’ as you can see:

<variant gram=”imp.5″>resolvez</variant>

<deviant gram=”imp.5″>resoylez</deviant>

<varref><reference><source siglum=”Alchimie”><loc>380.5</loc></source></reference></varref>

<variant gram=”p.p.”>resolé</variant>

<variant>resolu</variant>

<variant>resolut</variant>

<newvargroup/>

<variant gram=”p.p.pl.”>resolous</variant>

<deviant gram=”p.p.pl.”>resouz</deviant>

<varref><reference><source siglum=”Secr1″><loc>1524</loc></source></reference></varref>

<deviant>resus</deviant>

<varref><reference><source siglum=”Alchimie”><loc>379.1</loc></source></reference></varref>

The search uses the variants / deviants from the XML to figure out which main entry to load from a cross reference.  As ‘resoler’ is not present the system doesn’t know what entry ‘resoler’ refers to and therefore displays no results.  I pointed this out to the editor, who changed the XML to add in the missing variant, which fixed the issue.

Also this week I responded to some feedback on the Data Management Plan for Kirsteen’s project, which took a little time to compile, and spoke to Jennifer Smith about her upcoming follow-on project for SCOSYA, which begins in September and I’ll be heavily involved with.  I also had a chat with Rhona about the ancient DSL server that we should now be able to decommission.

Finally, Gerry Carruthers sent me some further files relating to the International Journal of Scottish Theatre, which he is hoping we will be able to host an archive of at Glasgow.  It consisted of a database dump, which I imported into a local database and had a look at it.  It mostly consists of tables used to manage some sort of editorial system and doesn’t seem to contain the full text of the articles.  Some of the information contained in it may be useful, though – e.g. it stores information about article titles, authors, the issues articles appear in, the original PDF filenames for each article etc.

In addition, the full text of the articles is available as both PDF and HTML in the folder ‘1>articles’.  Each article has a numerically numbered folder (e.g. 109) that contains two folders: ‘public’ and ‘submission’.  ‘public’ contains the PDF version of the article.  ‘submission’ contains two further folders: ‘copyedit’ and ‘layout’.  ‘copyedit’ contains an HTML version of the article while ‘layout’ contains a further PDF version.  It would be possible to use each HTML version as a basis for a WordPress version of the article.  However, some things need to be considered:

Does the HTML version always represent the final published version of the article?  The fact that it exists in folders labelled ‘submission’ and ‘copyedit’ and not ‘public’ suggests that the HTML version is likely to be a work in progress version and editorial changes may have been made to the PDF in the ‘public’ folder that are not present in the HTML version.  Also, there are sometimes multiple HTML versions of the article.  E.g. in the folder ‘1>articles>154>submission>copyedit’ there are two HTML files: ‘164-523-1-CE.htm’ and ‘164-523-2-CE.htm’.  These both contain the full text of the article but have different formatting (and may have differences in the content, but I haven’t checked this).

After looking at the source of the HML versions I realised these have been auto-generated from MS Word.  Word generates really messy, verbose HTML with lots of unnecessary tags and I therefore wanted to see what would happen if I copied and pasted it into WordPress.  My initial experiment was mostly a success, but WordPress treats line breaks in the pasted file as actual line breaks, meaning the text didn’t display as it should.  What I needed to do in my text editor was find and replace all line break characters (\r and \n) with spaces.  I also had to make sure I only copied the contents within the HTML <body> tag rather than the whole text of the file.  After that the process worked quite well.

However, there are other issues with the dataset.  For example, article 138 only has Word files rather than HTML or PDF files and article 142 has images in it, and these are broken in the HTML version of the article.  Any images in articles will probably have to be manually added in during proofreading.  We’ll need to consider whether we’ll have to get someone to manually migrate the data, or whether I can write a script that will handle the bulk of the process.

I had my second vaccination jab on Wednesday this week, which thankfully didn’t hit me as hard as the first one did.  I still felt rather groggy for a couple of days, though.  Next week I’m on holiday again, this time heaving to the Kintyre peninsula to a cottage with no internet or mobile signal, so I’ll be unreachable until the week after next.

Week Beginning 12th July 2021

I’m down visiting my parents in Yorkshire for the first time in 18 months this week and next, working a total of four days over the two-week period.  This week I mainly focussed on the Irish front-end for the Comparative Kingship place-names project, but also adding in some updates to the Scotland system that I recently set up, such as making the Gaelic forms of the classification codes visible and adding options to browse Gaelic forms of place-names and historical forms to the ‘Browse’ facility and ensuring the other place-name and historical form browses only bring back English forms.

The Irish system is mostly identical to the Scottish system, but I did need to make some changes that took a bit of time to implement.  As the place-names covered appear to be much more geographically spread out, I’ve allowed the map to be zoomed out further.  I’ve also had to remove the modern OS and historical OS map layers as they don’t cover Ireland, so currently there are only three map layers available (the default view, satellite view and satellite view with labels).  The Ordnance Survey of Ireland provides access to some historical map layers here: https://geohive.maps.arcgis.com/apps/webappviewer/index.html?id=9def898f708b47f19a8d8b7088a100c4 but their terms and conditions makes it clear that you can’t use the maps on another online resource.  However, there are a couple of Irish maps on the NLS website, the Bartholomew Quarter-Inch 1940 (https://maps.nls.uk/geo/explore/#zoom=9&lat=53.10286&lon=-7.34481&layers=13&b=1) and the GSGS One-Inch 1941-3 (https://maps.nls.uk/geo/explore/#zoom=9&lat=53.10286&lon=-7.34481&layers=14&b=1) and we could investigate integrating these as the NLS maps people have always been very helpful.

I also updated the map pop-ups to include the new Irish data fields, such as baronies, townlands and the different map types.  Both English and Gaelic forms of things like parishes, baronies and classification codes are displayed throughout the site and on the Record page the ITM figures also appear.  I updated the ‘Browse’ page so that it features baronies and the element glossary should work, but I haven’t tested it out as there is no data yet.  The Advanced search features a selectable list of baronies and currently a simple textbox for townlands.  I may change this to an autocomplete (whereby you start typing and townlands that include the letters appear in a selectable list), or I may leave it as it is, meaning multiple townlands can be searched for and wildcard characters can be used.

I managed to locate downloadable files containing parish boundaries for Ireland here: https://www.townlands.ie/page/download/ and have added these to the data for the two parishes that currently contain data.  I haven’t added in any other parish boundaries yet as there are over 200 parishes in our database I don’t want to have to manually add in the boundaries for all of these if it won’t be necessary.  Also, on the Scotland maps the three-letter acronym appears in the middle of each parish in order to identify it, but the Irish parishes don’t have TLAs so currently don’t have any labels.  The full text of the parish will clutter up the map too much if I use it, so I’m not sure what we could do to label the parishes.

Also this week I responded to some feedback about the Data Management Plan for Kirsteen McCue’s proposal and created a slightly revised version.  I also had an email conversation with Eleanor Lawson about her new speech project and how the web presence for the project may function.  Finally, I made some tweaks to the Dictionary of the Scots Language, updating the layout of the ‘Contact’ page and updating the bibliography page on the new website so that URLs that use the old style IDs will continue to work.  I also had a chat with Rhona Alcorn about some new search options that we are going to add in to the new site before it goes live, although probably not until the autumn.

 

Week Beginning 5th July 2021

After a lovely week’s holiday in the East Neuk of Fife last week I returned to full week of work.  I spent Monday catching up with emails and making some updates to two project websites.  Firstly, for the Anglo-Norman Dictionary I updated the Textbase to add in the additional PDF texts.  As these are not part of the main Textbase I created a separate page that listed and linked to them, and added a reference to the page to the introductory paragraph of the main Textbase page.  Secondly, I made some further updates to the content management system for the Books and Borrowing project.  There was a bug in the ‘clear borrower’ feature that resulted in the normalised occupation fields not getting clears.  This meant that unless a researcher noticed and manually removed the selected occupations it would be very easy to end up with occupations assigned to the wrong borrower.  I implemented a fix for this bug, so all is well now.  I had also been alerted to an issue with the library’s ‘books’ tab.  When limiting the listed books to only those mentioned in a specific register the list of associated borrowing records that appears in a popup was not limiting the records to those in the specified register.  I fixed this as well, and also made a comparable fix to the ‘borrowers’ tab as well.

During the week I also had an email conversation with Kirsteen McCue about her ‘Singing the Nation’ AHRC proposal, and made a new version of the Data Management Plan for her.  I also investigated some anomalies with the stats for the Dictionary of the Scots Language website for Rhona Alcon.  Usage figures were down compared to last year, but it looks like last year may have been a blip caused by Covid, as figures for this year match up pretty well with the figures for years before the dreaded 2020.

On Wednesday I was alerted to an issue with the Historical Thesaurus website, which appeared to be completely inaccessible.  Further investigation revealed that other sites on the server were also all down.  Rather strangely the Arts IT Support team could all access the sites without issue, and I realised that if I turned wifi off on my phone and accessed the site via mobile data I could access the site too.  I had thought it was an issue with my ISP, but Marc Alexander reported that he used a different ISP and could also not access the sites.  Marc pointed me in the direction of two very handy websites that are useful for checking whether websites are online or not.  https://downforeveryoneorjustme.com checks the site and lets you know whether it’s working while https://www.uptrends.com/tools/uptime is a little more in-depth and checks whether the site is available from various locations across the globe.  I’ll need to remember these in future.

The sites were still inaccessible on Thursday morning  and after some Googling I found an answer to someone with a similar issue here: https://webmasters.stackexchange.com/questions/104092/why-is-my-site-showing-as-being-down-for-some-places-and-not-others I asked Arts IT Support to check with central IT Services to see whether any DNS settings had been changed recently or if they know what might be causing the issue, as it turned out to be a more widespread issue than I had thought, and was affecting sites on different servers too.  A quick check of the sites linked to from this site showed that around 20 websites were inaccessible.

Thankfully by Thursday lunchtime the sites had begun to be accessible again, although not for everyone.  I could access them, but Marc Alexander still couldn’t.  By Friday morning all of the sites were fully accessible again from locations around the globe, and Arts IT Support got back to me with a cause for the issue.  Apparently there was some server in the Boyd Orr that controls DNS records for the University and it had gone wrong and sent out garbled instructions to other DNS servers around the world, which knocked out access to our sites, even though the sites themselves were all working perfectly.

I spent the rest of the week working on the front-end for the Scotland data for the Comparative Kingship project, a task that I’d begun before I went away on my holiday.  I managed to complete an initial version of the Scotland front-end, which involved taking the front-end from one of the existing place-names websites (e.g. https://kcb-placenames.glasgow.ac.uk/) and adapting it.  I had to make a number of adaptations, such as ensuring that two parallel interfaces and APIs could function on one site (one for Scotland, one for Ireland), updating a lot of the site text, creating a new, improved menu system and updating the maps so that they defaulted to the new area of research.  I also needed to add in facilities to search, return data for and display new Gaelic fields, e.g. Gaelic versions of place-names and historical forms.  This meant updating the advanced search to add in a new ‘language’ choice option, to enable a user to limit their search to just English or Gaelic place-name forms or historical forms.  This in turn meant updating the API to add in this additional option.

An additional complication came when I attempted to grab the parish boundary data, which for previous project I’d successfully exported from Scottish Government’s Spatial Data website (https://www.spatialdata.gov.scot/geonetwork/srv/eng/catalog.search#/metadata/c1d34a5d-28a7-4944-9892-196ca6b3be0c) via a handy API (https://maps.gov.scot/server/rest/services/ScotGov/AgricultureEnvironment/MapServer/1/query).  However, the parish boundary data was not getting returned with latitude / longitude pairs marking the parish shape, but instead used esriMeters instead.  I found someone else who wanted to covert esriMeters into lat/lng (https://gis.stackexchange.com/questions/54534/how-can-i-convert-esrimeters-to-lat-lng) and one of the responses was that with an ArcGIS service (which the above API appears to be) you should be able to set the ‘output spatial reference’, with the code 4326 being used for WGS84, which would give lat/lng values.  The API form does indeed have an ‘Output Spatial Reference’ field, but unfortunately it doesn’t seem to do anything.  I did lots of further Googling and tried countless different ways of entering the code, but nothing changed the output.

Eventually I gave up and tried an alternative approach.  The site also provides the parish data as an ESRI Shapefile (https://maps.gov.scot/ATOM/shapefiles/SG_AgriculturalParishes_2016.zip) and I wondered whether I could plug this into a desktop GIS package and use it to migrate the coordinates to lat/lng.  I installed the free GIS package QGIS (https://www.qgis.org/en/site/forusers/download.html) and after opening it went to the ‘Layer’ menu, selected ‘Add Layer’, then ‘Add Vector Layer’ then selected the zip file and pressed ‘add’, at which point all of the parish data loaded in, allowing me to select a parish and view the details for it.  What I then needed to do was to find a means of changing the spatial reference and saving a geoJSON file.  After much trial and error I discovered that in the ‘Layer’ menu there is a ‘Save as’ option.  This allowed me to specify the output format (geoJSON) and change the ‘CRS’, which is the ‘Coordinate Reference System’.  In the drop-down list I located ESPG: 4326 / WGS84 and selected it.  I then specified a filename (the folder defaults to a Windows System folder and needs to be updated too) and pressed ‘OK’ and after a long wait the geoJSON file was generated, with latitude and longitude values for all parishes.  Phew!  It was quite a relief to get this working.

With access to a geoJSON file containing parishes with lat/lng pairings I could then find and import the parishes that we needed for the current project, of which there were 28.  It took a bit of time to grab all of these, and I then needed to figure out where I wanted the three-letter acronyms for each parish to be displayed, as well, which I worked out using the National Library of Scotland’s parish boundaries map (https://maps.nls.uk/geo/boundaries/), which helpfully displays lat/lng coordinates for your cursor position in the bottom right.  With all of the parish boundary data in place the infrastructure for the Scotland front-end is now more or less complete and I await feedback from the project team.  I will begin work on the Ireland section next, which will take quite some work as the data fields are quite different.  I’m only going to be working a total of four days over the next two weeks (probably as half-days) so my reports for the next couple of weeks are likely to be a little shorter!

Week Beginning 14th June 2021

I divided my time this week primarily into three.  Firstly, I wrote a Data Management Plan for Craig Lamont’s proposal.  I can’t really say much about it at this stage, but it took about a day to write, including several email conversations with Craig.

Secondly, I made some updates to the Books and Borrowing CMS.  This took some time to get started on as my access to the Stirling VPN had been cancelled, and without such access I couldn’t access the project’s server.  Thankfully with the help of Stirling’s Information Services people my access was reinstated on Monday and I could start working on the updates.  After familiarising myself with the systems again I had some further questions about the updates suggested by Matt Sangster, resulting in an email conversation and a suggestion by him that he discusses things further with the team next Monday.  Gerry McKeever had suggested some further updates, though, and I worked on these.

The first issue was the ordering of the ‘Books’ tab when viewing a library.  This list of books (of which there can be thousands) is paginated with 200 books per page, with options to order the table by a variety of columns (e.g. book name and number of associated borrowings).  However, the ordering was only ordering the subset of 200 books rather than the whole set.

I updated the page so that the complete dataset is reordered rather than just the 200 records that are displayed per page.  However, this has a massive performance hit that wipes out the page loading speed increase that was gained from paginating the list in the first place.  To reorder the data the page needs to load the entire dataset and then reorder it.  In the case of St Andrews this means that more than 7,200 book records need to be loaded, with multiple sub-queries for each of these records required to bring back the counts of borrowing records and information about book items, book editions and authors.

With the previous paginated way of viewing the data the CMS was taking a couple of seconds to load the ‘Books’ page for St Andrews.  With the new update in place it was taking more than 1 minute and 20 seconds for the page to load.  When running the exact same code and database on my local PC it was taking 10 seconds to load, so presumably the spec of my local PC is considerably better than the server (either that or it’s having to handle a lot of other database requests at the same time, which is affecting performance).

I had considered storing the data in a session variable, which would mean after the first horrendous load time the data would be ready and waiting in the server’s memory to be used until you closed your browser, however, as the data is continuously being worked on this would mean the information displayed would possibly not accurately reflect the current state of the data, which may be confusing.  What I am planning on doing when I develop the front-end is to create a cached version of the data, so counts of borrowing records etc won’t need to be recalculated each time a user queries something, but creating such a cached version wouldn’t really work whilst the data is still being worked on.  I could set the system up to refresh the cache every night, but that would mean the CMS would again not reflect the current state of the data, which isn’t good.  I also updated the ‘Borrowers’ page to allow full reordering of data here too.  This isn’t quite as slow as the books page.

I spoke to the server admin people to see if they could think of a reason why the server loading speed was so much worse that on my local PC.  They reckoned it was because the database is stored on a different server to the code, and the sheer number of individual queries being sent meant that small delays in connecting between servers were mounting up.  I reworked the code somewhat to try and streamline the number of database queries that need to be made.  Only two of the columns can now be selected to order the data by: Book Holding title and number of borrowing records.  I’m hoping these are the most important anyway.  I have updated the queries so that the bulk of the data is only retrieved for the 200 records that are on the visible page (as used to be the case) with only a single query of the holding table and then a further query for each relevant holding record to bring back a count of its borrowing records now being made on the full dataset (e.g. for St Andrews for each of the 7,391 books).  This has made a huge difference and has brought the page loading times back down to a more acceptable few seconds.

Gerry’s second request was that when the book list is limited to a specific register the counts of borrowings updated to reflect this.  I updated the code so that counts of borrowing records on both the ‘Books’ and ‘Borrowers’ tabs get limited to just the selected register and thankfully there was no performance hit associated with this update.

The third project of the week for me was the Anglo-Norman Dictionary.  As mentioned in last week’s lengthy post, I had discovered a fourth version of the texts for the textbase that appear to be the ones that the old site actually used.  I spent most of Tuesday splitting this fourth version of the texts into individual pages and preparing them for display.  They had new issues that needed to be tackled (following the previous process resulted in about 2,000 fewer pages and it turned out that this was caused by some page breaks in the fourth version not having ‘n’ numbers).  By the end of the day I’d managed to get the same number of pages as with my initial version, with the new pages available via the front-end and all working with spacing issues resolved.

I discovered that the weird spacing issue that I had previously thought was an issue with the first version of the texts I was working with had actually been introduced via the ‘Tidy’ library I’d used to remove mismatched opening and closing tags from sections of the XML that I’d split into pages.  It’s really bizarre, but the library was inserting space characters and rearranging existing space characters between tags in a way that completely destroyed the integrity of the data.  After some Googling I came across this item about the issue: https://stackoverflow.com/questions/15147711/php-tidy-removes-whitespace-and-inserts-newlines and a suggested way around the issue is to enclose the XML in a <pre> tag before passing it through the Tidy library, which means the library doesn’t mess about with the layout.  The placement of spaces in a text can be of vital importance so why the library by default messes with spaces and doesn’t even provide an option to stop the library doing so is baffling.  However, the <pre> hack worked, thankfully.

However, on Wednesday I received an email from the editor Geert to say that they had received approval for the AND to display each of the textbase texts in full on one page, rather than being split up into individual pages.  This was great news, but did mean that all my work on splitting up and reformatting the pages was all for nothing.  Still, that’s the way it goes sometimes.  As the week drew to a close I began working on a new version of the textbase, and by the end of the week I had completed a preliminary version of the textbase featuring the full content of each text on one long page.  I have to say it’s a lot easier to use now and is a massive improvement on having to navigate through hundreds of individual small pages.

The contents page is pretty much the same, and still includes a ‘jump to page’ feature, although this now takes you to the relevant section of the long page rather than an individual page.  When you load a text, either by clicking on its title or selecting a page the full text will load.

I added the copyright statement to the top as well as the bottom of the text to make it more visible, and have given it a blue background for a similar reason.  There is also a ‘jump to page’ feature on this page too, which takes you directly to the appropriate section of the text.  I also added an option to show / hide notes so you can hide them to declutter the page a bit.  The individual pages are divided with a horizontal line with the page number centred in the middle of this.  Explanatory notes appear in a grey section at the foot of each page.  There are still some things I need to work on, namely to go through each text to check that the formatting is correct throughout and to fix the footnote numbering and ordering.  I think I have a plan for this, but will need to look into this next week.

Also this week I heard that a proposal involving Jane Stuart-Smith and Eleanor Lawson at QMU that I helped put together last year has been funded and is due to stary in July, which is great news.  I also made a few further tweaks to the Dictionary of the Scots Language and had a chat about some new dictionaries that are going to be added to the site.

Week Beginning 7th June 2021

This week I finished an initial version of the ‘Browse Textbase’ feature for the Anglo-Norman Dictionary. Processing the XML proved to be rather tricky as I couldn’t just use the old XSLT file as it included a lot of stuff that wasn’t needed in the new site (e.g. formatting headers and footers) and gave errors when plugged directly into the new system.  For these reasons I had to adapt the XSLT.  Also, I’d split up the full XML files into chunks for each page, resulting in more than 12,700 chunks.  However, the XML often included elements that extended across pages, and when the content was extracted on a per-page basis this led to an invalid XML structure, as some tags ended up missing their closing tags, or closed without featuring an opening tag.  XSLT only works on valid XML files so I needed to find a way to fix this tag issue.  After some Googling I discovered that there is a PHP extension called Tidy that can take an invalid XML file and fix it.  What this does is to strip out all tags that don’t have an opening or closing tag, which is exactly what I wanted.  I wrote a little script that used the extension, tested it successfully on a few files and then ran all of the 12,700 pages through it.

With a full set of valid XML page files I then began work on the XSLT to display the documents as required.  This has been a very laborious process as I needed to go through each of the 77 documents and check the layout for any issues, and fix these as they cropped up.  With more than 12,700 pages I couldn’t look at each individually, but instead I generally looked at every page of the front matter, and then a random selection of pages in the main body of the text, as generally the structure is more consistent here.  I think this approach has worked well as most formatting issues were to be found in the front matter (e.g. some tables were split across multiple pages and needed table tags to be inserted at the top and bottom).

With regards to the main body of the texts the largest challenge has been getting the explanatory notes to appear correctly, as these had been tagged in at least nine different ways throughout the documents, sometimes with entirely different XML structures and content.  One possible issue is that I dealt with new XML features as they cropped up as I worked through the books, but in dealing with these features I may have inadvertently messed up how things looked in earlier books.  One example that I thankfully spotted is that I wanted <bibl> tags to start on a new line as this would make the bibliographies easier to read, but other texts have the <bibl> tag mid-sentence and my change resulted in lines breaking where they shouldn’t.

There are some other issues that have cropped up that we may still need to address.  There are many spacing issues caused by whoever tagged the documents not leaving spaces between tags, or adding spaces between tags where there shouldn’t be spaces.  It’s a bit of a strange issue as it doesn’t seem to exhibit itself on the old site, but isn’t something that is dealt with by the scripts I have access to.  I don’t know if perhaps the texts were ‘fixed’ at some point and I just don’t have access to the fixed versions.  It’s not something that can be fixed automatically (at least not without coming up with a set of rules for fixing) as it’s not always the case that a tag should always have (or not have) a space after it.  Here are some examples, with the text as displayed before the colon and the XML after:

  1. ‘M cMoroug’: M <hi rend=”sup”>c</hi>Moroug
  2. ‘Lettres et pétitions( Legge’: <title lang=”FR” rend=”italic”>Lettres et p&#xE9;titions</title>( <editor>Legge</editor>
  3. ‘CDqui’: <title type=”MS”>CD</title>qui
  4. ‘( 17et 22)’: ( <ref target=”D1396_17″>17</ref>et <ref target=”D1396_22″>22</ref>)
  5. ‘n o2’: n <hi rend=”sup”>o</hi>2</ref>
  6. ‘Sire’: <hi rend=”bold”>S</hi>ire
  7. ‘T hepresent’: T <hi rend=”sc”>he</hi>present
  8. ‘Le xxx eiour ‘: Le xxx <hi rend=”sup”>e</hi>iour

Another issue is that the speed of loading a page is erratic.  Sometimes it’s instant, other times it takes several agonising seconds.  It’s really frustrating, and it’s not caused by my code.  I’m hoping when we get the new server (which we now have a quote for) this issue will resolve itself.  Also, Some of the pages are split at different points in two texts.  This must be due to the structure of the XML.  However, despite this all of the content is still included.                In addition, a couple of texts in the old system were broken – either the navigation just did not work or page contents were displaying multiple times.  I’m afraid I didn’t make a note of which these were, but they’re all sorted in the new system anyway.

There are currently some issues with footnote numbers due to all of the different ways these are tagged (sometimes with multiple ways being used on a single page).  Some examples:

  1. If multiple ways of tagging are used in the same page this can result in footnotes appearing out of order. This can be because some notes are <note> and others are <app>.  This is also causing some issue with the numbering as well (e.g. there are two [1] footnotes but the first listed should actually be [3].  This clearly needs some work, but I’m not sure how best to fix the issue.  On the old site notes of different types are given letters, but I’m not sure which letters to use for what, and if we want to continue using letters.
  2. In some places note numbers are being displayed where they weren’t previously being displayed. I’m not sure what should be done about this – I could for example add in an option to show / hide the notes.
  3. I’ve ensured all footnotes appear on a new line rather than having some that run on one line and others (sometimes in the same page) that have their own line.
  4. Sometimes an extended form of a footnote number appears where one didn’t previously (e.g. ‘[p2n5]’ rather than just ‘[5]’).
  5. Sometimes multiple notes appear straight after each other, and currently in such cases the numbering appears correctly in the text, but in the footnotes the first number in the line is duplicated. For example [2] and [3] in the text appear as [2] and [2] in the footnotes.

After spending a lot of time over the past two weeks working through the XML texts and wondering why the old site doesn’t display the spacing errors found in the texts I had access to, I did some further investigation into this.  It would appear that the old site uses different versions of the XML files to the ones I’ve been using.  I’m not sure why there are multiple versions of the XML files, but I’ve discovered that there are XML files in the ‘reduce’ folder that Heather gave me access to a couple of weeks ago, and these are different to the ones I have been using and must have been stored somewhere else on the server.

For example, the file ‘kingscouncil.xml’ that I have been using exhibits the spacing issue, see for example ‘M <hi rend=”sup”>c</hi>Moroug‘ and ‘xxx <hi rend=”sup”>e</hi>jour’ in this snippet:


<p> <hi lang=”LA” rend=”italic”>indorsacio</hi>. Eient les supplians la garde et la mariage dedens cestes contenues, selonc la purport de ceste peticion, pour xx. s. vi. d. appaier en le Haneper pur le fyn, par les lettres patentes notre Seignour le Roy souz son grant seel en Irland en due fourme. Doune a Dyvelyn le xxx <hi rend=”sup”>e</hi>jour Doctobre, lan notre dit Seignour le Roy Richard Seconde seszisme. <anchor id=”P4A1″ type=”note”/> <note place=”foot” target=”P4A1″>The <date>30th of October 1392</date>. The regnal years of this king commenced on the <date>22nd of June</date>in each year. Here, and elsewhere throughout the Roll, the year of the present style is used, but no rectification of the day of the month has been attempted.</note>A tresreverent pere <anchor id=”P4A2″ type=”note”/> <note place=”foot” target=”P4A2″>As letters patent were to issue, Robert Archbishop of Dublin, Chancellor of Ireland, must have been the person here addressed. See enrolment No. 15, <hi rend=”italic”>infra</hi>.</note>&amp;c., comme desus.</p> <div n=”2″> <p> <note place=”omargin”> <date>A.D. 1392</date> </note>A tresnobles Justice et Consel notre Seignour le Roy en Irland supplie Johan Creef de Ballaghmoun, que comme sa ville, sa mansion, ses blees et diverses autres benes furent arses, degastes et destruys par M <hi rend=”sup”>c</hi>Moroug et autres Irrois enemys notre Seignour le Roy, comme est comme est cognuz et notifie a vous, tresnobles</p> </div>


But in the ‘reduce’ folder there are two further versions of this (and all) textbase files.  One is named ‘kingscouncil.xml’ but is different to the one I’ve been using.  It has different TEIHeader data and doesn’t exhibit the spacing issue, see for example:


<p><hi lang=”LA” rend=”italic”>indorsacio</hi>. Eient les supplians la garde et la mariage dedens cestes contenues, selonc la purport de ceste peticion, pour xx. s. vi. d. appaier en le Haneper pur le fyn, par les lettres patentes notre Seignour le Roy souz son grant seel en Irland en due fourme. Doune a Dyvelyn le xxx<hi rend=”sup”>e</hi> jour Doctobre, lan notre dit Seignour le Roy Richard Seconde seszisme.<anchor id=”P4A1″ type=”note”/><note place=”foot” target=”P4A1″>The <date>30th of October 1392</date>. The regnal years of this king commenced on the <date>22nd of June</date> in each year. Here, and elsewhere throughout the Roll, the year of the present style is used, but no rectification of the day of the month has been attempted.</note> A tresreverent pere<anchor id=”P4A2″ type=”note”/><note place=”foot” target=”P4A2″>As letters patent were to issue, Robert Archbishop of Dublin, Chancellor of Ireland, must have been the person here addressed. See enrolment No. 15, <hi rend=”italic”>infra</hi>.</note> &amp;c., comme desus.</p></div>

<div n=”2″><p><note place=”omargin”><date>A.D. 1392</date></note> A tresnobles Justice et Consel notre Seignour le Roy en Irland supplie Johan Creef de Ballaghmoun, que comme sa ville, sa mansion, ses blees et diverses autres benes furent arses, degastes et destruys par M<hi rend=”sup”>c</hi>Moroug et autres Irrois enemys notre Seignour le Roy, comme est comme est cognuz et notifie a vous, tresnobles


Finally, there is a further version named ‘kingscouncil-apps.xml’ that appears to be just the text (no TEIHeader), again doesn’t exhibit the spacing issue, but in addition seems to use different tags in places.  See the tag around ‘indorsacio’, for example:


<p><term lang=”LA” rend=”i”>Indorsacio</term>. Eient les supplians la garde et la mariage dedens cestes contenues, selonc la purport de ceste peticion, pour xx. s. vi. d. appaier en le Haneper pur le fyn, par les lettres patentes notre Seignour le Roy souz son grant seel en Irland en due fourme. Doune a Dyvelyn le xxx<hi rend=”sup”>e</hi> jour Doctobre, lan notre dit Seignour le Roy Richard Seconde seszisme.<anchor id=”P4A1″ type=”note”/><note place=”foot” target=”P4A1″>The <date>30th of October 1392</date>. The regnal years of this king commenced on the <date>22nd of June</date> in each year. Here, and elsewhere throughout the Roll, the year of the present style is used, but no rectification of the day of the month has been attempted.</note> A tresreverent pere<anchor id=”P4A2″ type=”note”/><note place=”foot” target=”P4A2″>As letters patent were to issue, Robert Archbishop of Dublin, Chancellor of Ireland, must have been the person here addressed. See enrolment No. 15, <hi rend=”italic”>infra</hi>.</note> &amp;c., comme desus.</p></div>

<div n=”2″><p><note place=”omargin”><date>A.D. 1392</date></note> A tresnobles Justice et Consel notre Seignour le Roy en Irland supplie Johan Creef de Ballaghmoun, que comme sa ville, sa mansion, ses blees et diverses autres benes furent arses, degastes et destruys par M<hi rend=”sup”>c</hi>Moroug et autres Irrois enemys notre Seignour le Roy, comme est comme est cognuz et notifie a vous, tresnobles


So yet again the old site has me wanting to tear my hair out in exasperation at how badly organised, maintained and thought out it is.  It’s looking like I’ll have to replace all of the content I’ve been working on over the past couple of weeks with different versions.  But the question is which version?  Should it be the ‘apps’ version or the other version?  I realise now that the ‘apps’ version is referenced in the URLs used by the old site.  However, what is confusing is the ‘apps’ version doesn’t include the front-matter, but this is included in the old site, meaning it can’t be purely using the ‘apps’ version of the XML.  Even more strangely, the ‘kingscouncil.xml’ file in ‘reduce’ folder has a different structure to the version published on the old site, which is in fact closer to the version of the XML I have been using.  On the old site the first page begins:


“[p.xxvi]

INTRODUCTION.

[…]

Whether the Roll…”


But the ‘reduce’ version of ‘kingscouncil.xml’ includes two previous pages:


<pb n=”ix”/><div lang=”EN” type=”Introduction”><head>INTRODUCTION.</head>

<pb n=”xxv”/><p>It may be mentioned here that the folios are all mounted on linen guards, and that no part of the parchment has been inserted into the back, and none cut away at the fore-edge, top, or bottom, of the volume.</p>

<pb n=”xxvi”/><p>Whether the Roll…


Whereas the XML I’ve been using matches the published text:


<pb n=”xxvi” ed=”base”/><div lang=”EN” type=”Introduction”><head>INTRODUCTION.</head>

<p>[…]</p>

<p>Whether the Roll…


I had been intending to extract pages from the non-apps files in the ‘reduce’ folder and to present these alongside the existing pages in the front-end so the editors could look at them, but I’m encountering difficulties right from the start.  The first XML file in the data I originally had is ‘albus.xml’, which I expected to find as ‘albus-apps.xml’, yet there is no such file in the ‘reduce’ folder, nor a non-app ‘albus.xml’ file.  There are files called ‘libalbapp.xml’ and ‘libalbapp-apps.xml’, which would seem to correspond to the AND Source reference (Lib_Alb).  However, the contents of these files in no way correspond to the contents of the ‘albus.xml’ file I have and nor do they correspond to the text that is displayed on the old site at the above URL.

I can only conclude that there is yet another version of the files stored in another location that the old site uses.  It’s definitely not the same file as I have been using as the text on the old site has the spacing issue corrected.  I have done a ‘find in files’ for certain strings found in the ‘Albus’ text across all files in the ‘reduce’ folder and the text is definitely not found there.  It’s very confusing as the scripts suggest they are processing files only in this folder.  The script ‘and-getloc’ uses the variable ‘filename’ from the URL and passes this to the script ‘and-fetcher’ in the ‘reduce’ folder.  This in turn loads the file, finds and processes the required page.

As I was working through this I managed to figure things out.  It looks like I was right – there is yet another version of the files stored somewhere else that the old system actually uses.  Buried towards the end of the ‘and-fetcher’ script is this:

##############################################

## TODO !!!!

## HARDCODED TEXTS LOCATION HERE!

## SHIFT THIS TO CONSTANTS SYSTEM!!!

##

my $textpath = “/and/reduce/ready1/$text”;

##

##############################################

So the texts that are used are in a folder called ‘ready1’ within the ‘reduce’ folder.  However, there were no subfolders in the zip file of the ‘reduce’ folder that Heather sent me a couple of weeks ago.  If we can somehow track down this fourth(!) version of the files then perhaps I’ll be able to make some progress.  Heather managed to get access to the server again and located the additional folder, which did indeed include yet another version of the XML files.  It looks like this fourth version is the correct version.  It would appear to be the files that appear on the old website, including correction of spacings and all front matter (despite all files ending in ‘apps’, whereas the other ‘apps’ versions didn’t include the front matter).  Looking at the files discussed above:

The file ‘albus-apps.xml’ is present and includes all front-matter the same as both the file I was previously working with and the old site, but with spacing issues fixed.  The file ‘kingscouncil-apps’ also appears to be structurally identical to the ‘kingscouncil’ file I was originally working with (unlike the other two versions in ‘reduce’) and has the spacing issues fixed (e.g. M<hi rend=”sup”>c</hi>Moroug).

So now I’ll be able to begin again with the process I started a couple of weeks ago.  It’s going to take some time again, although hopefully most of the XSLT issues will be the same as before and will already be sorted.

Also this week I read through the bib documentation for Craig Lamont’s project and had a chat with him about a data management plan, which I’ll have to work on next week.  I also fixed a couple of issues on the SCOCO website for Matthew Creasy and spoke to Mike Black about the quote for a new server, which will hopefully be purchased soon.  I gave some advice to Katie Halsey about file formats and data transfer options for a new digitisation unit that will be working with the Books and Borrowing project, and also spent some time trying to sort out access to the server at Stirling for this project as it turned out that my access privileges had been removed midway through last month.

I also fixed an issue with the bibliography search on the new DSL website.  This was occurring when a search for ‘author or title’ was performed, which prefixes ‘Author: ‘ or ‘Title: ‘ to each entry in the autocomplete to help users differentiate between the two.  Selecting from the autocomplete list ran the search fine as this was based on the bibliographical ID hidden in the autocomplete, but if you pressed the ‘search’ button before the event was fired the search was looking for the full contents of the box – i.e. looking for authors and titles that begin with ‘Author: ‘ or ‘Title: ‘.  This was also happening if you pressed the browser’s back button from the results as the textbox would still then contain the full text.  I fixed this issue.  So it’s been a pretty busy week.

Week Beginning 24th May 2021

I had my first dose of the Covid vaccine on Tuesday morning this week (the AstraZeneca one), so I lost a bit of time whilst going to get that done.  Unfortunately I had a bit of a bad reaction to it and ended up in bed all day Wednesday with a pretty nasty fever.  I had Covid in October last year but only experienced mild symptoms and wasn’t even off work for a day with it, so in my case the cure has been much worse than the disease.  However, I was feeling much better again by Thursday, so I guess I lost a total of about a day and a half of work, which is a small price to pay if it helps to ensure I don’t catch Covid again and (what would be worse) pass it on to anyone else.

In terms of work this week I continued to work on the Anglo-Norman Dictionary, beginning with a few tweaks to the data builder that I had completed last week.  I’d forgotten to add a bit of processing to the MS date that was present in the Text Date section to handle fractions, so I added that in.  I also updated the XML output so that ‘pref’ and ‘suff’ only appear if they have content now, as the empty attributes were causing issues in the XML editor.

I then began work on the largest outstanding task I still have to tackle for the project: the migration of the textbase texts to the new site.  There are about 80 lengthy XML digital editions on the old site that can be searched and browsed, and I need to ensure these are also available on the new site.  I managed to grab a copy of all of the source XML files and I tracked down a copy of the script that the old site used to process the files.  At least I thought I had.  It turned out that this file actually references another file that must do most of the processing, including the application of an XSLT file to transform the XML into HTML, which is the thing I really could do with getting access to.  Unfortunately this file was no in the data from the server that I had been given access to, which somewhat limited what I could do.  I still have access to the old site and whilst experimenting with the old textbase I managed to make it display an error message that gives the location of the file: [DEBUG: Empty String at /var/and/reduce/and-fetcher line 486. ].  With this location available I asked Heather, the editor who has access to the server, if she might be able to locate this file and others in the same directory.  She had to travel to her University in order to be able to access the server, but once she did she was able to track the necessary directory down and get a copy to me.  This also included the XSLT file, which will help a lot.

I wrote a script to process all of the XML files, extracting titles, bylines, imprints, dates, copyright statements and splitting each file up into individual pages.  I then updated the API to create the endpoints necessary to browse the texts and navigate through the pages, for example the retrieval of summary data for all texts, or information about a specified texts, or information about a specific page (including its XML).  I also began working on a front-end for the textbase, which is still very much in progress.  Currently it lists all texts with options to open a text at the first available page or select a page from a drop-down list of pages.  There are also links directly into the AND bibliography and DEAF where applicable, as the following screenshot demonstrates:

It is also possible to view a specific page, and I’ve completed work on the summary information about the text and a navbar through which it’s possible to navigate through the pages (or jump directly to a different page entirely).  What I haven’t yet tackled is the processing of the XML, which is going to be tricky and I hope to delve into next week.   Below is a screenshot of the page view as it currently looks, with the raw XML displayed.

I also investigated and fixed an issue the editor Geert spotted, whereby the entire text of an entry was appearing in bold.  The issue was caused by an empty <link_form/> tag.  In the XSLT each <link_form> becomes a bold tag <b> with the content of the link form in the middle.  As there was no content it became a self-closed tag <b/> which is valid in XML but not valid in HTML, where it was treated as an opening tag with no corresponding closing tag, resulting in the remainder of the page all being bold.  I got around this by placing the space that preceded the bold tag “ <b></b>” within the bold tag instead “<b> </b>” meaning the tag is no longer considered empty and the XSLT doesn’t self-close it, but ideally if there is no <link_form> then the tag should just be omitted, which would also solve the problem.

I also looked into an issue with the proofreader that Heather encountered.  When she uploaded a ZIP file with around 50 entries in it some of the entries wouldn’t appear in the output, but would just display their title.  The missing entries would be random without any clear reason as to why some were missing.    After some investigation I realised what the problem was:  each time an XML file is processed for display the DTD referenced in the file was being checked.  When processing lots of files all at once this was exceeding the maximum number of file requests the server was allowing from a specific client and was temporarily blocking access to the DTD, causing the processing of some of the XML files to silently fail.  The maximum number would be reached at a different point each time, thus meaning a different selection of entries would be blank.  To fix this I updated the proofreader script to remove the reference to the DTD from the XML files in the uploaded ZIP before they are processed for display.  The DTD isn’t actually needed for the display of the entry – all it does is specify the rules for editing it.  With the DTD reference removed it looks like all entries are getting properly displayed.

Also this week I gave some further advice to Luca Guariento about a proposal he’s working on, fixed a small display issue with the Historical Thesaurus and spoke to Craig Lamont about the proposal he’s putting together.  Other than that I spent a bit of time on the Dictionary of the Scots Language, creating four different mockups of how the new ‘About this entry’ box could look and investigating why some of the bibliographical links in entries in the new front-end were not working.  The problem was being caused by the reworking of cref contents that the front-end does in order to ensure only certain parts of the text become a link.  In the XML the bib ID is applied to the full cref, (e.g. <cref refid=”bib018594″><geo>Sc.</geo> <date>1775</date> <title>Weekly Mag.</title> (9 Mar.) 329: </cref>) but we wanted the link to only appear around titles and authors rather than the full text.  The issue with the missing links was cropping up where there is no author or title for the link to be wrapped around (e.g. <cit><cref refid=”bib017755″><geo>Ayr.</geo><su>4</su> <date>1928</date>: </cref><q>The bag’s fu’ noo’ we’ll sadden’t.</q></cit>).  In such cases the link wasn’t appearing anywhere.  I’ve updated this now so that if no author or title is found then the link gets wrapped around the <geo> tag instead, and if there is no <geo> tag the link gets wrapped around the whole <cref>.

I also fixed a couple of advanced search issues that had been encountered with the new (and as yet not publicly available) site.  There was a 404 error that was being caused by a colon in the title.  The selected title gets added into the URL and colons are special characters in URLs, which was causing a problem.  However, I updated the scripts to allow colons to appear and the search now works.  It also turned out that the full-text searches were searching the contents of the <meta> tag in the entries, which is not something that we want.  I knew there was some other reason why I stripped the <meta> section out of the XML and this is it.  The contents of <meta> end up in the free-text search and are therefore both searchable and returned in the snippets.  To fix this I updated my script that generates the free-text search data to remove <meta> before the free-text search is generated.  This doesn’t remove it permanently, just in the context of the script executing.  I regenerated the free-text data and it no longer includes <meta>, and I then passed this on to Arts IT Support who have the access rights to update the Solr collection.  With this in place the advanced search no longer does anything with the <meta> section.

Week Beginning 10th May 2021

I continued to work on updates to the Anglo Norman Dictionary for most of this week, looking at fixing the bad citation dates in entries that were causing the display of ‘earliest date’ to be incorrect.  A number of the citation dates have a proper date in text form (e.g. s.xii/xiii) but have incorrect ‘post’ and ‘pre’ attributes (e.g. ‘00’ and ‘99’).  The system uses these ‘post’ and ‘pre’ attributes for date searching and for deciding which is the earliest date for an entry, and if one of these bad dates was encountered it was considering it to be the earliest date.  Initially I thought there were only a few entries that had ended up with an incorrect earliest date, because I was searching the database for all earliest dates that were less than 1000.  However, I then realised that the bulk of the entries with incorrect earliest dates had the earliest date field set to ‘null’ and in database queries ‘null’ is not considered less than 1000 but a separate thing entirely and so such entries were not being found.  I managed to identify several hundred entries that needed their dates fixed and wrote a script to do so.

It was slightly more complicated than a simple ‘find and replace’ as the metadata about the entry needed to be regenerated too – e.g. the dates extracted from the citations that are used in the advanced search and the earliest date display for entries.  I managed to batch correct several hundred entries using the script and also adapted it to look for other bad dates that needed fixing too.

I also created a new feature for the Dictionary Management System: an entry proofreader.  It allows an editor to attach a ZIP file containing XML entries and it then displays all of these in a similar manner to the live site, only with all entries on one long page.  The editor can then select all of the text, copy it and then paste it into Word and the major formatting elements will be retained (bold, italic, superscript etc.).  I tested the feature by zipping up 3,178 XML entries and although it took a few minutes to process, the page displayed properly and I was able to copy the text to Word (resulting in a 1,029 page Word file).  After finishing the initial version of the script I had to tweak it a bit, as I wrote the HTML and JavaScript with the expectation that there would be one dictionary item on the page and some aspects were not working when there were multiple items and needed updating.  I also ensured that links to sources in entries work.  In the actual dictionary they open a pop-up, which clearly isn’t going to work in Word so instead I made the link go to the relevant item in the bibliography page (e.g. https://anglo-norman.net/bibliography/B#bib-Best).  Links to other dictionaries, labels and other AND entries also all now work from Word.

In addition, cogrefs appear before variants and deviants, commentaries appear (as full text, not cut off), Xrefs at the bottom now have the ‘see also’ text above them as in the live site, editor initials now appear where they exist and numerals only appear where there is more than once sense in a POS.

Also this week I did some further work for the Dictionary of the Scots Language based on feedback after my upload of data from the DSL’s new editing system.  There was a query about the ‘slug’ used for referencing an entry in a URL.  When the new data is processed by the import script the ‘slug’ is generated from the first <url> entry in the XML.  If this <url> begins ‘dost’ or ‘snd’ it means a headword is not present in the <url> and therefore the new system ID is taken as the new ‘slug’ instead.  All <url> forms are also stored as alternative ‘slugs’ that can still be used to access the entry.  I checked the new database and there are 3258 entries that have a ‘slug’ beginning with ‘dost’ or ‘snd’, i.e. they have the new ID as their ‘slug’ because they had an old ID as their first <url> in the XML.  I checked a couple of these and they don’t seem to have the headword as a <url>, e.g. ‘beit’ (dost00052776) only has the old ID (twice) as URLs: <url>dost2543</url><url>dost2543</url>, ‘well-fired’ (snd00090568) only has the old ID (twice) as URLs: <url>sndns4098</url><url>sndns4098</url>.  I’ve asked the editors what should be done about this.

Also this week I wrote a script to generate a flat CSV from the Historical Thesaurus’s relational database structure, joining the lexeme and category tables together and appending entries from the new ‘date’ table as additional columns as required.  It took a little while to write the script and then a bit longer to run it, resulting in a 241MB CSV file.

I also gave some advice to Craig Lamont in Scottish Literature about a potential bid he’s putting together, and spoke to Luca about a project he’s been asked to write a DMP for.  I also looked through some journals that Gerry Carruthers is hoping to host at Glasgow and gave him an estimate of the amount of time it would take to create a website based on the PDF contents of the old journal items.