HCMC Blogs

The regular editing grind on an Issue 7 article.

Met with CC, SA and some folks from the library to discuss a possible grant application, details of which will be fleshed out in due course. Did some research first and follow-up afterwards; meeting on Friday by which time I need to have a basic list of bullet-points to discuss.

On late duty, and later than planned, but longer lunch than usual.

I've got the whole tree we worked out on the whiteboard converted to an ODD file, with some changes to keep element names unique and rationalize some things; I have new data types of various kinds, and I have a test file which is working well. The process of looking at the real data has raised a number of very complicated issues -- it turns out that partial lots can be included in titles, and titles can combine lots and partial lots from disparate blocks; e.g. title id 203 from the existing database contains 8 lots and one partial lot, from four distinct blocks. Combine this with a variety of semi-documented ownership splits and you have such a potential source of inaccuracy and confusion that a very clear policy on handling this sort of thing must be established in advance.

One outstanding issue for my ODD: should I combine all my customizations into their own distinct module? I think probably yes, but our documentation says nothing about this. When I've done with this ODD file, I'll use it as an example for the "Getting started with P5 ODDs" document I'm supposed to be working on, and I think it should also be built into TEIP5-Test as a validation test (today it uncovered a problem with handling of multiple constraints in a constraintSpec which took some sorting out across the two Jinks boxes).

Leaving early.

The ODD file is coming along slowly. I hit a bug in the current ODD schema, and another in the Jenkins build, and fixed the latter to get a stable schema I could validate my ODD file against.

Very productive meeting with RRR and DBM on expectations and plans for the GIS cluster. The basic outcome is that we need to start by defining the exact boundaries of the areas we're focusing on (JSR should do that); then they will contact the UBC library to find out exactly which fire insurance maps are available and how accessible they are (digitized or not?), and enumerate other resources. The basic plan is to start with a modern streetmap as a base layer, then create polygons which are linked to a database of properties and a separate database of addresses; these would most likely be set up by us, and populated (at least initially) from the Properties db info we have, then supplemented with info from the city directories. The objective is to have a polygon for every incarnation of every property during the period in question, linked to any addresses and property descriptions it may have had. Properties are then linked to titles and owners, etc., as covered by our other developing plans (the XML schema among other things).

We could use single-word font names:
avenir
baskerville
benguiat
bodoni
caslon
clarendon
courier
didot
franklin
frutiger
futura
garamond
georgia
goudy
helvetica
lucida
museo
myriad
optima
palatino
perpetua
rockwell
warnock

Or names from books:
tintin
emma
toad
lyra
fagin
portnoy
paddington

Or, more specifically, literary detectives:
poirot
sherlock
marlowe
spade
dalgleish
morse
rumpole
peel
smilla
marple
salander
cadfael
gideon

Worked late yesterday -- forgot to record it.

There were none; I've added a default set to all major pages. After the final publish before freezing, we'll see if these have any effect on the search engine rankings for the site, which are not high at the moment.