Main »

Workshop On Application Programming Interfaces For The Digital Humanities

I'm at a workshop organized by Bill Turkel on APIs for the Digital Humanities that was funded by SSHRC under the ITST program. See http://niche-canada.org/digital-infrastructure/apiworkshop

This page has a Tiny URL http://tinyurl.com/ykr8q2k - Twitter hashtag is at #apiworkshop

Notes: these are being written on the fly and are not representative.

Raymond Yee on the API

Raymond Yee gave us an overview of APIs. See http://bit.ly/7i0qH for links. He wrote Web 2.0 Mashups which is also online. We had a discussion about where it is we want to get. Some of the issues:

  • As attractive as Google Maps and Flickr are, they only allow limited access. We want to encourage deep access.
  • Certain APIs can close things down.
  • We want web-scale APIs (as opposed to deep level APIs). We want things that students can easily play with.
  • Too many content owners want to brand their stuff so they don't give any access. Ownership branding gets to the heart of the academic face economy - it is our coin. There was a discussion of the roles of libraries and the challenges they face. I think there are tensions between the content people and analytics.
  • Robustness is important to successful APIs.

Soap Box

We ran a 30 second shoutout so that people could talk about a pet idea.

  • How to separate content and user interface. MITH has a 4 layer model: i) content, ii) metadata , iii) widgets that do things, and iv) user generated knowledge. APIs are useful for the third widget level.
  • Libraries need to think differently - they should not think about collections they hold but about what users want.
  • We should think about the web as an API.
  • Go to maps.nypl.org - get an account and try their mashup for maps.
  • The difference between APIs that are content driven and those that are function driven (as in APIs for tools).
  • Content or data APIs need to be both public and private where private ones respect copyright and so on.
  • We have to make this simple - we have to hide the plumbing and show recipes of how mashups can be done.
  • Lots of us have cool projects with APIs - how can they be discovered.

Stakeholder Groups

We formed into groups around different types of stakeholders. I was in a Clusters group.

  • It is hard to bridge differences in technical ability.
  • Universities can restrict tools to only members of the university.
  • We need internships across different projects as a way of sharing knowledge.
  • When developing a collaboratory (Web 2.0 community like the Wikipedia) one needs a common referent.
  • How much can we do with off-the-shelf tools like Google Docs.
  • We can see common practices of groups that might be what we want to aim APIs and tools to. They would include: i) creating a shared bibliography, ii) organizing a conference, iii) organizing a journal or publication, iv)
  • Can we imagine a research bartering system where people could get help from others far away - a mechanical turk for research.
  • How do we get sociopaths to collaborate? Could technology ever be a solution. Most researchers want anonymity and space for solitary research.
  • We talked about how to do cluster to cluster collaboration. I mentioned the model in the arts of an alternative to Google ads where clusters give advertising space to each other. See Culture Pundits or Feral Trade
  • Do good APIs and tools make us cognitively lazy so we don't learn about how to do our own research and be critical of what is aggregated.
  • There is a flattening of knowledge as we start expecting it on the internet.
  • If Google (Wave?) is going to do it all, then what is left for us? i) We make the quality content, ii) we think long term and Google will disappear over the long term, iii) we develop tools which Google will never, and iv) we teach the next generation.
  • Google's Street View is a unique snapshot of, for example, the streets of Toronto last Spring and there is nothing like it.
  • To make APIs work we probably have to learn to do simple things rather than complex things. Projects should do simple things well and let others mash them together. Do we trust others enough to depend on their tools? Are we ready to not roll our own?
  • If we were to push the idea of using what is at hand (on the web)
  • We need to give our research assistants and students time to do whatever they want (the way Google supposedly gives their employees 20% of their time to work on anything.)
  • We need to support things socially. We need to list all participants in papers and find other ways to support and credit social groups.
  • We used to build things in the hopes everyone would come to us. Now we need to think about how to push data and functionality out so that others can use it.
  • What do we need to support humanities mashups with existing stuff? We need: i) a guide to APIs that can be used, ii) ways of "branding" disparate elements so they look like they are part of a common project, iii) training, and iv) some exemplars that communicate to the unsophisticated.
  • Maybe the issue of publishing (vs doing cool computing API stuff) isn't that important - in Canada, for example, the tenure rate is so high that people probably don't need to worry. The problem is getting the tenure-track job.
  • The problem may be graduate schools who want to graduate students quickly so they don't give grad students time to engage other communities or deal with methods other than the most conservative.

