AustLit

Marie-Louise's last week as AustLit Project Manager

The AustLit Project is testament to the vision, leadership and intellect of Marie-Louise Ayres.

Although many people around Australia have given their heart and soul to this project, no one deserves more recognition for what has been achieved individually and collectively than Marie-Louise. Her insight, dedication, pragmatism and decisiveness executed within a framework of humour, honesty, respect, cooperation and trust made this project fulfilling and a pleasure for all involved and the outcome something with which we can all be justly happy.

Her own high standards inspired us all.

The consequence of the change from the excitement and frenzied activity of the development phase of the project to a running production system with dozens of paying customers with high expectations are often misunderstood and underestimated.

But I'm sure that with Kerry Kilner as the new Project Manager and the continuing goodwill and enthusiasm of the AustLit partners, the gateway has a wonderful future.

What I've done

• Meetings with Marie-Louise, Kerry and Annette about development priorities.

• Started design for work to add "scope" information to relationships.

  Background: AustLit represents data as topics and links between them as relationships. Nearly everything is a topic, even things which you might not think of as warranting the status of a topic, such as a date, a biographical note, or any note at all! A relationship consists of two topics and a relationship-type. For example, "Agent XYZ" (topic 1) "hasBiography" (relationship type) "blah blah blah" (topic 2). Relationships actually have 2 other attributes - a sequence number for ordering relationships of the same relationship-type, and an "uncertain" flag.

  Many topics (such as agents and works) are nothing other than their relationships - they have no data "of their own". Other topics, such as dates and biographies do have data, such as a year or a string of text.

  Now, we've been noticing a need to use more metadata than a simple uncertain flag to describe a relationship. Specifically, we've seen the need to annotate relationships with a note. For example, you might want to describe in detail something about someone's heritage - you could currently record this note at the agent level, but it would be mixed in with other notes at the agent level; far more sensible to annote that agent - heritage relationship with the note than the agent. Another example: an award can be a subject of a work - that is, a work could discuss the Miles Franklin award (where the Miles Franklin award is a topic). But what if it wants to discuss the 1998 Miles Franklin Award? It would be nice to scope the relationship between the work and the award with a date topic.

  Well, all we are really doing here is making the relationship addressable, also known as making the relationship a "first-class-object" in some jargon, or "reifying it" in other jargon. That is, just as you can make associations between topics, you can make associations between associations and topics.

  The database and object structures in AustLit are very easily modified to support this. However, the bit I'm struggling with is how to represent scopes in the XML representation, which is used to drive the stylesheets and importantly, drive the maintenance user interface! The problem is that the XML representation of a simple relationship is currently as follows:

  <gender seq="0" tid="z#" topicType="z" typeCode="P1" uncertain="n">Female</gender> Now, imagine we were to allow gender to be scoped. We'd have something like this: <gender seq="0" tid="z#" topicType="z" typeCode="P1" uncertain="n"> Female <scope tid="s1"> <hasDate seq="0" tid="VQX" topicType="V" typeCode="V" uncertain="n"> <date startYear="1962" endYear="1992" tid="VQX">1962-1992</date> </hasDate> <hasNote seq="1" tid="Tx" topicType = "T" uncertain="n"> Had sex change operation whilst visiting Peru in 1962, reversed in London in 1992. </hasNote> </scope> </gender> This is a bit yucky because previously the content of the "gender" element was the string: "Female" - very easy to find/use in a stylesheet. Now the content of "gender" is some text ("Female") and the "scope" element, so printing out the gender is a bit harder, and the scope has to be dealt with (selectively displayed by formatting (in this case) the date and note). So called "Mixed content" (where the direct children of an XML element are both text and markup) is difficult to process efficiently. And it is especially difficult because our text may in fact contain legitimate HTML style markup in many cases. Putting the text in a special "text" sub-element is one way, but it seems overkill when the percentage of scoped relationships will be very very low.

  In the maintenance suite, these nested scope attributes have to be displayable, updatable, deletable, which has big consequences in both the browser code and the server code which gets the updates.

• Added NLA Amicus number as a work attribute. Changed the NLA Holdings lookup to use Amicus number rather than name/title if a work has one or more Amicus numbers. For periodical issues, use the parent periodical's Amicus numbers if they have been recorded.

• Changed maintainer's search logic to use the general search engine used by simple/guided/advanced searches. The "old" search engine was just hanging around from the early days, and has now been retired.

• Rejigged work detail display to remove separation between "Review" and "Criticisms" of a work. The problem here was that any work having the shown work as a "work-as-subject" was being called a criticism in this list (although it may have had a type of column or biography). The more neutral term "Works About" is now used to describe reviews and works having the work-as-subject.

• Misc minor changes to stylesheets and other formatting following maintainer and user feedback (add periodical issue period to maintainer search; added updateSummaryList to XML extract to show who has updated/maintained a record; a few template changes; removed double quotes from titles passed to Kinetica for holdings lookup; electronic media removed as a form type)

• Produced usage stats for Kerry.

• All works with just a single worktype being "single work" and just a single form being "extract" have been changed to have a work type of "extract" and the form type "extract" has been deleted.

• The system was stable.

Next Week

• Continue design/implementation of relationship scopes. The first use for this facility will be year-scoping of award-as-subject relationships.

• Move awards to be event-based rather than work-based.

• Design/implement "public view" processing.

• Multiple creation events for a work as a mechanism for allowing date ranges to be associated with agents responsible for works, eg editors of a periodical.

• Refining NBD Holdings searches.

• Review all subset definitions for efficacy.

• Import/export in MARC and DC formats.

• SDI facility.

• Combining searches

• System Documentation