HCMC Blogs

Rewrote some parts of the markup documentation to include our decisions about attested vs unattested transcriptions, locations of <bibl> elements, and other issues.

Met with AW to discuss the early stages of a project to digitize a set of aboriginal language texts.

• As a simple introduction to XML/TEI, I suggested working on the personography (which will include researchers, informants, authors etc.). For this purpose, I'll generate a schema, and create a couple of sample entries in a file. I'll send that to him, and he can get to work with oXygen.
• There are several languages, each with several dialects; each will need an ISO code. AW is more conversant with the ISO 639, having just been involved in an application to split a language code into two, so he's best placed to handle this.
• The project members will coordinate to ensure that they have a finalized list of the orthographical features used in the transcription, and the Unicode codepoints appropriate for them.
• AW will create an inventory of document types, so that we can figure out which modules the eventual schema will require, and a list of the important features that need to be encoded. For instance, there are some documents which will be transcriptions from old printed books; some aspects of the original rendering will need to be preserved, and others will be discarded.
• The project team will think about the range of eventual output formats they want to produce (HTML/website, print editions of texts, dictionaries, wordlists, etc.).
• Another key feature will be an inventory of the root morphemes, along with a list of their allomorphs. Because of the regularity of the languages, and the fact that the key morpheme usually occurs word-initially, we should be able to delegate the markup (or highlighting, or linking) of the word-initial morphemes to the web application itself, based on the morpheme inventory.
• There is a significant amount of data already in Shoebox/Toolbox format. This needs to be converted to TEI. I will investigate tools and procedures for doing this, and report back.
• Over the next few weeks, we'll collaborate on a project profile which Stew can take to the HCMC committee for approval.
• We're aiming for a SSHRC grant application in the fall.

Takeaways for me: the personography schema, and the Toolbox-to-TEI research.

Logging time spent on search committee work.

Created a simple one-table db for the GRS Journal list, which they'd like to have available as a page on their website; that's best achieved using RSS feeds and the code already available on GRS for parsing them. The db and the editing interface is done (based on the Adaptive DB code). They may be able to provide a workstudy student to enter the data (which is currently a Word document, and only partial). If the data entry gets done, I'll write the RSS output, and we'll also have to create some kind of page-scraping system which runs through crontab to check the library listings for any new issues; that's slightly complicated, but interesting and useful elsewhere, so worth doing.

I have a buggy details search going now, but no time to finish it.
The file I'm working on is test_search.php and it should have enough pointers in it to get me going when I get back.
I'm part way through characters and places, and although the php generates functional sql (I can copy/paste the sql in to phpmyadmin and it runs) I get garbage echo'd to html.
I'm on the right track, though.

Working all day on the Siberian project -- needed to get to a point where I could hand off to SA because I'll be busy tomorrow. Then started trying to fix a bug on Coldesp which I can't figure out at all.

KSW discovered a very odd piece of behaviour on the site. When you go directly to a document with an abstract, the abstract appears as normal. If you go to the same document with a search string in the URL (as you would if it were the result of a search), then the abstract does not appear. I've been working on this for an hour, and I can't figure it out. So far, I know:

• The problem appears to be in the XQuery which generates the XML.
• That code branches depending on whether there's a search string or not. If there's a search string, it constructs a new document based on the old document, but including the search results and search data.
• The function which constructs the document appears to be correctly inserting the <notesStmt> component of the <teiHeader>, but it's failing to do so. It's successfully inserting other components of <fileDesc>, which is very odd indeed.
• One possibility is the Java library I wrote which creates the XQuery search code based on the input search string. I'll have to look at that. However, it seems unlikely that the search string could modify the actual components of the file which are returned. This is a really puzzling one.

Dr. Iles came in for a bit of an overview on operating the VC equipment. I've also documented the process, and he's declared himself satisfied with it. The only potential fly in the ointment (come VC day) will be the network.

I now have a very basic search page that will allow you to do a count on search terms.
Running a search will only produce a count of how many characters, places and so forth are in the DB.

I can't decide whether I should leave it at that or try to make something that returns actual values.
If not, I need to adjust the SQL in search.php to check for different GET values and run either a COUNT or a regular query.

Argument for keeping this page a count only is that some results are not immediately plotable on a map, and I should only allow maps where there are locations involved. Therefore, when users click on a link (like "3 locations") they'll get a map.

I can see that this might get messy, though, so I need to think about this a bit before barging in to the code.