Saturday

Demos

We started Saturday with some demos.

  • Raymond Kee talked about what he is trying to do with information about stimulus spending in the US.
  • We saw a quick demo of Our Ontario - http://www.ourontario.ca/
  • Dan Cohen talked about extending Zotero - see http://www.zotero.org/support/dev/start . We can write a Firefox extension that extends their extension. They have notifiers so others can write a plug-in that listens for events.
  • Jeremy talked about Omeka - http://omeka.org/ - a content management system for collections and narrative exhibitions. They describe it as Word Press for museums that is modeled around items.
  • Josh Greenberg talked about New York Public Library projects. See http://digitalgallery.nypl.org/nypldigital/index.cfm . He talked about Voice Thread that lets students or teachers to create presentations with audio. They are doing a lot with maps.
  • Doug Reside from MITH presented on Google 3D and then on AXE that lets you annotate all sorts of media. This is being added to Zotero.
  • Stéfan presented about Voyeur Tools. Working with Adam he added into the NiCHE web site a wordle to their API Workshops page.
  • Adam of the Library of Congress floated some ideas. The first is that the web makes a pretty good API all by itself. Linked data is a cool idea. They built a World Digital Library http://wdl.org . See also http://chroniclingamerica.loc.gov which tries to make newspaper data available. The LOC is committing themselves to the URIs for items and trying to provide clean URIs. Stable URIs meant they could be crawled and indexed which lead to greater use. Their HTML links are sensible so that people can figure out how to get, for example, the next issue. He raised issues about what we mean by "page". They try to use other ontologies that provide definitions and reference them. He doesn't like to talk about the semantic web, the LOC is just trying make sense of the things that they use. He concluded by pointing us to Tim Berners-Lee on Linked Data.

General Discussion

We broke into three groups. One having a general discussion, one doing coding, and one that I facilitated looking at a matchmaking to form clusters to actually make APIs work.

Other things

6 Ideas for Low Hanging Mashups that we could do

Lots of ideas are flowing for what can be done. Here are some of the easy ones I can think of:

  1. An integrated news feed for the digital humanities. Lots of projects have RSS feeds. Suppose we agreed on a common thesaurus of keywords (or just one general one like "General") which if used would allow someone to create a mashup of general news about projects in the field.
  2. Zotero mashups to analytical tools. Zotero has started down this path, but we need to help them by developing some example tools that demonstrate how Zotero can send items to a tool for analysis.
  3. Task Exchange. Can we develop a social research exchange site where people can post a need and others can volunteer to help. One could post jobs for which you are willing to pay or jobs for which you are willing to give credit. Would anyone offer to help? What motivation would there be for the volunteers?
  4. Academic Ads. Can we build something like Cultural Pundit for digital humanities projects and bloggers. The idea is that people would contribute space on their sites for "ads" from others (ads for a new issue of a journal, ads for conferences and so on). Those that contribute space could then post ads to show up on the spaces of others.
  5. Recipes for getting things done. Suppose tutorial recipes were structured so that they could be subsumed and reused by others. A recipe for doing X could be exposed so that others could weave it into their centre's help sheets using the tools available at their site. (Will Bamboo do this?)
  6. Five Cool Analytics for any web site.

Navigate

PmWiki

edit SideBar

Page last modified on October 21, 2009, at 07:49 PM - Powered by PmWiki

^