We propose to use the ecology metaphor to describe and explore some issues raised through the PerX project . This project developed a pilot service providing resource discovery across a series of repositories of interest to the engineering learning and research communities. The fundamental use case behind PerX is that an Engineer who requires information should be able to perform a search across a selected range of data providers and the results should direct him or her to a relevant information resource. The distributed architecture involved in building such a service can easily be described using the JISC Information Environment Architecture : the PerX service is an aggregator in the fusion layer, it has a user interface provided in the presentation layer, and cross-searches information about resources held by several data providers in the provision layer. In the Information Environment Architecture view of PerX, the nature of the content provider services and how to search them is known because of data provided by a service registry, which is part of the shared infrastructure. This is shown schematically in the central part of figure 1.
The actual experience of setting up and maintaining links between PerX and data providers has been described (here, and here), and was critically dependent on many more resources and factors than are shown in the Architectural view. Typically addition of a new data provider involved the PerX service manager gathering information from the wider community of information specialists, from the data provider’s website and crucially from a data provider service manager: someone with the authority and/or expertise to commit to providing a data feed under suitable conditions.
We believe that the interactions involved in setting up and maintaining a cross search aggregation service may be modelled as a “habitat” in the repository ecology, and have attempted to sketch some of these interactions in figure 1. We make the following observations relating to this approach:

• the architectural view is at the centre of our ecological view. The ecological view supplements the architecture: it highlights crucial interactions that are out of scope for a technical architecture, and has the potential to show where the architecture fails to support the information flow required by a service.
• It would be of great benefit to obtain more detail on the precise nature of the information obtained by the PerX service manager from each of the available sources, and whether necessary interactions are in place for this information to be supplied via the Service Registry in the shared infrastructure.
• Organizations acting as data providers have an internal structure that may be modelled as a community. Within this there will be factors that may hinder the interactions required for the PerX habitat to function smoothly. These may include competition (a biotic factor) from other services that offer resource discovery, for example other equivalents to PerX (engagement in other habitats) or a policy of preferring use of their own resource discovery tools over facilitating indirect resource discovery.
• “Abiotic” factors such as policy and the consequent flow of funding may affect the whole habitat by, for example, not providing enough resource to nurture the “soft” elements such as a functioning information community. The ecological view has value in surfacing these elements of the ecology, helping to explain their value, and thus providing a means of securing support for them.
• Service managers may be a keystone species. There are certainly cases where no service manager emerged from the mists of the data provider’s community, and achieving a cross-search in these cases was problematic.

We hope to be able to expand on these and other observations during the workshop. If the ecology approach is to meet its potential as a communication tool, then it is important that we all speak the same language when employ it: we hope that attendance at this workshop will be important in establishing this language.

Figure 1.
Entities and interactions in the PerX cross-search habitat. An engineer uses the PerX user interface to perform a cross search of selected data providers in order to find information. The schematics in the centre of the diagram show the distributed architecture of data provision, fusion (the aggregator), and presentation the user interface), with a shared service registry which (in theory) can be used obtain information about the available data providers and how to interface with them. Around this we show the other elements at play in the habitat which were required in order set up the cross-search: a community supporting Information Professionals that provided information about which data providers were relevant and a service manager at each data-provider who provided information specific to that service.

Ecology is an approach to studying a complex mess of interacting things each with its own aims (or no aims), each mutually dependent on the things with which it interacts. I think this far better describes the field that we want to study than some other approaches. For example, an architecture can provide you with a plan of something that you want to build, but it’s often not a good approach to describing what you actually have. This is quoted in Davenport:

Since we never fully implement our models, we never have a useful map of the structure and location of our current information.

An ecological study can be broad and sweeping covering a vast area, like the Russian Steppes or Amazon rain forest, or focus right down on a single pond or tree in great detail, while still recognizing that the system being studied is connected to other systems that are not being studied but are still important. I think the idea of choosing a level of granularity for a study while not isolating what you study from the wider system is a strong one.

In ecology the things being studied are divided into species, which seems to match with the approach of considering different types of service and roles of player in an information environment. One approach to ecology is to look at the role of one species in an ecosystem, and the role it plays in interacting with other species (e.g. do any other species depend on the way species being studied distributes resources). I think this is one way in which our repository ecology study can be seen (though perhaps repositories represent a genus rather than a species, since there are so many different types of repository each with their own characteristics).

Two species-related concepts from ecology seem to resonate with studying information environments: firstly a healthy ecosystem requires a diversity of species; secondly some species are more important than others (e.g. bears in distributing nutrients around forest environments) even when they are not particularly abundant, these are known as keystone species.

Ecology recognizes that the systems it studies change: populations vary number and age-profile, species adapt and evolve, the system as a whole can react (positively or negatively) to the introduction of a new species or other change in environment. Our funders are keen that we remember that we should study repository ecology from the point of view of gardeners (or maybe farmers, but hopefully sustainable, organic ones) trying to produce something, rather than as conservationists trying to maintain the status quo.

Location is important in ecology, with concepts such as habitat and niche. This is useful when gathering information from people who interact with information systems, since most informants will be able to tell you about what happens in the place they occupy in the big scheme of things (running an institutional repository, using and creating learning resources, and so on) without needing to take a view on the bigger picture.

Also on the theme of gathering information about an information environment from the players in it, I think it might help that “ecology” has rather positive connotations for most people. Think about the alternative approach of going to someone and saying that you would like to talk to them about their role in “The System”, even worse “The New System” we are going to build for you to work in. Well, such an approach wouldn’t encourage me to cooperate .

OK, there’s a few thoughts on why I like the ecology metaphor, the work being done by my colleagues in the repository Research Team is looking at how to map it to information systems: what exactly is the equivalent of a species or a habitat? How do you describe their interactions? We also need to decide whether what we’re doing really follows on from the previous Information Ecology work or are we picking up the metaphor afresh. We’re going to try out a couple of case studies applying it (one at this year’s JISC CETIS conference in November). If you’re interested in more of the previous work we’re looking at, we’re tagging resources on our del.cio.us account as InformationEcology.

Refs:
1. Nardi, B. A., & O’Day, V. (2000). Information ecologies: using technology with heart. Cambridge, Mass: MIT.
Wikipedia Book Sources, WorldCat, Amazon.co.uk

2. Davenport, T. H., & Prusak, L. (1997). Information ecology: mastering the information and knowledge environment. New York: Oxford University Press.
Wikipedia Book Sources, WorldCat, Amazon.co.uk

Technorati Profile