IT Infrastructure for the Digital Humanities Observatory
•Download as PPT, PDF•
0 likes•331 views
The document discusses building an infrastructure to support national collaboration in Ireland through information technology. It proposes creating a community portal, a database of research projects, and a demonstration repository. It recommends strategies like using open source software, rapid application development, partnering with other Irish digital initiatives, and employing object-oriented design patterns to integrate tools for multiple uses cases and skill levels. The goal is to develop flexible infrastructure that can accommodate new knowledge and support collaboration, research, and scholarly communication.
![Information technology provision ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to IT Infrastructure for the Digital Humanities Observatory
Similar to IT Infrastructure for the Digital Humanities Observatory (20)
Recently uploaded
Recently uploaded (20)
IT Infrastructure for the Digital Humanities Observatory
- 1. Building a National Collaboratory - Information Technology Infrastructure Don Gourley IT Manager, Digital Humanities Observatory
- 6. Strategy: build on open source software
- 10. Strategy: integrate tools for multiple use cases & skill sets
Editor's Notes
- Provision of IT services is prominently mentioned in the original project proposal. But it is a little short on specifics….
- … but that is a good thing, it lets us focus the infrastructure on the services that we think most critical for enabling collaboration: Re-use of e-resources Integration of our infrastructure with existing systems used by scholars/researchers Agile infrastructure that is not obsolete before it is implemented.
- Specific deliverables defined…with a focus on encouraging, supporting & sustaining collaboration: Portal: Rather than just being a door to resources, emphasize the community aspects of the portal web site Register: Rather than taking a snapshot of current research projects, build a dynamic web site where you can find out not only what colleagues are doing, but how Repository: Rather than try to build a full featured repository and insist partners use it, explore what repository services they want and adapt to them We came up with this demonstration repository concept when it became clear that our HSIS partners had a wide range of needs and expectations and we would not have time to in our funding timeframe to build all the features of an access and preservation repository that may or may not be used by our partners. In this context, the recent D-Lib article by William Arms & Colleagues: “Escience in Practice: lessons from the Cornell web lab” resonated. The first principle is “build a laboratory, then a library”…we are building the laboratory, while pursuing opportunities to fund and sustain the archive repository in the future.
- There are many issues and risks in building this infrastructure, such as resource limitations, scope definition, and sustainability. We are adopting various strategies to minimze these risks and leverage, apply, and integrate existing work.
- Typical open source software stack Portal: built on Drupal -- community-oriented, flexible & sustainable -- hosted at HEAnet DRAPIer: built on Drupal -- originally conceived as a standalone db application -- mapped easily to the same well-supported / sustainable OSS stack Demo Repository: built on FEDORA -- only solution with broad community support and flexibility to meet our potential requirements This may seem unimportant or obvious, but in the context of a limited term project these choices are critical to sustainability. Sustainability is of primary concern to the DHO, but means something a little different in the context of IT infrastructure. As with digital preservation, you can’t tie sustainability too tightly to the organization’s survival. You need to think in terms of “exit strategies” and “hand-offs”. Drupal/PHP, for example, would not be my first choice from my background as a programmer and system architect…PHP is really a mess of a programming language, and Drupal helps somewhat but as a framework it is still idiosyncratic , not e.g. MVC. But the fact that there are so many people with PHP skills and so many hosting sites that support Drupal means you can be pretty confident that the IT infrastructure can be maintained even if the DHO cannot.
- In order to customize and integrate DHO resources with the OSS stack, we are embracing the Agile perspective on systems development. In particular, we don’t believe we can successfully apply engineering-based predictive planning and specification processes for building this kind of IT infrastructure. We need an adaptive process that incorporates constant and immediate feedback into the design/implementation. We are employing RAD, which involves iterative development and the construction of prototypes. The final bullet point is perhaps the most important…that success is measured by the utility, robustness and sustainability of the systems we deploy, not by how well we met some arbitrary, misguided and probably obsolete requirements specified at the beginning of the project.
- Partnering is always a good strategy for addressing resource and interoperability issues. The DHO repository, in particular, is playing both sides of this game. We are fortunate to be working with the HPC/Grid community in Ireland who are eager (as they are in many other countries) to engage the humanities and arts …we are serving as a demonstrator project for the national data store project and in return are getting some critical computing resources for our work…esp. important for us as we are not based in a HEI with all the basic IT services it would provide. In turn, we are using partner projects as demonstrators for the DHO repository. We get use cases, metadata and e-resources and they get in return the kinds of services they need. Their needs vary widely. For example, within the Academy the projects are looking to us for all the technical support required to create, manage, publish and preserve resources. The AFF research institute, at the other extreme, has (as we have seen in presentations here) their own technically advanced infrastructure, but they fully understand this concept of a national collaboratory and are interested in working with us to explore ways to federate our resources.
- Danger of basing our infrastructure design on the limited use cases we derive from the demonstrator projects is that the collections become sequestered within structural ‘silos’ accommodating the needs of particular presentations or projects. Even with a common repository, if we only design to specific use cases the content is effectively silo’ed and not be interoperable. We would rather, as we heard last night, “err toward openness, reusability and generalizability.” Fortunately, there are mature and well-tested design patterns that come out of the object oriented programming community to build extensibility and flexibility into software systems. Even though most of the OSS stack we employ…Drupal, PHP, etc… is not strictly-speaking object oriented, we can still follow these patterns to mimic things like class inheritance and data encapsulation. For example, Fedora is not really object oriented in the programming sense. It is obviously DO-oriented, but it doesn’t support inheritance for example. But by applying those concepts to our content models, we can re-use and extend the models we build for specific use cases in new contexts.
- Finally, we have a strategy for balancing the priorities of various projects with those of the larger community and the concept of the collaboratory. Scholars, researchers and doctoral students are understandably most concerned with producing and publishing the outputs of their work. Our national collaboratory is prioritizing common, standardized ways of formatting, encoding and storing the data and metadata. We are addressing our priorities with a common repository, with the content available through a standard interface in the DHO portal. But we are integrating the repository with a variety of tools for publishing, visualising and analysing e-resources. These tools are targeted to a range of skill sets and needs. Drupal, for example, provides a number of content management features that can be configured by non-programmers. We have already built a simple tool for transcribing and reviewing audio recordings using the workflow module. We are talking to the SEASR folks about using their infrastructure, which is also aimed at multiple target users and skill levels, to create more complex data-oriented workflows to identify, e.g, named entity references that can then be ingested back into the repository. And we intend to hook the content up to any of the various viz tools that are being developed that a partner project wants to use to present their research. This way they get their fancy web site, which may look like a silo but is interconnected with other resources through the repository and portal.