Sean Gillies (Posts about digital humanities)

More field goals, fewer pratfalls

Sean Gillies — Tue, 05 Jun 2012 06:00:00 GMT

For a computer user in the humanities who doesn't develop their own tools and information systems (for all kinds of good reasons), using technology "the right way" may look like an ever-growing list of fashion prescriptions.

"Use MS Access or Filemaker"
"Use a relational database"
"Use TEI XML"
"Implement web services"
"Provide RSS feeds"
"Make a web API"
"Cool URIs for everything"
"Use RDF"
"Use a triple store"
"Use ontology X"
and so on ...

Of all the discussions at LAWDI, the one that's on my mind this morning is the very short one I had with Eric Kansa about what happens when linked data principles start being used as criteria for evaluating the fundworthiness of projects in classics and archaeology. It could be disruptive, and it's on me and Eric and others to make sure that we're not setting researchers up for a frustrating run at a football that is pulled away at the last moment.

Maybe the following might be useful prescriptions for we linked data evangelists.

Don't focus too much on counting triples.
Don't beat projects up about their ugly URIs.
Don't make openness a moral issue.
Let projects get easy wins from simple vocabularies and ontologies (SKOS, for example).
Show people what to do instead of telling people what to do.
Emphasize results and getting things done.

I'm sure others can think of more.

Pleiades software reuse

Sean Gillies — Mon, 26 Mar 2012 06:00:00 GMT

Yesterday I read Melissa Terras On Making, Use and Reuse in Digital Humanities:

That's right. The code we made is now in use by another institution, to do their own transcription project. Hurrah!

It was always our aim in Transcribe Bentham to provide the code to others: it was a key part of our project proposal. But you always have to wonder if that is going to happen. Its the kind of thing that everyone writes in project proposals. And whilst lots of people talk about making things in Digital Humanities, and whether or not you have to make things to be a Digital Humanist, we've shied away - as a community - from the spectre of reuse: who takes our code and reappropriates it once we are done? How can we demonstrate impact through the things we've built being utilised beyond just us and - quite frankly - our mates?

So I'm happy as larry that the code we developed, and the system we have built, is both useful to us, but is now useful to others. I'm not sure how much I want to prod the sleeping monster that is general code reuse in Digital Humanities... dont draw attention to our deficiencies!

But I would be delighted if anyone else could point me to examples where code and systems in Digital Humanities were repurposed beyond their original project, just as we would wish?

I was unable to persuade Recaptcha to let me leave a comment and congratulations on Melissa's blog, so am writing a brief post here. TL;DR Transcribe Bentham: congrats! My own horn: toot! toot!

To my knowledge, no one has set up another instance of Pleiades as a gazetteer. But code written for Pleiades gets reused more and more widely the further down in our stack you look. I designed it to be modular and reusable – a stack of tools, not a single tool – so I'd be disappointed if that wasn't the case. I'll explain how it works for us.

Pleiades uses the Plone (and Zope) web application framework. Our Plone products and packages have taken on a life of their own as the collective.geo project. IW:LEARN is a good example of a collective.geo site. Contributions to collective.geo by almost 20 other people have been making Pleiades better. And this is just the start of our reuse story.

Pleiades and collective.geo Zope and Plone packages are based on Python GIS packages spun off from Pleiades such as Shapely, Rtree, and Geojson. At PyCon a couple of weeks ago, I ran into a lot of Shapely users. I saw it mentioned on slides in talks and on posters in the poster session. Famous web and geography hackers even write about using Shapely from time to time. Shapely feature-wise, Pleiades now gets as much back from others as we give out. This is a fantastic position to be in.

Digging deeper in the stack, I've contributed (as "sgillies") to the development of GEOS as part of my work on Pleiades, so Pleiades has thereby played a tiny role in making thousands of open source GIS programs and web sites more spatially capable. A Python protocol for sharing geospatial data that we invented for Pleiades has been implemented rather widely in GIS software. Anywhere you see __geo_interface__ and shape() or asShape(), or programmers sharing data as GeoJSON-like Python mappings, that's the impact of Pleiades. The GeoJSON format itself has some of its roots in Pleiades.

