Over the past month or so I've had to prepare for the coming expiration of the makingpublics.org domain. Though the project officially concluded in 2010, a remainder of funds was allocated to re-imagine its website, and see whether discussions could continue. In short, though we received some traffic initially, and some requests for new user accounts over the years, the new site did not take of on its own. Nevertheless the work done on it acted as a good leaping point for the new NanoHistory site which launched this last fall. When I arrived at McGill to take up my position as a postdoc and webmaster for MaPs, I made it a priority to archive and preserve the work of my predecessor, Jen Drou
read more

Building parsers for Nanohistory has involved quite a bit of thinking about what's in a name. I'm going to leave organizations, places, and things and outline how I've approached the issue for prosopographical data. Let's get some basics out of the way first - just so we're clear on what's going on. A "name" is essentially a label; whether it as attached to anything in particular is secondary in practical terms. In short, a name is a descriptor for something that can exist in reality or be completely fictive. This is important to note because unlike a cataloguer in a repository, historical scholars are interested in the movement and shaping of identities: names are the lynchpins, but do not
read more

Open Data is great - despite the fact most historians have no idea what it is or how to use it. It uses standard vocabularies, namespaces, and taxonomies to describe data, allowing researchers to move data from one context to another easily. Yet it's also rather complicated for the average humanities scholar (let's be honest here) since it also requires familiarity with data types and formats like XML, JSON, Turtle, etc. These aren't always usually picked up for those with mind towards prose and manuscripts, though they're not difficult, really. When it comes to the bibliographic world, we now have excellent tools for quickly creating lists and generating metadata as needed - Zotero, EndNote
read more

I'm releasing a revised version of the EEBO-TCP Phase I metadata mashup I created last fall. There were some issues with nested elements in the which needed addressing. These new headers will soon make their way into DREaM. Here is the revised version: EEBO TCP Phase 1 DREaM Metadata Headers - May 6, 2016 (~43MB zipped). For more on the full process and EEBO-TCP policies for using Phase I, see my earlier post EEBO-TCP Metadata Mashup
read more

I've been busy migrating two new tools for NanoHistory. Both are geared towards making life easier for users, as the main problem for NanoHistory is the density of data entry and connections which need to be made quickly, easily, and accurately. This work focuses on rapid creation of new events or connections between existing nodes or entities, and the transcription or documentation of entities and events from online source materials that aren't well suited to automated processing - mainly manuscript sources. Like existing NanoHistory tools, I've given these them one word names - Weave and Scribe. Weave In Making Publics, in many ways NanoHistory's progenitor, we created a workbench tool c
read more

Is it possible to build a kind of fingerprint of a given historical source or text using discreet parameters, and compare it with others? Radar is an experimental tool that seeks to do just this. Whereas text analysis tools and software allows scholars to extract named entities, parts of speech, or identify elements of a given text, NanoHistory's model requires users to do so in order to create evidentiary trails through the historical record. In essence this establishes a different kind of typology for text analysis as entities are mentioned, referenced, or cited in a thing, imbuing the resulting data with a critical characteristic - an assertion of meaning. Radar allows users to compare th
read more

NanoHistory's use of graph or network models immediately lends itself to creating the usual force-directed representations of networks that we've grown accustomed to over the past decade or so. For the inhouse network visualization tool, which I'm calling 'webs' for lack of a better name, I've opted to adapt D3's well known force directed example. I've mashed it up with some later versions by other D3 designers, and tweaked it for our use. Two issues related to scale affected the development of this core tool. The first was building an effective query engine that would allow for users to create visualizations of data as needed from the overall NanoHistory collection. The second was handling
read more