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:
- ‘M cMoroug’: M <hi rend=”sup”>c</hi>Moroug
- ‘Lettres et pétitions( Legge’: <title lang=”FR” rend=”italic”>Lettres et pétitions</title>( <editor>Legge</editor>
- ‘CDqui’: <title type=”MS”>CD</title>qui
- ‘( 17et 22)’: ( <ref target=”D1396_17″>17</ref>et <ref target=”D1396_22″>22</ref>)
- ‘n o2’: n <hi rend=”sup”>o</hi>2</ref>
- ‘Sire’: <hi rend=”bold”>S</hi>ire
- ‘T hepresent’: T <hi rend=”sc”>he</hi>present
- ‘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:
- 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  footnotes but the first listed should actually be . 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.
- 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.
- 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.
- Sometimes an extended form of a footnote number appears where one didn’t previously (e.g. ‘[p2n5]’ rather than just ‘’).
- 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  and  in the text appear as  and  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>&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> &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> &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:
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>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.
It was the late May bank holiday on Monday, so this was a four-day week. On Tuesday I decided to try working at my office at the University – my first full day back at my office since the first lockdown began. All went very smoothly; I didn’t meet anyone in the building and it seemed very quiet on campus generally. The only issue was the number of updates my computer had to install, which caused some delays. I’m probably going to try and come back to work on Tuesdays on a semi-regular basis now to see how things go.
I had some discussions with Marc and Arts IT Support this week about the possibility of purchasing a new server, and some progress is being made there. I also responded to a query regarding the Scots Syntax Atlas that Jennifer Smith forwarded on to me and spoke to Roslyn Potter about a project that a lecturer in History is needing a website for.
Other than these tasks I spent the week continuing to work on the Textbase feature of the Anglo-Norman Dictionary. Last week I’d left off with the infrastructure in place to browse texts, display the raw XML of pages and navigate between pages. My task for this week was to ensure that the XML displayed properly. This proved to be rather tricky as although I had managed to get access to the XSLT file that the Textbase on the old site used to transform the XML to HTML, it included a lot of stuff that wasn’t needed in the new site (e.g. formatting headers and footers) and also 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,000 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 fid a way to fix this tag issue. After some Googling I discovered that there is a PHP extension called Tidy (https://www.php.net/manual/en/intro.tidy.php) 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,000 pages through it.
With a full set of valid XML page files I then began work on the XSL to display the documents as required. This has been a very laborious process as I needed to go through each of the more than 70 documents and check the layout for any issues, and fix these as they cropped up. With more than 12,000 pages I couldn’t look at each individually, but instead took a random selection, a process that’s is working pretty well so far. The largest challenge was getting the explanatory notes to appear correctly, as these had been tagged in at least eight different ways throughout the documents, sometimes with entirely different XML structures and content. So far all is looking good, and I’m about halfway through checking the documents. I’ll continue with this task next week.
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.
I spent a lot of this week continuing with the Anglo-Norman Dictionary, including making some changes to the proofreader feature I created recently. I tweaked the output of this so that there is now a space between siglum and ‘MS’, ‘edgloss’ now has brackets and there is now a blank paragraph before the ‘summary’ section and also before the ‘cognate refs’ section to split things up a bit. I also added some characters (~~) before and after the ‘summary’ section to help split things up and added extra spaces before and after sense numbers, and square brackets around them (because background styles, which give the round, black circle are not carried over into Word when the content is copied). I also added more spaces round the labels, added an extra line break before locutions and made the locution phrase appear in bold.
I also spent some time investigating some issues with the data, for example a meaning was not getting displayed in the summary section of https://anglo-norman.net/entry/chaucer_3 because the part of speech labels didn’t quite match up (one was ‘subst.’, the other was ‘sbst.’) and updated the entry display so that the ‘form section’ at the top of an entry gets displayed even if there is no ‘cognate refs’ section. My code repositions the ‘formSection’ so it appears before ‘cognateRefs’ and as it was not finding this section it wasn’t repositioning the forms anywhere – instead they just disappeared. I therefore updated the code to ensure that the forms will only be repositioned if the ‘cognateRefs’ section is present, and this has fixed the matter.
I also responded to a request for data from a researcher at Humboldt-Universität zu Berlin who wanted information on entries that featured specific grammatical labels. As of yet the advanced search does not include a part of speech search, but I could generate the necessary data from the underlying database. I also ran a few queries to update further batches of bad dates in the system.
My initial version allowed an editor to add Text and MS dates using the input boxes and then by pressing the ‘Generate XML’ button the ‘XML’ box is populated and the date as it would be displayed on the site is also displayed. I amalgamated the ‘proof’ and ‘Build XML’ options from the old DMS as it seemed more useful to just do both at the same time. There is also a ‘clear’ button that does what you’d expect it to do and a ‘log’ that displays feedback about the date. E.g. if the date doesn’t conform to the expected pattern (yyyy / yyyy-yyyy / yyyy-yy / yyyy-y) or one of the characters isn’t a number or the date after the dash is earlier than the date before the dash then a warning will be displayed here. The XML area is editable so if needs be the content can be manually tweaked. There is also a ‘Copy XML’ button to copy the contents of the XML area to the clipboard.
Also this week I set up some new user accounts for the Books and Borrowing project, I gave Luca Guariento some feedback about an AHRC proposal, I had to deal with the server and database going down a few times and I added a new publication to the SCOSYA website.
Finally, I made some further tweaks to the Comparative Kingship content management systems for Scottish and Irish placenames. When I set up the two systems I’d forgotten to add the x-refs section into the form. The code was all there to handle them, but the section wasn’t appearing. I therefore updated both Scotland and Ireland so x-refs now appear. I’d also noticed that some of the autogenerated lists that appear when you type into boxes in the Ireland site(e.g. xrefs) were pointing to the Scotland database and therefore bringing back the wrong data and I fixed this too.
I also added all of the sources from the Kirkcudbrightshire system to the Scotland CMS and replaced the Scotland elements database with the one from KCB as well, which required me to check the elements already associated with names to ensure they point to the same data. Thankfully all did except the existing name ‘Rhynie’, which was newly added and its ID ended up referencing an entirely different element from the KCB database, but I fixed this. I also fixed a bug with the name and element deletion code that was preventing things for getting deleted.
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.
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.
I then spent some time investigating why part of speech in the <senseInfo> element of senses sometimes used underscores and other times used spaces. This discrepancy was messing up the numbering of senses, as this depends on the POS, with the number resetting to 1 when a new POS is encountered. If the POS is sometimes recorded as ‘p.p._as_a.’ (for example) and other times as ‘p.p. as a.’ then the code thinks these are different parts of speech and resets the counter to 1. I looked at the DTD, which sets the rules for creating or editing the XML files and it uses the underscore form of POS. However, this rule only applies to the ‘type’ attribute of the <pos> element and not to the ‘pos’ attribute of the <senseInfo> element. After investigating it turned out that these ‘pos’ attributes that the numbering system relies on are not manually added in by the editors, but are added in by my scripts at the point of upload. The reason I set up my script to add these in is because the old systems also added these in automatically during the conversion of the editors’ XML into the XML published via the old Dictionary Management System. However, this old system refactored the POS, replacing underscores with spaces and thus storing two different formats of POS within the XML. My upload scripts didn’t do this but instead kept things consistent, and this meant that when an entry was edited to add a new sense the new sense was added with the underscore form of POS, but the existing senses still had the space form of POS.
There were two possible ways I could fix this, I could either write a script that regenerates the <senseInfo> pos for every sense and subsense in every entry, replacing all existing ‘pos’ with the value of the preceding <pos type=””> (i.e. removing all old space forms of POS and ensuring all POS references were consistent); or I could adapt my upload script so that the assignment of <senseInfo> pos treats both ‘underscore’ and ‘space’ versions as the same. I decided on the former approach and wrote a script to first identify and then update all of the dictionary entries.
The script goes through each entry and finds all that have a <senseInfo> pos with a space in. There are 2,538 such entries. I then adapted the script so that for each <senseInfo> in an entry all spaces are changed to underscores and the result is then compared with the preceding <pos> type. I set the script to output content if there was a mismatch between the <senseInfo> pos and the <pos> type, because when I set the script to update it will use the value from <pos> type, so as to ensure consistency. The script identified 41 entries where there was a mismatch between <senseInfo> pos and the preceding <pos> type. These were often due to a question mark being added to the <senseInfo> pos, e.g. ‘a. as s. ?’ vs ‘a._as_s._’, but there were also some where the POS was completely different, e.g. ‘sbst. inf.’ and ‘v.n.’. I spoke to the editor Geert about this and it turned out that these were due to a locution being moved in the XML without having the pos value updated. Geert fixed these and I ran the update to bring all of the POS references into alignment.
My final AND task was to look into some issues regarding the variant and deviant section of the entry (where alternative forms of the headword are listed). Legiturs in this section were not getting displayed, plus there were several formatting issues that needed addressed, such as brackets not appearing in the right place and line breaks not worked as they should. This was a very difficult task to tackle as there is so much variety to the structure of this section, and the XML is not laid out in the most logical of manners, for example references are not added as part of a <variant> or <deviant> tag but are added after the corresponding tag as a sibling <varref> element. This really complicates navigating through the variants and deviants as there may be any number of varrefs at the same level. However, I managed to address the issues with this section, ensuring the legiturs appeared, repositioning semi-colons outside of the <deviant> brackets, ensuring line breaks always occur when a new POS is encountered and don’t occur anywhere else, ensuring multiple occurrences of the same POS label don’t get displayed and fixing the issue with double closing brackets sometimes appearing. It’s likely that there will be other issues with this section, as the content and formatting is so varied, but for now that’s all issues sorted.
The only other project I worked for this week was the Iona place-names project, for which I helped the RA Sofia with the formatting of this month’s ‘name of the month’ feature (https://iona-placenames.glasgow.ac.uk/names-of-the-month/). Next week I’ll continue with the outstanding AND tasks, of which there are still several.
I continued with the import of new data for the Dictionary of the Scots Language this week. Raymond at Arts IT Support has set up a new collection and had imported the full-text search data into the Solr server, and I tested this out via the new front-end I’d configured to work with the new data source. I then began working on the import of the bibliographical data, but noticed that the file exported from the DSL’s new editing system didn’t feature an attribute denoting what source dictionary each record is from. We need this as the bibliography search allows users to limit their search to DOST or SND. The new IDs all start with ‘bib’ no matter what the source is. I had thought I could use the ‘oldid’ to extract the source (db = DOST, sb = SND) but I realised there are also composite records where the ‘oldid’ is something like ‘a200’. In such cases I don’t think I have any data that I can use to distinguish between DOST and SND records. The person in charge of exporting the data from the new editing system very helpfully agreed to add in a ‘source dictionary’ attribute to all bibliographical records and sent me an updated version of the XML file. Whilst working with the data I realised that all of the composite records are DOST records anyway, so I didn’t need the ‘sourceDict’ attribute, but I think it’s better to have this explicitly as an attribute as differentiating between dictionaries is important.
I imported all of the bibliographical records into the online system, including the composite ones as these are linked to from dictionary entries and are therefore needed, even though their individual parts are also found separately in the data. However, I decided to exclude the composite records from the search facilities, otherwise we’d end up with duplicates in the search results. I updated the API to use the new bibliography tables and I updated the new front-end so that bibliographical searches use the new data. One thing that needs some further work is the display of individual bibliographies. These are now generated from the bibliography XML via an XSLT whereas previously they were generated from a variety of different fields in the database. The display doesn’t completely match up with the display on the live and Sienna versions of the bibliography pages and I’m not sure exactly how the editors would like entries to be displayed. I’ll need further input from them on this matter, but the import of data from the new editing system has now been completed successfully. I’d been documenting the process as I worked through it and I sent the documentation and all scripts I wrote to handle the workflow to the editors to be stored for future use.
I also worked on the Books and Borrowing project this week. I received the last of the digitised images of borrowing registers from Edinburgh (other than one register which needs conservation work), and I uploaded these to the project’s content management system, creating all of the necessary page records. We have a total of 9,992 page images as JPEG files from Edinburgh, totalling 105GB. Thank goodness we managed to set up an IIIF server for the image files rather than having to generate and store image tilesets for each of these page images. Also this week I uploaded the images for 14 borrowing registers from St Andrews and generated page records for each of these.
I had a further conversation with GIS expert Piet Gerrits for the Iona project and made a couple of tweaks to the Comparative Kingship content management systems, but other than that I spent the remainder of the week returning to the Anglo-Norman Dictionary, which I hadn’t worked on since before Easter. To start with I went back through old emails and documents and wrote a new ‘to do’ list containing all of the outstanding tasks for the project, some 20 items of varying degrees of size and intricacy. After some communication with the editors I began tackling some of the issues, beginning with the apparent disappearance of <note> tags from certain entries.
In the original editor’s XML (the XML as structured before uploaded into the old DMS) there were ‘edGloss’ notes tagged as ‘<note type=”edgloss” place=”inline”>’ that were migrated to <edGloss> elements during whatever processing happened with the old DMS. However, there were also occasionally notes tagged as ‘<note place=”inline”>’ that didn’t get transformed and remained tagged as this.
I’m not entirely sure how or where, but at some point during my processing of the data these ‘<note place=”inline”>’ notes have been lost. It’s very strange as the new DMS import script is based entirely on the scripts I wrote to process the old DMS XML entries, but I tested the DMS import by uploading the old DMS XML version of ‘poer_1’ to the new DMS and the ‘<note place=”inline”>’ have been retained, yet in the live entry for ‘poer_1’ the <note> text is missing.
I searched the database for all entries where the DMS XML as exported from the old DMS system contains the text ‘<note place=”inline”>’ and there are 323 entries, which I added to a spreadsheet and sent to the editors. It’s likely that the new XML for these entries will need to be manually corrected to reinstate the missing <note> elements. Some entries (as with ‘poer_1’) have several of these. II still have the old DMS XML for these so it is at least possible to recover the missing tags. I wish I could identify exactly when and how the tags were removed, but that would quite likely require many hours of investigation, as I already spent a couple of hours trying to get to the bottom of the issue without success.
Moving on to a different issue, I changed the upload scripts so that the ‘n’ numbers are always fully regenerated automatically when a file is uploaded, as previously there were issues when a mixture of senses with and without ‘n’ numbers were included in an entry. This means that any existing ‘n’ values are replaced, so it’s no longer possible to manually set the ‘n’ value. Instead ‘n’ values for senses within a POS will always increment from 1 depending on the order they appear in the file, with ‘n’ being reset to 1 whenever a new POS is encountered.
Main senses in locutions were not being assigned an ‘n’ on upload, and I changed this so that they are assigned an ‘n’ in exactly the same way as regular main senses. I tested this with the ‘descendre’ entry and it worked, although I encountered an issue. The final locution main sense (to descend to (by way of inheritance)) had a POS of ‘sbst._inf.’ In its <senseInfo> whereas it should have been (based on the POS of the previous two senses) ‘sbst. Inf.’. The script was therefore considering this to be a new POS and gave the sense an ‘n’ of 1. In my test file I updated the POS and re-uploaded the file and the sense was assigned the correct value of 3 to its ‘n’, but we’ll need to investigate why a different form of POS was recorded for this sense.
I also updated the front-end so that locution main senses with an ‘n’ now have the ‘n’ displayed, (e.g. https://anglo-norman.net/entry/descendre) and wrote a script that will automatically add missing ‘n’ attributes to all locution main senses in the system. I haven’t run this on the live database yet as I need further feedback from the editors before I do. As the week drew to a close I worked on a method to hide sense numbers in the front-end in case where there was only one sense in a part of speech, but I didn’t manage to get this completed and will continue with it next week.
It was a return to a full five-day week this week, after taking some days off to cover the Easter school holidays for the previous two weeks. The biggest task I tackled this week was to import the data from the Dictionary of the Scots Language’s new editing system into my online system. I’d received a sample of the data from the company responsible for the new editing system a couple of weeks ago, and we had agreed on a slightly updated structure after that. Last week I was sent the full dataset and I spent some time working with it this week. I set up a local version of the online system on my PC and tweaked the existing scripts I’d previously written to import the XML dataset generated by the old editing system. Thankfully the new XML was not massively different in structure to the old set, and different mostly in the addition of a few new attributes, such as ‘oldid’ that referenced to old ID of each entry, and ‘typeA’ and ‘typeB’, which contain numerical codes that denote which text should be displayed to note when the entry was published. With changes made to the database to store these attributers and updates to the import script to process them I was ready to go, and all 80,432 DOST and SND entries were successfully imported, including extracting all forms and URLs for use in the system.
I had a conversation with the DSL team about whether my ‘browse order’ would still be required, as the entries now appear to be ordered nicely by their new IDs. Previously I ran a script to generate the dictionary order based on the alphanumeric characters in the headword and the ‘posnum’ that I generated based on the classification of parts of speech taken from a document written by Thomas Widmann when he worked for the DSL (e.g. all POS beginning ‘n.’ have a ‘posnum’ of 1, all POS beginning ‘ppl. adj.’ have a ‘posnum’ of 8). Although the new data is now nicely ordered by the new ID field I wanted to check whether I should still be generating and using my browse order columns or whether I should just order things by ID. I suggested that going forward it will not be possible to use the ID field as browse order, as whenever the editors add a new entry its ID will position it in the wrong place (unless the ID field is not static and is regenerated whenever a new entry is added). My assumption was correct and we agreed to continue using my generated browse order.
In a related matter my script extracts the headword of each entry from the XML and this is used in my system and also to generate the browse order. The headword is always taken to be the first <f> of type “form” within <meta> in the <entry>. However, I noticed that there are five entries that have no <f> of type “form” and are therefore missing a headword, and are appearing first in the ‘browseorder’ because of this. This is something that still needs to be addressed.
In our conversations, Ann Ferguson mentioned that my browse system wasn’t always getting the correct order where there were multiple identical headwords all within the same generate part of speech. For example there are multiple noun ‘point’ entries in DOST – n. 1, n. 2 and n. 3. These were appearing in the ‘browse’ feature with n. 3 first. This is because (as per Thomas’s document) all entries with a POS starting with ‘n.’ are given a ‘posorder’ of 1. In cases such as ‘point’ where the headword is the same and there are several entries with a POS beginning ‘n.’ the order is then set to depend on the ID, and ‘Point n.3’ has the lowest ID, so appears first. I therefore updated the script that generates the browse order so that in such cases entries are ordered alphabetically by POS instead.
I also regenerated the data for the Solr full-text search, but I’ll need Arts IT Support to update this, and they haven’t got back to me yet. I then migrated all of the new data to the online server and also created a table for the ‘about’ text that will get displayed based on the ‘typeA’ and ‘tyepB’ number in the entry. I then created a new version of the API that uses the new data and pulls in the necessary ‘about’ data. When I did this I noticed that some slugs (the identifier that will be used to reference an entry in a URL) are still coming out as old IDs because this is what is found in the <url> elements. So for example the entry ‘snd00087693’ had the slug ‘snds165’. After discussion we agreed that in such cases the slug should be the new ID, and I tweaked the import script and regenerated the data to make this the case. I then updated one of our test front-ends to use the new API, updating the XSLT to ensure that the <meta> tag that now appears in the XML is not displayed and updating bibliographical references and cross references to use the new ‘refid’ attribute. I also set up the entry page to display the ‘about’ text, although the actual placement and formatting of this text still needs to be decided upon. I then moved on to the bibliographical data, but this is going to take a bit longer to sort out, as previous bib info was imported from a CSV.
Also this week I read through and gave feedback on a data management plan for a proposal Marc Alexander in involved with and created a new version of the DMP for the new metaphor proposal that Wendy Anderson is involved with. I also gave some advice to Gerry Carruthers about hosting some journal issues at Glasgow.
For the Books and Borrowing project I made some updates to the data of the 18th Century Borrowers pilot project, including fixing some issues with special characters, updating information relating to a few books and merging a couple of book records. I also continued to upload the page images of the Edinburgh registers, finishing the upload of 16 registers and then generating the page records for all of the pages in the content management system. I then started on the St Andrews registers.
I also participated in a Zoom call about GIS for the place-names of Iona project, where we discussed the sort of data and maps that would appear in the QGIS system and how this would relate to the online CMS, and also tweaked the Call of Papers page of the website.
Finally, I continued to make updates to the content management systems for the Comparative Kingship project, adding in Irish versions of the classifications and some of the labels, changing some parishes, adding in the languages that are needed for the Irish system and removing the unnecessary place-names that were imported from the GB1900 dataset. These are things like ‘F.P.’ for ‘footpath’. A total of 2,276 names, with their parish references, historical forms and links to the OS source were deleted by a little script I wrote for the purpose. I think I’m up to date with this project for the moment, so next week I intend to continue with the DSL bibliographical data import and to return to working on the Anglo-Norman Dictionary.
I’d taken Monday and Thursday off this week to cover some of the school Easter holidays, and I also lost some of Friday as I’d arranged to travel through to the University to pick up some equipment that had been ordered for me. So I probably only had about two and a half days of actual work this week, which I mostly spent continuing to develop the content management systems for the new Comparative Kingship place-names project. I created user accounts to enable members of the project team to access the Scottish CMS that I completed last week, and completed work on the 10,000 or so place-names I’d imported from the GB1900 data, setting up a ‘source’ for the map used by this project (OS 6 inch 2nd edition), generating a historical form for each of the names and associating each historical form with the source. This will mean that the team will be able to make changes to the head names and still have a record of the form that appeared in the GB1900 data.
I then began work on the Irish CMS, which required a number of changes to be made. This included importing more than 200 parishes across several counties from a spreadsheet, updating the fields previously marked as Scottish Gaelic to Irish and generating new fields for recording ‘Townland’ in English and Irish. ‘Townland’ also had to be added to the classification codes and a further multi-select option similar to parish needed to be added for ‘Barony’. OS map names ‘Landranger’ and ‘Explorer’ needed to be changed too, in both the main place-name record and in the sources.
The biggest change, however, was to the location system as Ireland has a different grid reference system to the UK. A feature of my CMS is that latitude, longitude and altitude are generated automatically from a supplied grid reference, and in order to retain this functionality for the Irish CMS I needed to figure out a method of working with Irish grid references. In addition, the project team also wanted to store another location coordinate system, the Irish Transverse Mercator (ITM) system, and wanted not only this to be automatically generated from the grid reference, but to be able to supply the ITM field and have all other location fields (including the grid reference) populate automatically. This required some research to see if there was a tool or online service that I could incorporate into my system.
I also continued to work on the Books and Borrowing project this week. I’d been in discussion with the Stirling University IT people about setting up a IIIF server for the project, and I heard this week that they have agreed to this, which is really great news. Previously in order to allow page images to be zoomed and panned like a Google Map we had to generate and store tilesets of each page image at each zoom level. It was taking hours to generate the tilesets for each book and days to upload the images to the server, and was requiring a phenomenal amount of storage space on the server. For example, the tilesets for one of the Edinburgh volumes consisted of around 600,000 files and took up around 14GB of space. This was in addition to the actual full-size images of the pages (about 250 at around 12MB each).
An IIIF server means we only need to store the full-size images of each page and the server dynamically chops up and serves sections of the image at the desired zoom level whenever anyone uses the zoom and pan image viewer. It’s a much more efficient system. However, it does mean I needed to update the ‘Page image’ page of the CMS to use the IIIF server, and it took a little time to get this working. I’d decided to use the OpenLayers library to access the images, as this is what I’d previously been using for the image tilesets, and it has the ability to work with a IIIF server (see https://openlayers.org/en/latest/examples/iiif.html). However, it did take some time to get this working, as the example and all of the documentation is fully dependent on the node.js environment, even though the library itself really doesn’t need to be. I didn’t want to convert my CMS to using node.js and have yet another library to maintain when all I needed was a simple image viewer, so I head to rework the code example linked to above to strip out all of the node dependencies, module syntax and import statements. For example ‘var options = new IIIFInfo(imageInfo).getTileSourceOptions()’ needed to be changed to ‘var options = new ol.format.IIIFInfo(imageInfo).getTileSourceOptions()’. As none of this is documented anywhere on the OpenLayers website it took some time to get right, but I got there in the end and the CMS now has an OpenLayers based IIIF image viewer working successfully.
This week began with Easter Monday, which was a holiday. I’d also taken Tuesday and Thursday off to cover some of the Easter school holidays so it was a two-day working week for me. I spent some of this time continuing to download and process images of library register books for the Books and Borrowing project, including 14 from St Andrews and several further books from Edinburgh. I was also in communication with one of the people responsible for the Dictionary of the Scots Language’s new editor interface regarding the export of new data from this interface and importing it into the DSL’s website. I was sent a ZIP file containing a sample of the data for SND and DOST, plus a sample of the bibliographical data, with some information on the structure of the files and some points for discussion.
I looked through all of the files and considered how I might be able to incorporate the data into the systems that I created for the DSL’s website. I should be able to run the new dictionary XML files through my upload script with only a few minor modifications required. It’s also really great that the bibliographies and cross references are getting sorted via the new Editor interface. One point of discussion is that the new editor interface has generated new IDs for the entries, and the old IDs are not included. I reckoned that it would be good if the old IDs were included in the XML as well, just in case we ever need to match up the current data with older datasets. I did notice that the old IDs already appeared to be included in the <url> fields, but after discussion we decided that it would be safer to include them as an attribute of the <entry> tag, e.g. <entry oldid=”snd848”> or something like that, which is what will happen when I receive the full dataset.
There are also new labels for entries, stating when and how the entry was prepared. The actual labels are stored in a spreadsheet and a numerical ID appears in the XML to reference a row in the spreadsheet. This method of dealing with labels seems fine with me – I can update my system to use the labels from the spreadsheet and display the relevant labels depending on the numerical codes in the entry XML. I reckon it’s probably better to not store the actual labels in the XML as this saves space and makes it easier to change the label text, if required, as it’s only then stored in a single place.
The bibliographies are looking good in the sample data, but I pointed out that it might be handy to have a reference of the old bibliographical IDs in the XML, if that’s possible. There were also spurious xmlns=”” attributes in the new XML, but these shouldn’t pose any problems and I said that it’s ok to leave them in. Once I receive the full dataset with some tweaks (e.g. the inclusion of old IDs) then I will do some further work on this.
I spent most of the rest of my available time working on the new Comparative Kingship place-names systems. I completed work on the Scotland CMS, including adding in the required parishes and former parishes. This means my place-name system has now been fully modernised and uses the Bootstrap framework throughout, which looks a lot better and works more effectively on all screen dimensions.
I also imported the data from GB1900 for the relevant parishes. There are more than 10,000 names, although a lot of these could be trimmed out – lots of ‘F.P.’ for footpath etc. It’s likely that the parishes listed are rather broader than the study will be. All the names in and around St Andrews are in there, for example. In order to generate altitude for each of the names imported from GB1900 I had to run a script I’d written that passes the latitude and longitude for each name in turn to Google Maps, which then returns elevation data. I had to limit the frequency of submissions to one every few seconds otherwise Google blocks access, so it took rather a long time for the altitudes of more than 10,000 names to be gathered, but the process completed successfully.
Also this week I dealt with an issue with the SCOTS corpus, which had broken (the database had gone offline) and helped Raymond at Arts IT Support to investigate why the Anglo-Norman Dictionary server had been blocking uploads to the dictionary management system when thousands of files were added to the upload form. It turns out that while the Glasgow IP address range was added into the whitelist the VPN’s IP address range wasn’t, which is why uploads were being blocked.
Next week I’m also taking a couple of days off to cover the Easter School holidays, and will no doubt continue with the DSL and Comparative Kingship projects then.