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 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 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.
I continued to work on the new textbase search facilities for the Anglo-Norman Dictionary this week. I completed work on the required endpoints for the API, creating the facilities that would process a search term (with optional wildcards), limit the search to selected books and or genres and return either full search results in the case of an exact search for a term or a list of possible matching terms and the number of occurrences of each term. I then worked on the front-end to enable a query to be processed and submitted to the API based on the choices made by the user.
By default any text entered will match any term that contains the text – e.g. enter ‘jour’ (without apostrophes) and you’ll find all forms containing the characters ‘jour’ anywhere e.g. ‘adjourner’, ‘journ’. If you want to do an exact match you have to use double quotes – “jour”. You can also use an asterisk at the beginning or end to match forms starting or ending with the term – ‘jour*’ and ‘*jour’ or an asterisk at both ends ‘*jour*’ will only find forms that contain the term somewhere in the middle. You can also use a question mark wildcard to denote any single character, e.g. ‘am?n*’ will find words beginning ‘aman’, ‘amen’ etc.
If your selected form in your selected books / genres matches multiple forms then an intermediary page bringing up a list of matching forms and a count of the number of times each form appears will be displayed. This is the same as how the ‘translation’ advanced search works, for example, and I wanted to maintain a consistent way of doing things across the site. Select a specific form and the actual occurrences of each item in the texts will appear. Above this list is a ‘Select another form’ button that returns you to the intermediary page. If your search only brings back one form the intermediary page is skipped, and as all selection options appear in the URL it’s possible to bookmark / cite the search results too.
Whilst working on this I realised that I’d need to regenerate the data, as it became clear that many words have been erroneously joined together due to there being no space between words when one tag is closed and a following one is opened. When the tags are then stripped out the forms get squashed together, which has led to some crazy forms such as ‘amendeezreamendezremaundez’. Previously I’d not added spaces between tags as I was thinking that a space would have to be ended before a closing tag (e.g. ‘</’ becomes ‘ </’) and this would potentially mess up words that have tags in them, such as superscript tags in names like McDonald. However, I realised I could instead do a find and replace to add spaces between a closing tag and an opening tag (‘><’ becomes ‘> <’, which would not mess up individual tags within words and wouldn’t have any further implications as I strip out all additional spaces when processing the texts for search purposes anyway.
I also decided that I should generate the ‘key-word in context’ (KWIC) for each word and store this in the database. I was going to generate this on the fly every time a search results page was displayed but it seems more efficient to generate and store this once rather than do it every time. I therefore updated by data processing script to generate the KWIC for each of the 3.5 million words as they were extracted from the texts. This took some time to both implement and execute. I decided to pull out the 10 words on either side of the term, which used the ‘word order’ column that gets generated as each page is processed. Some complications were introduced in cases where the term is either before the tenth word on the page or there are less than ten words after the term on the page. I such cases the script needed to look at the page before or after the current page in order to pull out the words and fill out the KWIC with the appropriate words on the other pages.
With the updates to data processing in place and a fair bit of testing of the KWIC facility carried out, I re-ran my scripts to regenerate the data and all looked good. However, after inserting the KWIC data the querying of the tables slowed to a crawl. On my local PC queries which were previously taking 0.5 seconds were taking more than 10 seconds, while on the server execution time was almost 30 seconds. It was really baffling as the only difference was the search words table now had two additional fields (KWIC left and KWIC right), neither of which were being queried or returned in the query. It seemed really strange that adding new columns could have such an effect if they were not even being used in a query. I had to spend quite a bit of time investigating this, including looking at MySQL settings such as key buffer size and trying again to change storage engines, switching from MyISAM to InnoDB and back again to see what was going on. Eventually I looked again at the indexes I’d created for the table, and decided to delete them and start over, in case this somehow jump-started the search speed. I previously had the ‘word stripped’ column indexed in a multiple column index with page ID and word type (either main page or textual apparatus). Instead I created an index of the ‘word stripped’ column on its own, and this immediately boosted performance. Queries that were previously taking close to 30 seconds to execute on the server were now taking less than a second. It was such a relief to have figured out what the issue was, as I had been considering whether my whole approach would need to be dropped and replaced by something completely different.
As I now had a useable search facility I continued to develop the front-end that would use this facility. Previously the exact match for a term was bringing up just the term in question and a link through to the page the term appeared on, but now I could begin to incorporate the KWIC text too. My initial idea was to use a tabular layout, with each word of the KWIC in a different column, with a clickable table heading that would allow the data to be ordered by any of the columns (e.g. order the data alphabetically by the first word to the left of the term). However, after creating such a facility I realised it didn’t work very well. The text just didn’t scan very well due to columns having to be the width of whatever the longest word in the column was, and the text just took up too much horizontal space. Instead, I decided to revert to using an unordered list, with the KWIC left and KWIC right in separate spans, with KWIC left right aligned to push it up against the search term no matter what the length of the KWIC left text. I split the KWIC text up into individual words and stored this in an array to enable each search result to be ordered by any word in the KWIC, and began working on a facility to change the order using a select box above the search results. This is as far as I got this week, but I’m pretty confident that I’ll get things finished next week. Here’s a screenshot of how the KWIC looks so far:
Also this week I had an email conversation with the other College of Arts developers about professional web designers after Stevie Barrett enquired about them, arranged to meet with Gerry Carruthers to discuss the journal he would like us to host, gave some advice to Thomas Clancy about mailing lists and spoke to Joanna Kopaczyk about a website she would like to set up for a conference she’s organising next year.
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.
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.
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:
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.
This was my second and final week staying at my parents’ house in Yorkshire, where I’m working a total of four days over the two weeks. This week I had an email conversation with Eleanor Lawson about her STAR project, which will be starting very shortly. We discussed the online presence for the project, which will be split between a new section on the Seeing Speech website and an entirely new website, the project’s data and workflows and my role over the 24 months of the project. I also created a script to batch process some of the Edinburgh registers for the Books and Borrowing project. The page images are double spreads and had been given a number for both the recto and the verso (e.g. 1-2, 3-4), but the student registers only ever use the verso page. I was therefore asked to write a script to renumber all of these (e.g. 1-2 becomes 1, 3-4 becomes 2), which I created and executed on a test version of the site before applying to the live data.
I also continued to make tweaks to the front-ends for the Comparative Kingship project. I fixed a bug with the Elements glossary of the Irish site, which was loading the Scottish version instead. I also contacted Chris Fleet at NLS Maps to enquire about using a couple of their historical Irish maps with the site. I also fixed the ‘to top’ button in the CMSes not working; the buttons now actually scroll the page to the top as they should. I also fixed some issues relating to parish names no longer being unique in the system (e.g. the parish of Gartly is in the system twice due to it changing county at some point). This was causing issues with the browse option as data was being grouped by parish name. Changing the grouping to the parish ID thankfully fixed the issue.
I also had a chat with Ann Fergusson at the DSL about multi-item bibliographical entries in the existing DSL data. These are being split into individual items, and a new ‘sldid’ attribute in the new data will be used to specify which item in the old entry the new entry corresponds to. We agreed that I would figure out a way to ensure that these IDs can be used in the new website once I receive the updated data.
My final task of the week was to investigate a problem with Rob Maslen’s City of Lost Books blog (https://thecityoflostbooks.glasgow.ac.uk/) when went offline this week and only displayed a ‘database error’. Usually when this happens it’s a problem with the MySQL database and it takes down all of the sites on the server, but this time it was only Rob’s site that was being affected. I tried accessing the WP admin pages and this gave a different error about the database being corrupted. I needed to update the wordpress config file to add the line define(‘WP_ALLOW_REPAIR’, true); and upon reloading the page WordPress attempted to fix the database. After doing so it stated that “The wp_options table is not okay. It is reporting the following error: Table is marked as crashed and last repair failed. WordPress will attempt to repair this table… Failed to repair the wp_options table. Error: Wrong block with wrong total length starting at 10356”. WordPress appeared to regenerate the table, as after this the table existed and was populated with data and the blog went online again and could be logged into. I’ll have to remember this if it happens again in future.
Next week I’ll be back in Glasgow.
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.
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.