At present, TOCs are only generated for documents which have multiple
<text> elements. This is resulting in documents which should never have multiple texts being created that way, just so they get an automated TOC. Obviously this is silly, and I need to revise the system so that it continues to support the existing documents (while we change them -- although perhaps not all will change), but supports TOC generation for single-text documents based on some measure of complexity. (Or perhaps all documents with multiple div elements should get a TOC by default?)
We are thinking of using the occupation element to describe someone's role/contribution to the project. The @code attribute could point to a formal taxonomy including Editorial Board Member, Author, etc., while the actual text content could provide a refined version of this specific to the person. Multiple occupation elements could be provide for people with multiple roles, and the Credits page could provide a list of all of the taxonomy types, as links which would generate or jump to detailed tables of the people in those roles.
EDIT: I'm adding DONE as I caomplete each task.
Tasks arising out of today's project meeting:
CB now has a user id on the eXist db, and is a member of the editors group. In the process of testing this, we discovered that lots of files and dirs in /db/data did not have group write, or were assigned to the dba group, which meant that he couldn't overwrite them. This is fixed for most files, but we need to watch out for it. I think it may happen when I upload stuff as admin; although admin is in the editors group, it's also dba, and it may cause uploaded data to be set to group dba.
I have a task, which needs to be clarified a bit before I start work on it. We have two types of links: those which open up popup windows, and those which navigate off the page or off the site. It would help users if they could tell the difference before they click on one. A number of options are under consideration.
I am really enjoying my time with MoEML so far. While working through the BIBL1 and PERS1 files I have noticed a few things that we will need to be thinking about in the near (and distant) future. The following is a log of my tasks so far, including notes about what we may need to think about looking forward.
My first task was to delete the dates and names of contributors who have added files to BIBL1 in the past. JJ decided that there was no longer any need for this info. Working in this file, I noticed numerous formatting inconsistencies (arising from different people adding different info at different times with different MLA conventions). I look forward to amending these errors in the coming weeks.
My second task was to ensure that all links in PERS1 were updated. The ODNB had made some changes to their website and so most of our links were broken. Again, I noticed many formatting/style inconsistencies that I am eager to amend in the coming weeks.
My third task was to add the medium (i.e. Print, Web) to each BIBL1 entry. This is a newer MLA convention and has not been used consistently since the website launched. While adding these, I made some changes to the more easily-spottable inconsistencies. This got me pretty excited about a large-scale tidy-up! I am hoping to have this "spring cleaning," as I am calling it, finished by mid-June.
Since I will be spring cleaning for the next few weeks, JJ has assigned me the task of creating an updated style guide for the website. This will ensure that everyone adding information to these files continues to follow a correct and consistent format. I cannot stress enough the importance of consistent formatting for even the most trivial matters like using an en-dash instead of a hyphen between a person's life dates. If we are to continue to assert MoEML as a serious academic publication, we cannot allow formatting errors to persist. I (think I) have attached a draft of the style guide (which is also available in the svn file "documentation," in case the file addition backfired) and I would love to hear your input. It is not yet completely implemented, but please begin referring to it when inputting information. If you have any questions about formatting, please don't hesitate to contact me.
I think that's all for now. Thanks to JJ and MH for all of their guidance so far.
JJ, MS, and CB have started to use the title level="a" markup for articles, both in the BIBL1.xml file and in the markup of pages where an article title appears.
Current rendering code puts quotation marks around article titles. We note, however, that MLA style and MoEML house style call for commas and periods to be INSIDE quotation marks, even if they are not part of the quotation. Colons, semi-colons, exclamation marks, and question marks remain outside the quotation marks.
The rendering code we need will pull a following period or comma into the quotes but leave a following colon, semi-colon, or question mark outside the quotes.
If the question mark is part of the title, then it will be inside the title tag anyway and will be automatically included inside the quotation marks.
Priority: Sometime this summer. We can leave with a few stray commas until MH has time to write the code.
Right now, the titles of articles are not showing up in our handy list of all XML:ids used in the site. Let's try adding the title level="a" tag to a couple of articles, then checking out what displays on http://mapoflondon.uvic.ca/ids.htm. I've asked MS to undertake this task next week. If titles do not show up, we'll ask MH to adjust the programming.
This is the second blog entry recording IDs created that need some follow-up action. Click on the Category "ID Created" to see all blog entries pertaining to new IDs.
IDs Assigned that Need to be Added to the Map (adding them to the map automatically adds them to the Index)
IDs Assigned that Need to Be Added to the Index but not the Map (because they are off-map, cannot be located with certainty, or are too big to be marked
IDs Assigned to Livery Companies (add to Index but not to Map)
Neighbourhoods: These need to have their own Index. They won't link to points on the map.
Dan and I talked about whether or not to make new pages for prisons in gates that doubled as prisons. E.g., should Newgate become Newgate [the gate] and Newgate Prison? We decided to capitalize on the ambiguity of having a page called Newgate because many EM texts are ambiguous in their referents. Having only one page means that we don't have to resolve which page to point to, and also allows us to logically encode the ambiguous references.
This decision means that we will have to reverse the earlier step of creating a Ludgate Prison page [XML:id LUDG2] and will have to re-encode any references thereto so that they point to Ludgate again [XML:id = LUDG1].
This post needs to be recategorized as "House Rules."
Add to list of Sites on Index: Lord Wentworth's Jail
:: Next Page >>
This project allows literary and scholarly works (primary and secondary) to be associated with locations in London, providing the reader with a richer understanding of the works.
|<< <||> >>|