When to use Drupal
When does it make sense to use Drupal, rather than WordPress or a more lightweight technology (e.g. generating static HTML pages)? Key indicators are having fairly structured data where you want to make use of that structure, and wanting to specify and leverage relationships between different pieces of data.
Projects that are a good fit for WordPress often have a lot of text — blog posts, descriptions of the project and its participants, perhaps even full-length essays, articles or books. These kinds of texts do have a certain structure; they generally have a title, an author, a publication date, and perhaps some categories. WordPress has some lightweight ways of leveraging parts of this data— for instance, seeing all posts with a given category. With some additional work, you can also make it display all posts by a given author. But most of the structure of the text stored in a WordPress site isn’t machine-readable; there may be some headings (“chapter 1”, “1.1 Introduction”, etc.) that use HTML markup to specify that they are headings (e.g. a <h2> tag), but there’s no easy way to query a WordPress site to display only the abstracts from only the texts that are articles.
Drupal also supports this kind of loose structure out of the box; there’s a “basic page” content type that corresponds to the WordPress “page”, and an “article” content type that corresponds to the WordPress “post”. It’s not uncommon to have such minimially-structured data as part of a Drupal site; if, for instance, you want to include CVs for the project’s directors, but the details of those CVs don’t constitute data that you want to be able to specifically reference or connect to other data on the site, it’s perfectly reasonable to create a couple of nodes (Drupal jargon that roughly corresponds to “web pages”, though they don’t necessarily have to be) using the “basic page” content type, and just paste the CV contents into a large text box and be done with it. On the other hand, consider a project that looks at academic genealogies, where it would be important to granularly capture information some of the information contained in a CV, in order to show which scholars worked together as peers, in a mentor/student relationship, who coauthored which articles, when certain research topics were in vogue, etc. There’s no easy way to do that in WordPress, but Drupal would allow you to create a CV content type, a template with specific fields for each kind of information that you want to capture. Developing a good data model is one of the biggest and most important challenges of a Drupal site; choose the wrong type of field for capturing a particular kind of information, and it limits the ways you can connect and reuse that data in other contexts. Chapter five of Drupal for Humanists discusses how to break down your data into different content types, and chapter seven works through an example of how to decide between different common field types. A few other examples of how different projects use Drupal:
Open Catalogue Raisonné Platform
A team at UC Berkeley is developing a Drupal-based platform for creating catalogues raisonnés, comprehensive, annotated listings of all the known artworks by an artist either in a particular medium or all media. The data in these catalogues is fairly uniformly structured, using one or more controlled vocabularies (e.g. for describing the media of artworks, provenance data, location, dimensions, genres, etc.) The project is creating a fairly general template that can accommodate most catalogues raisonnés, but because it’s based on Drupal, individual scholars can easily expand the template to accommodate types of information specific to the works of the particular artist they study. By creating displays using the Views module (discussed in chapters 12 and 13 of Drupal for Humanists), scholars can easily investigate questions including which pieces of art tend to appear together in exhibitions, whether images above a certain size are more or less likely to change hands, how the pieces of art have circulated historically, whether and how exhibitions impact the value of paintings, etc.
George Washington Financial Papers
A team at the new Center for Digital Editing at the University of Virginia is developing a Drupal-based platform to support documentary editing, starting with financial papers but expanding to include other genres of material as well. The George Washington Financial Papers are being used for a prototype. The major content types mirror the structure of historical bookkeeping practices, including single-entry and double-entry ledgers. Each entry in the ledger is stored as its own node, and includes information such as the text describing the expense/credit (in the original form, a normalized form, and categorized according to a controlled vocabulary), to whom it is owed/credited (using a node reference to be able to point directly to a page with more information about the entities with which George Washington did business), the amount (in its original formulation, as well as in an integer form that can be used for calculations), and similar information. Each entry also includes its entry number, and a pointer to the page on which it occurs. Each page also exists as a node (using a different content type), and contains any page-level metadata (e.g. date ranges for undated entries on the page), as well as a pointer to the ledger in which the page occurs. Each ledger itself exists as a node, with any metadata that applies to the whole ledger. By capturing all this information in a granular way, it’s possible to see to what extent medical expenses increased in the winter, to chart the frequency and extent of George Washington’s business relations with any particular entity, to compare his spending across different categories and different time periods, etc.
The DiRT Directory is a centerNet initiative that provides information about digital tools for scholarship, primarily in the humanities. DiRT started out as a wiki, with essentially no structure to the data. Tools were divided into a handful of categories, and each category had its own wiki page. Within the wiki page, the tools were simply provided in a list, with a little bit of metadata (e.g. whether the tool was free of charge) and a brief description. In 2011, as part of Project Bamboo, DiRT was relaunched as a Drupal site. In this new instantiation, categories are metadata rather than pages, though the Views module is used to generate a list of tools within each category. Each tool has its own page, and the information about it (cost, platform, categories, description, screenshots, logo, etc.) is stored granularly, each in its own field. This makes it possible for users to easily sort and filter tools— for instance, filtering the category-based listing to only include those tools that are web-based or Mac-compatible.