Update of Humanities Sites

Met with Martin and three people from PAAS to finalize proposed site plan. Made modifications and circulated to all and to JS at communications.

Turns out that the GRS site proposal hasn't got past JS, which she and Judy try to schedule a meeting. I proposed a day and time which worked out. We got input from JS, and submitted an updated proposal after getting OK from BB. JS is expediting the provisioning of the site in advance of cascade training session next week, and we expect to hear back from information architects at about the same time.

Heard back from JS that our site plan was approved and we have had an account provisioned. Assigned Judy and Greg to work together (Judy's worked on one more-complex site already, and Greg wants to learn the ropes of how the environment works) to structure and populate the site.

With advice from BLT on what was intended, I've fixed the secondaryNavbar.php code in the student subfolder. I think the style of the section headers could be revisited, and customized, so they don't look selected, but the page is valid and everything works.

The previous bugs in aboutus/secondaryNavbar.php had re-introduced themselves, so I fixed them again. Then I realized that another secondaryNavbar.php page in the studehnt subfolder has similar bugs, so I started looking at it. The left-side menu looks like it was supposed to be designed to expand and contract, so initially you would see only:

For all students
For undergraduates
For graduates

then when you clicked on one of those, it would expand and show the contents below it. But it doesn't work like that; all the contents are expanded all the time.

The code looks as though it was once written to expand and contract, but it's completely broken; it has <li> elements embedded directly inside <li> elements, multiple class attributes on the same element, and all sorts of confusion. I don't yet know how to go about fixing it, because I don't know what it originally looked like. I found an old backup of Stewart's, but it's structured completely differently; instead of secondaryNavbar.php, it uses section_left_nav.inc, which looks somewhat similar, but was only ever intended to be static. I'm waiting for some feedback from BLT, in case he can remember what the original intention was, and when the changes were made.

I've now implemented the plans described in this previous post, as follows:

• The rssReaderManyDepts.php file has been modified in a couple of places, to add an optional parameter (default value "true") called $includeDesc, which is used to control whether or not the Description field is included when the full event detail is written out. This doesn't change any other behaviour elsewhere on the site, but enables me to suppress the description information when I need to.
• A new page (aboutus/eventsWeek.php) has been created. This instantiates a special instance of the rssReader class, which is set to retrieve events for only 8 days. This class then writes out the events twice, once in short form (for copy-pasting into the email) and once in long form (so that the speaker information can be retrieved and copy-pasted into the email too, where appropriate).
• The new page does not include the normal right-column listings, because its special version of the RSS reader wouldn't be able to provide them, since it's only retrieving 8 days of material. However, this is not a page intended for the public anyway, so it doesn't really matter whether it's complete or not.
• This special reader uses its own cache file, so as not to step on the toes of the other two instances of readers used on the site.

I've emailed BLT to let him know about the new page.

Preparing to write the new Events feed page requested by BLT, I first set about fixing a bunch of errors in the existing code:

• The RSS reader class (includes/rssReaderManyDepts.php) function writeOutTitle() did not echo open <li> and close </li> tags around its content, although it is called in the context of a <ul> tag. Added the appropriate tags, and also commented out <br/> tags which were being used to space the content.
• The RSS reader class (includes/rssReaderManyDepts.php) function writeOutEvent() echoed out two <br/>s and an <hr/> after closing the <li> tag; this obviously was invalid, so I've moved them inside the <li> tag.
• <includes/rightColumn.inc> had two elements with the same id attribute (rightCol_1). I changed the second to rightCol_1a.
• <includes/rightColumn.inc> had an unclosed <ul> (in rightCol_2). That's now closed.

Pages now validate, so I can move on to the new events output page.

Details of a request from BLT to an enhancement to the RSS feed reader on the Humanities faculty site:

• We need to create a page which shows only one week's events.
• This should be done by added a custom output format to the current RSS feed reader code. There are already two or three output routines; this would just be another, for this specific purpose.
• The output from this routine would provide two lists of the events for the coming week:
  1. The first should be identical to the current output, except that it should not include the description field. BLT will copy-paste this into an email he sends out to the faculty.
  2. The second would be the same, except that it would include the description field; this would enable BLT to extract the speaker information from it manually (there is no speaker field in the events calendar, so this always has to be extracted manually).
• A page showing this output will be added to the Hums site, but not linked from anywhere. The URL will be known to BLT, who will use it to generate his weekly emails. It wouldn't matter if anyone else stumbled upon this page, because it's just another list of events from the calendar.
• While writing this, we should also take the opportunity to fix a bug in the current output from the reader, as it appears in all pages -- see this validator output. The bug is caused by the use of a <ul> element with children which are <p>s instead of <li>s.

I'll get to work on this in the week of the 18th.

BT contacted me asking about a feature of the Hums site which SA had proposed and possibly implemented that would provide a short-form view of the events calendar events, suitable for copy/pasting into a weekly email. I poked around on the site, and I found that the RSS reader object is based on some code I adapted years ago for the GRS site, so I've seen it before, but it's been modified considerably to handle the multiple calendar sources. The reader has a "shortForm" parameter that causes it to spit out the events in a shorter form. That can't be set externally, unfortunately -- it's private and there's no setter function -- so as a quick workaround I created a new page called eventsSimple.php which re-creates the reader with the shortForm parameter set to true in the constructor.

The resulting output for each event consists only of a date and a title, which is linked to something that doesn't work. Obviously we'll have to tweak it, so I'm waiting for details from BT about what he'd like to see in the list, and then I'll make some modifications to the reader to make the short form output more useful, testing everything in the :8080 first.

I'm beginning to work out the structure for the tables in the database for the Victorian Poetry database.

The primary unit in this database appears to be a published-poem.
Each published-poem has a relationship to a poem and to a periodical. Each poem has a relationship to an author.

There are some questions that I need MT to answer before I can continue.

1) Will there be any instances of a poem having more than one author?

