HCMC Blogs

This is handy when you're checking whether your XSLT handles all the elements your documents happen to use:

distinct-values(//*/descendant-or-self::*/name(.))

Net over this week Monday to Thursday.

Met with Simon again to go over further questions on data structuring for Bailey database. We will make the execution, respite and pardon fields pointers to tables to accommodate the complexities of each of those three fields of data. Simon will provide me lists of the possible values for each of the fields in each of the tables.

We also worked out how to integrate trials in which the sentence/charge is respited (reconsidered by the review panel) and to distinguish those from trials in which the punishment (as recommended by the trial judge) is respited.

Considering how two structure the trial records - may go with fields like "finding of trial judge", "modification by panel", "outcome". In most cases, the outcome will be identical to either the finding of the trial judge or the final modification of the panel. Now I'm not sure if multiple entries in the current respite and pardon fields reflect behaviour of the trial judge or the panel - will have to ask Simon.

Started working through the basic structure of the XHTML output. The headings (APA stuff) were a bit tricky, but I've figured it out; headings are always h2 down to h6 in XHTML tag terms, but they also get a class attribute which is based on the level they're at and the number of levels, so we can style them appropriately. Lists, tables and quotes are handled, as are names and abbreviations. There are still titles, figures, graphics, notes, mentioned/soCalled/term etc., and the dreaded bibliography to do. There's also the wrinkle that appendices may have nested headings, and those headings are styled based on THEIR nesting level, not the levels in the main text. However, I think it's reasonable to assume no more than three levels in appendix headers, so we can avoid a lot of calculation that way.

The project wishes to solicit suggestions on additional records to add to the database from the public through the website. Given the likely numbers of suggestions, we think a relatively simple, low-tech implementation would be best. If demand justifies, we will can look at a more automated procedure in the future. The web-site would offer a form of some kind for the person to provide details on the suggested addition. The amount of detail required is still to be settled. The editor of the site would then take that suggestion, verify the information and create a record in an appropriate structure for the database. The record would then be added to the database. Details on the exact tools to create the record and upload it to the database are still to be settled. Only the editor would have write access to the database, the person originally suggesting the addition would have no effect on the database. This system is simple but entails a relatively large amount of manual labour per suggestion. On the other hand, because it is simple it requires relatively little coding and devlopment work to create the infrastructure for handling queries. This approach is sensible assuming the number of suggestions is low (in the hundreds). The project itself will be finding material to add to the database and will need a method for doing that. Whatever we settle on for this kind of work will almost certainly be what is used to enter suggestions from third parties.

Dr John Price in History wishes to create an Asian-Canadian bibliographic database. I met with Darby Cameron to discuss the possibilities. It currently contains hundreds of records and ultimately will contain ten thousand. The database will contain references to a wide range of sources - traditional books, articles etc., audio and video recordings and possibly material in internet resources (blogs, websites, etc.). The Canadian Labour History bibliography http://www.library.mun.ca/qeii/labour/index.php is to be used as a model for the front-end query and reporting. That implementation has the following features: Search: - Search for: text1 AND/OR/NOT text2 AND/OR/NOT text3 AND/OR/NOT text4 - Filter by: type of info (all, author, title, subject, journal) for each of the text fields - Filter by: language - Filter by: type of document (book, article, chapter, thesis, other) - Filter by: year of publication Report: - title - author - publication details - year of publication - full details (hide-show): document type, subject term(s) The user interface (front-end) we settle on is independent of whichever infrastructure (back-end) is used. The specifics of the interface for queries and reports still needs to be settled and will depend on the important characteristics of our data set (e.g. the four regions and the three types of record (history, literature, multimedia)). I expect we will be able to produce a wider range of output reports than the Labour History Bibliography does (for example: optimized for printing vs on-screen display vs export, styled according to a style standard etc.). Based on the research I've done since the meeting, the infrastructure used by the Canadian Labour History bibliography appears to be a component of a very large relational database system used to run the entire library. The alternative to a relational database (rows and columns of data in tables) is an XML database (trees of data). Based on the relatively small number of documents and the relatively wide range of types of documents in the dataset, it appears that the XML-based option might be preferable on the grounds that: 1) it may be less work to structure the data and create the appropriate queries using an XML rather than a purely relational approach 2) the XML structure will allow for more sophisticated queries should we wish to run them in addition to the queries currently envisioned. If we decide to store the data in XML, we'll likely use the MODS standard for structuring the data, which is designed for exactly this kind of thing http://www.loc.gov/standards/mods/ and see the list of sample documents linked from that page. The structured data would then go into an eXist XML database, and the website would communicate with that database to send queries in and receive reports back. The HCMC has done similar work (publishing xml-based journals including extensive bibliographies) so would be interested in seeing how closely that kind of work ties in to this present project. In addition, we believe this work could be use to support other scholars assembling specialist bibliographies. Action Items: We (the HCMC) will look at the data and consider the best database system to use and how to structure the data based on the nature of your data. You need to consider who your audiences are and the various kinds of queries they will be making of the data (That is, what questions can people ask of the database, and what questions can they not ask. For example, you may want to allow to people search by "subject term" such as 'China--Social conditions--1976-2000', but not to search for who the publisher is, and so on.) When you've assembled that list, please forward it on to me, as that will help us make the final decision about which database system to use and how to structure the data. If you are using things like keywords, subject-terms etc. you'll need to prepare a list of those and forward that to us too.

We have a slightly interesting dilemma which is the result of some oddities in the APA style. Articles may have multiple levels of header in them, if they're divided into sections (both the articles I've worked on so far have two levels of header). APA, rather strangely, chooses to style headers based on the number of levels that happen to be present in the article; so, for example, where there are two or three levels, the second level is aligned left, but where there are four levels, the second level is centred, and the third level is left-aligned instead. For full details, see the APA Style Guide section 3.32.

Quite frankly, I think this is astoundingly silly, and so does everyone else I've shown it to. it means that the second level heading in one article may well be styled differently from the second level heading in another article. When we get to five levels, it gets even sillier; an ugly all-caps header is inserted at the top level, pushing all the other levels down, and making that particular article look radically different from others which use fewer levels of heading.

I've never really worked seriously with APA before, so this is new to me. Chicago and MLA seem to have nothing to say about it, other than Chicago's pragmatic assertion that levels of heading are "differentiated by type style and placement" (1.74). It makes for an interesting problem for XSLT and CSS, to say the least!