DHQ meeting 10/12/07

John Walsh, Michelle Dalmau, Wendell Piez, Julia Flanders, Ashwini Athevale met in Bloomington to discuss technical development issues.

We discussed a number of issues (notes represent net results, not order of discussion):

1. Schedule for technical development over the next year

Set up development server at IU to allow for experimentation without Amit's help, at SLIS

• buy a box from DHQ funds
• use it for sandbox and for a development/test/internal version of the DHQ environment
• run subversion on it
• maybe use it for Zone 2? need to discuss this further but it's an option

Move to cocoon in Feb/March; this might be either before or after issue 2.1 depending on how soon that appears

With the cocoon environment will also come subversion control for articles, stylesheets, etc.; we discussed the Xubmit tool which could serve as an easy interface for subversion and also provide easy validation, transformation, etc.

Once the cocoon environment is available, this will also enable us to plug incoming articles into a "draft" publication environment as soon as they're encoded so that authors can see online proofs

In writing up these notes it also strikes me that we could conceptualize the web visibility of articles in three phrases: "proof" (internally visible), "preview" (publicly visible), and "publication" (publicly visible)]

Get a blog in place by July, if cocoon goes well and Ashwini stays; see below for details

Implement searching after the blog is in place, perhaps by the end of the summer? Searching will take advantage of added content encoding (e.g. names, titles, etc.), and on getting a substantial body of content in hand (by then, ~6 issues, 25 articles?)

Implement indexes: title, author, maybe subjects?

2. Blog issues

We discussed a number of issues in connection with the addition of a blog for DHQ:

• design integration issues: need to think through where the blog would sit as a visible part of the DHQ interface. Our initial thoughts are that it would feed teaser-like snippets to the front page in the manner of news items, but that its reading interface would be as a separate page (perhaps listed in as an item in the front-page TOC?); it should appear as seamless a part of the DHQ interface as possible, rather than feeling like a separate place where you go to read the blog, and there should be as many opportunities as possible to go back and forth between articles and the blog; need to think about automatable ways to generate links and connections
• need to identify what kinds of information it needs to feed to the interface in order to be integrated
• NB Stefan uses WordPress? ; we plan to look first at this one and see if it will work, how customizable it is
• we discussed the issue of what kind of blog it would be (i.e. what kinds of entries) and observed that ideally it would be a mix of new content (i.e. entries authored for DHQ) or metacontent (i.e. critical mentions of entries authored elsewhere) but not transparent inclusion of entries authored elsewhere. In other words, not simply an aggregator, but to some extent a critical aggregator. It should be to other blogs as the New York Review of Books is to other publications: not as Books in Print is to other publications.

We also discussed the possibility of using the blog as an easy way of introducing commenting functionality to DHQ

• to enable commenting on articles, each article could generate an automatic (empty) blog entry which could then serve as a hook for comments. (Need to think about how and where the comments would become visible; presumably the comments would carry some identifier linking them to the article-blog-entry, which could then be used to grab them and hook them to the actual article as needed for display or discovery.)
• this would focus people's attention on commenting at the article level rather than at the paragraph level, which might also be a good thing, at least as a first step; we could always add more granular commenting later on as we had initially planned to do
• we discussed the registration mechanism for commenting (which the blog software would also provide): obvserved that it should be simple and not a barrier to entry; probably only minimal information needed from people to protect against spam (name, email address, affiliation; need to confirm the email address?)
• we discussed the question of moderation; probably we do need some person to observe the comments (not pre-approve them but take note of them) and occasionally to remove spurious/malicious/etc. items
• (it also occurs to me that we should have a clearly stated policy that DHQ reserves the right to delete or suppress comments as necessary, but that in general only malicious or spurious comments would be a concern--in other words, we don't want to edit the discourse, we just want to keep it clean)

3. Schema development

We examined the schema and worked through a number of areas, focusing on metadata.

We're now moving to a two-schema world:

DHQAuthor: used by authors for authoring and submitting articles

• can be either "draft" or "article"
• if an "article", header required, but no publicationStmt
• no internal content encoding of the kind that we may add
• keywords solicited but optional

DHQPublish: used by DHQ staff when encoding accepted submissions (including those submitted in DHQAuthor; need to switch schemas at this point)

• more extensive header with publicationStmt

For the publication schema, we discussed the following metadata and checks:

• link integrity: checking IDREFs (SCH); run link checker as well
• check for abstract, author bio, teaser (SCH)
• other metadata: author email, affiliation (institution), name
• publicationStmt containing vol and issue info, issue title, article type
• volume and issue numbers
• issue title: "Spring 2008", "Special issue: Multimedia..."
• date released
• roll <availability> into <publicationStmt>
• add <relations> to manage relationships with other articles or parts: uses type to describe relationship, and allows pointer (prior versions, other sections, includes, responds-to
• modify <change> to P5 version
• add id= for entire article in <publicationStmt> (or use <idno type="DHQ">)

Encoding of multimedia

• graphics element needs to include
• <mmobject> element with attributes, to handle audio/video/functional aspect: type=, url=

For the authoring schema

• rend with controlled values
• optional keywords in the header, requires resp=

For IM submissions

• we decided we need to include a manifest with editorial checklist: readMe, platform dependencies, tools/plugins required, parts list; this should be a section of the submission itself, rather than expressed as a header.
• we discussed the possibility that some IM metadata might be needed: e.g. download plugin needed, system requirements, hardware/software/browser. This probably isn't needed for our internal purposes, but would be useful in cases of library acquisition.
• we also discussed a checklist of parts and information needed about IM submissions; need for this would be driven by the publication team, so Michelle will supply the requirements if this is needed.

4. Multimedia issues

We discussed a number of issues relating to multimedia included in Zone 1 documents: e.g. graphics, audio, video; Michelle has detailed notes on this section of the conversation

• in general, we're just linking to these things
• add a new mediaObject element that includes info about type (e.g. YouTube? ) which can help with appropriate processing
• request from authors images of as high a quality as possible; we will resize and also may provide a link to a larger image in cases where closer examination is needed
• for sound and audio, need to allow viewing/listening in the DHQ window itself, rather than going somewhere else.

5. Tools and features

We discussed the TAPoR? tools suite and how best to approach this

• ideally we would have a sandbox area, publicly visible, where we can install tools on a trial basis for user examination.
• tools would be installed there in the first instance, by DHQ technical group or by skunkworks participants (small group of volunteers with permissions on the development server)
• skunkworks people are free to improve tools, work with the tool developers, etc., so that tools and ideas can develop as they sit in the sandbox
• each year, one or two tools can be nominated for migration/integration into the DHQ production environment: this lets us fundraise for this process (e.g. NEH digital humanities startup funding, etc.) and also rationalize it a bit: have some ability to see which tools have real potential and have attracted user attention; gives us a more rational process for tackling issues of design integration with DHQ interface

NB possible "user tools" suite: bookmark this, email this, cite this, etc.; this would be on deck for consideration after searching and indexes are implemented.

-- JuliaFlanders - 21 May 2008