ALEG

What I've done

• ALEG Partner Meeting on Tuesday, which was very positive and professional, and recharged the batteries! It was good to catch up with the partners I'd met in Hobart and meet Cate and Wenche from Deakin.

• Spent half a day with Cate and Kerry discussing the multicultural writers database. This is a great resource, with lots of bio information and information about editions. Unfortunately, the edition information is next to impossible to interpret programmatically, but Cate and Kerry talked about how some reformatting could take place to make the data ambiguous to a dumb computer program.

• Spent about a day with Kerry and Sally (in person and on the phone) discussing the reformatting of the BAL and LAW databases to make the data load easier/more accurate.

• Discussed prototype query results with many people, made some minor formatting changes pending bigger decisions on what will be shown on short and detailed views, what the query interface will look like, how results will be sorted, other delivery options (email?), ...

• Started to work again on the data maintenance infrastructure and Agent maintenance prototype. This is a critical part of the system, and it is very important that it is done the best way possible to allow for future changes, ease of use and speed, even if development takes a bit longer.

  I've already implemented one option, got it working and abandoned it (if you have IE5+, you'll be able to see the smoking hulk at here (RACV Milne, fiddled with new notes) or here (Kit Denton). None of the buttons do anything - it is completely static. This version uses an XSL Stylesheet in the server to transform a topic (here, an agent) using a "schema" which describes what the topic looks like into an HTML form. The form is sent to the browser to render.

  The alternative I've roughly coded sends the topic as an XML object to the browser, which reads the "schema" and generates the HTML form in the browser. It doesn't use XSL to do this (but it could), instead using the Document Object Model (DOM). Why do this in the browser? Because the code running in the browser has to have a lot of code to understand the schema anyway; to edit the input, dynamically allow elements and groups of elements to be added and deleted and a create the updated topic for shipping back to the server. Maybe we can make things simplier by not having code on the server that does any part of this - leave it all to the client.

  The idea is that changes in the data model (at least slight ones, such as adding new attributes and events and changing editting rules) will require no or minimal programming, being maintainable by the ALEG data administrator. A schema definition represented in an XML file "drives" the whole process. (This approach worked well on a previous system implemented for CSIRO-Online - that design performed the transformation into the HTML form on the server and dynamic editing on the client, but this attempt is much generalised and more ambitious having to deal with much more complex data structures and relationships!)

  Hopefully, something useful will be going this week...

• Document how ALEG will handle some tricky cases - The "Poets of the Month" works from the mid 1970's and "Down the Lake with Half a Chook". These are amongst the most "difficult" cases Tessa and Kathy can come up with, so if we think the proposed data model can handle these, we'll be happy!

• Continue on the data maintenance (input) suite - develop prototype agent maintenance screens.

• Continue discussions on user interface presentation options, sort orders, long -v- brief displays

• The more we look at data conversion, the more issues arise. These aren't due to specifics such as FRBR or technology, but just the problems of converting text databases designed for printing, browsing and human interpretation into a highly structured and linked database. Work on the data maintenance suite is progressing well.