2) Do we distinguish between a poem with no author and poem whose author is anonymous?

3) Do we have one anonymous author associated with all unattributed to poems, or do some unattributed poems get associated with one "anonymous" and other unattributed poems get associated with another "anonymous" (for example, if you have a collection of poems you know to be written by one unknown person and wish to distinguish that author from another unknown person who wrote another poem)

4) We've noted that authorship can be declared or can be inferred by the scholar, are there any other ways authorship is attributed? (We'll need to include a "authorship_determined_by" field to contain that information.)

5) We need to tighten up conventions on what information we capture about each person's name (and possible title or other identifiers) and how each of those is to be represented in the spreadsheet. The most common presentation of author name is Surname, FirstName, but a number of entries don't conform, for example these from DarkBlue.xls:
Ca(d)(l)verley, C.S.
see title
R.G.
Professor Sylvester
the late John Lyall
Leary (D.C.L.), T.H.L.
And these from DublinU:
M
M?
'Filia'
The London Hermit
Rev. Dr. MacMoreland
And these from PoetryIndex_1.docx
Edward Oxenford
We discussed having an "author-as-found" field and an "author-normalized" field.

6) Do we separate author surnames from given names e.g. for purposes of searching?

7) We also need to tighten up conventions on what information we capture about each published poem's title and how each of those is to be represented in the spreadsheet. Some of the "titles" appear to be titles, others appear to be the first line of the poem. Do we want to distinguish between those?

8) These are instances of titles that appear to contain more than just the title. Do we need to do anything with these other than reproduce the characters as found?
Tragedy (trans. from the German by Franz Huffer)
The Story of Europa (Hor. Od. III. Xxvii. 25.)
'Amour qui Sourit Caché'
One untitled poem opens and two close the author’s essay “Sketches of Travel in Germany”

9) This example of a title in DarkBlue appears to refer to a collection of poems.
Garden Poems (I.—The Garden, II.—Visions, III.—The Bird ...)
This example from DublinU also appears to refer to a collection, but is treated differently:
I [Happiest of happy feelings ‘tis to feel]
II [If gold could give us peace]
We have no structure right now for handling collections of poems. Should we? That is, do we want to treat an entire collection as one poem (what about collections whose poems are written by different authors) or do you want to treat each poem in a collection as a separate poem and then add a "collections" table and some way of relating each of the poems to the collection?

10)
In the poetryindex_1 file, a typical entry begins like this:
[January 1886]
No. 1, 129
(7)
Whereas, in DarkBlue the issue/page field looks like this:
1 (March 1871): 35
What does each piece of information in both types of entry identify? We'll need to normalize that.