Even if no one ever sets up another Pleiades site, we're having a significant impact on GIS software and systems, even on big time GIS software being used for Spatial Humanities work. The keys to having a similar impact are, in my mind, 1) modularization and generalization to increase the number of potential users and contributors, and 2) a policy of open sourcing from day zero instead of open sourcing after completion of the project – and after people have lost interest and moved on to other software.

Comments

open sourcing from day zero

Author: Christian Ledermann

Release often, release early. It is important to let the community know what you are up to, though it might feel a little embarrassing to make unfinished buggy alpha code available to the public it has big advantages. E.g. when I released the alpha of collective.geo.index the UI was unfinished and ugly, not one of my priorities. It would probably still be unfinished and ugly if it was not for David who gave the UI some TLC just days after the initial announcement.

Thank you very much for your hard work and your great products :)

Linked Ancient World Data Institute

Sean Gillies — Thu, 12 Jan 2012 07:00:00 GMT

From the ISAW blog:

ISAW will host the Linked Ancient World Data Institute (LAWDI) from May 31st to June 2nd, 2012 in New York City. Applications are due 17 February 2012.

LAWDI, funded by the Office of Digital Humanities of the National Endowment for Humanities, will bring together an international faculty of practitioners working in the field of Linked Data with twenty attendees who are implementing or planning the creation of digital resources.

More information, including a list of faculty, and application instructions are available at the LAWDI page on the Digital Classicist wiki.

I'm excited to get to play a small part in this. I was on the faculty of the UVA Scholars' Lab's Institute for Enabling Geospatial Scholarship in 2009 and got to see first hand how an excellent institute is run. We'll try to live up to the high standards of #geoinst.

Simple in theory

Sean Gillies — Fri, 18 Nov 2011 07:00:00 GMT

Rich Hickey's "Simple Made Easy" presentation at Strange Loop, recommended to me by my Clojure programming co-worker Hugh Cayless, is flat out awesome. "Guardrail Programming" and "Knitted Castle" are my new favorite metaphors. Hickey has a compelling theory about complexity and after watching the presentation, I feel like I can be a better advocate for simplicity. Advocate to those who like theory, at least. For others, the proof remains in the pudding, whether simple means better software.

REST, the architectural style, didn't factor into Hickey's talk at all, but is a great example of an approach that chooses simplicity over ease. REST is hard. It is. You're wrong if you've been thinking that REST is easier than SOAP or COM. Look at almost any (there are exceptions, yes) so called "REST API" and you'll see something produced by web programmers that tried to apply the REST style and either couldn't get their heads around it or gave up on it under pressure to deliver. REST is hard to understand and it can be difficult to explain its benefits to managers and customers that prioritize ease over simplicity. REST is hard, but REST is simple. It is predictable and you can reason about what you can or cannot do with it.

There's a notion in the humanities that DH (digital humanities) is undertheorized. I'm not a humanist, really, just a programmer, but I strongly disagree. Programmers in the humanities are doing a great amount of theoretical work. As well as reading Hugh's recent posts, digital humanities theorists owe themselves a look at Hickey's theory of complexity and Roy Fielding's theory of representational state transfer. The world of programming and the field of humanities programming and computer are more theorized than they appears to non-programmers.

Pleiades "un-GIS" poster

Sean Gillies — Tue, 21 Jun 2011 06:00:00 GMT

This is the graphic from the imagemap version of the poster Tom Elliott and I put together for the Digital Humanities conference at Stanford University. It's a Frankenstein's monster of a diagram, showing relationships on different planes between Pleiades resources and code and other resources and communities.

By "un-GIS", we mean that our geographic information system compares to industry standard GIS as an unconference like a ThatCamp or WhereCamp compares to AAG or ESRIUC. We're not rejecting principles of geography and cartography at all, but we are reducing formality and complexity and trading other properties of conventional GIS for scalability and flexibility. It went over well at DH11.

DH/Geo/LOD Workshop March 24, London

Sean Gillies — Wed, 09 Mar 2011 07:00:00 GMT

An upcoming workshop that I'd previously mentioned now has a page for signup.

The Pelagios workshop is an open forum for discussing the issues associated with and the infrastructure required for developing methods of linking open data (LOD), specifically geodata. There will be a specific emphasis on places in the ancient world, but the practices discussed should be equally applicable to contemporary named locations. The Pelagios project will also make available a proposal for a lightweight methodology prior to the event in order to focus discussion and elicit critique.

The one-day event will have 3 sessions dedicated to:

Issues of referencing ancient and contemporary places online

Lightweight ontology approaches

Methods for generating, publishing and consuming compliant data

Each session will consist of several short (15 min) papers followed by half an hour of open discussion. The event is FREE to all but places are LIMITED so participants are advised to register early. This is likely to be of interest to anyone working with digital humanities resources with a geospatial component.

Comments

Perl+RDF Hackathon the week after

Author: Kjetil Kjernsmo

The week after, I'm organizing a

"Semantic Web with Perl hackathon" in London.

If any of the participants on the Pelagios workshop would be interested in contributing to advance the state-of-the-art of Perl tools to work on LOD, please let me know.

Pleiades and DARMC

Sean Gillies — Tue, 29 Jun 2010 06:00:00 GMT

Here is ISAW's Associate Director for Digital Programs (my boss), Tom Elliot, on collaboration between Pleiades and DARMC [Ramping up Pleiades 2]:

Meanwhile, we've been in dialog with Michael McCormick, Guoping Huang and Kelly Gibson at Harvard. They're the driving force behind the Digital Atlas of Roman and Medieval Civilization, with whom we're collaborating under the new grant. Our aim is to collate and share the datasets assembled by both projects and to cross-link our web applications. This will bring more accurate coordinates for many features into Pleiades, as well as a number of new features that will expand our time horizon into the middle ages. You'll get a choice of display and map interaction modes and, eventually, the ability to move back and forth between both resources. We'll keep you posted as the timeline for this portion of the work is refined.

Shapely 1.2b5

Sean Gillies — Fri, 09 Apr 2010 06:00:00 GMT

Update (2010-04-28): 1.2b7 has another important bug fix. Links are updated below.

Update (2010-04-13): 1.2b6 has an important bug fix. Links are updated below.

Shapely 1.2b5 is uploaded to http://pypi.python.org/pypi/Shapely and http://gispython.org/dist/. It contains a few enhancements that suggested themselves while I was writing example code for the user manual.

To install and try it out (in a virtualenv):

$ pip install http://gispython.org/dist/Shapely-1.2b7.tar.gz

$ easy_install http://gispython.org/dist/Shapely-1.2b7.tar.gz

A sneak preview of the (still in progress) manual for 1.2 is online at a non-permanent URI: http://gispython.org/shapely-1.2/manual/manual.html. Feedback on the HTML has been positive. I hope that the content is (or will be) even better. There are copious code examples and figures (with code) made using descartes. A lot of the discussion is based on Martin Davis's JTS docs, without which I'd be nowhere.

In other Shapely news, the project in which it originated has been refunded and will be the biggest part of my job over the next few years. Count on improvements to the code and the docs.

NSF funding for historical GIS

Sean Gillies — Tue, 10 Nov 2009 07:00:00 GMT

Wow, indeed (via @brettbobley):

It isn’t often the National Science Foundation funds a project from a humanities discipline with a history professor as a principal investigator, but that is exactly what happened earlier this fall when ISU history professor J.B. “Jack” Owens received an award for a project titled “Understanding social networks within complex, nonlinear systems: geographically-integrated history and dynamics GIS.” About $1.3 million of the four-year grant will go to ISU, with about $471,000 to go to the University of Oklahoma and co-principal investigator May Yuan.

That's big money for digital humanities. It's the first I've heard of their project. Good news for MapWindow, perhaps?

Can't happen here

Sean Gillies — Thu, 05 Nov 2009 07:00:00 GMT

Says Paul Ramsey in comments on Paul Bissett's great post about disruption of the data and navigation business:

Right, a black hole isn’t “evil”, but that doesn’t change the fact that it massively distorts the shape of space-time everywhere it goes, which can be a bummer for any object in its immediate neighbourhood.

Thank the gods that Digital Classicism isn't GIS. It can't happen here.