Ecological modelling for repositories: an overview

[copy of my post from the RRT Team blog]

Introductory Report released

We’re pleased to announce the release of the final version of RRT’s introductory report:

An ecological approach to repository and service interactions .

In the report we examine the idea that ecology can usefully serve as a metaphor (or source of metaphors) to help articulate the complex contexts which digital libraries, repositories, and related services operate in.

Many problem-solving tools focus on one dimension of a context such as system architecture or business process. In the report we suggest that prior to using such problem-solving tools it is essential to have a wider view of the local context and to understand and be able to communicate how human interactions, system interactions, and human/machine interactions relate. Ecology offers one metaphor to view such a discussion, and shape how these interactions are analysed and considered.

The report is available from .

With this milestone it seems appropriate to also mention other work related to this report.

Ariadne article:

A Bug’s Life?: How Metaphors from Ecology Can Articulate the Messy Details of Repository Interactions
R. John Robertson, Mahendra Mahey, Phil Barker.

Case Studies

Metadata in an Ecosystem of Presentation Dissemination
R. John Robertson, Phil Barker, Mahendra Mahey, internet gambling Poster at DC2008

3 more case studies are underway.

Upcoming CRIG unConference

At the end of this week JISC’s Common Repositories Interfaces Group (CRIG) are holding a two day meeting to look at the key scenarios affecting repository interfaces.

Our discussions for the two days are going to build on a series of teleconferences organised by the CRIG support project – WoCRIG which have just been podcast. I’m both excited about this meeting and a little nervous.

I think that the support project are doing a good job of stirring us up to move forward the work of CRIG and helping us engage with and shape the next stages of repository interface interoperability. For the next stage of this work, this meeting, they’ve organised an unConference. Two days of informal thinking, discussing, and getting at the core of the interoperability issues related to repositories. I’m looking forward to it for what I know I’ll learn, for the chance to contribute, and for the chance to actually just have time to sit down and talk about these things.

The nervousness on my part comes from the unknown – I’ve never been to an unConference before and although the idea is good – to have discussions about what people want to talk about and to cut out the fairly predictable presentation part of a meeting and so to get at the eureka moments that usually happen alongside but not actually in conferences – I’m aware of how much, for me, those eureka moments come along because I’ve been sitting for extended periods of time for my mind to go off at tangents while half listening to a presentation which may or may not be relevant to my thoughts.

Anyway I guess it’s a bit like a codebash for ideas – and that’s no bad thing.

Domain models and the ecological approach

This a more focused brief discussion to follow up my last post about different approaches to modeling. It attempts to understand some of the similarities and differences between a domain modeling approach and an ecological approach.

Thoughts so far:

  1. Like a domain model an ecological view is concerned with more than the technical issues and interfaces
  2. A domain model is usually at a given large scale. In UK terms often the information environment level (parallel to the ecosystem level). An ecological view, on the other hand, can be at different levels. The size of a domain is somewhat arguable but (AFAIK) within the eFramework the domain is taken as the UK (or other given country).
  3. A domain model is more like what Les is getting at in terms of an ontology. It’s trying to agree a set of (abstracted) terms to represent all of the activity in a particular area. An ecological view is looking at a slice of that activity in a particular setting for particular purpose. However, I need to think this through a bit more.
  4. From a project’s point of view. if we treat the project as a book it may be a bit like the difference between classifying it (putting it in a domain model) and writing an abstract of it (creating an ecological model).
  5. From a high level point of view a domain model agrees categories of everything that’s going on; an ecological view (selectively) puts entities, interactions, and influences into a picture/ story.

Recent developments in the repository ecology work

A brief update on the progress of the repository ecology work. We’ll be revising the draft report shortly but here’s an overview of what else is going on with this work.

ECDL2007 Workshop

We held a workshop in conjunction with this year’s ECDL conference (workshop home page ). I’ll return to some of the presentations and outcomes of the workshop in another post but, in summary, the workshop went really well. The participants understood the ideas being presented and I think that everyone (whether or not they agreed with the ideas presented) had a thought-provoking day. Thank you to all of the speakers and other participants.

There were some useful critiques of particular aspects of the approach, including: a concern that the distinctions between entities and species were unclear (particularly when mentally translated into other languages); an observation that the approach could complement (rather than conflict) with newer approaches to the development of architectures; and a call to provide some more structured guidance about how to represent ecological views or models.

The workshop affirmed that there is something in this approach and it’s emphasis on articulating messy particularity that isn’t currently being covered by other efforts. It reinforced our feeling that this is more of a communication, planning, and management approach than a more formal (mathematical/systems) modeling approach.

JISCCETIS Conference

Next week, we’re going to be holding a workshop on the repository ecology work at the JISCCETIS conference. The session, being organized by Phil Barker and Lorna Campbell, will complement the ECDL workshop, and further shape the development of this work.

Spanish Repository Working Group: La ecología de los repositorios institucionales: Interacción entre sociedad, producción científica y acceso a la información

In December, I’ll be presenting at the Spanish Repository Working Group’s conference. They’ve chosen the theme of ecological approaches for their annual meeting this year. I’m not sure how much of the conference I’ll be able to follow at the time, but am looking forward to the opportunity.

Ontologies, domain models, use cases, and the ecological approach (part 1)

Or: a Friday afternoon study of poker.

In an attempt to make some more sense of how the ecological view fits with some other key ideas in the repository space here are some different views on a game of poker. I hope that taking a non-repository related example should force a clearer articulation. When time permits I’ll provide a repository-based example as a precursor to including it in the revised ecology report. This is example is tentative and may not yet be balanced. It’s trying to capture the intent of each of these approaches and is a bit fuzzy in some of the details.

A brief overview of what I think the the relations between the below type of model might be:

An ecological approach in relation to other approaches

An ontology-based model

Purpose of this view.

An ontology is used to describe an event in abstract ‘universal’ terms. This can be at varied levels of detail. Such an approach can support greater machine processing of the event and consequently richer software tools. ‘Weaker’ forms of ontology for human use, as found in classification schemes aim to identify commonalities and fit a particular event or concept into a bigger picture.

Ontological-driven example

An ontology would make statements about the game, locating it within a structured set of information. It would do this to create a universal model of the particular event or to locate the particular event within a larger framework. It might try to make statements to represent the following information.

Type of activity = Social activities > games > card games > multi-player card games > poker > Texas Hold’Em
Occurrence = Friday Repetition = Weekly
Players= Bill, Jake, Jim, Mike
Rules= Texas Hold’Em [number of cards, no of rounds, priority of hands, etc.]

It might add information about the location of the game (location=Mike’s house), the probability of drawing particular cards or hands, the probability of a given player turning up (player participation=0.7). It might be attempting to capture the detail considered necessary to allow a simulation of the game or it might just be attempting to describe in detail an event using agreed terms.

A Use Case model

Purpose of this view.

A Use Case presents a view of an interaction between an actor and a system. Describing how the actor uses the system to accomplish a goal. It is intended to be abstract/ not implementation specific. It is frequently used to support the design of systems or model business processes.

An example use case.

In the poker example, the use case would probably be focused on one player improving their game.

Player A observes the behaviour of Player B, C , and D. Player A tests when the other players bluff or fold. They note which players rarely bluff and who folds frequently. Player A changes their style as a result.

A Scenario-based model

Purpose of this view.

A Scenario is an instantiation of a use case or an aspect of it (conversely a use case is an abstraction of a scenario). Its purpose is to provide a common example to allow discussion of an issue among a varied group of stakeholders.

An example scenario.

Player A wants to win more often at Poker. He observes that player D rarely bluffs. Player A changes his style so that they fold against D unless they have a three of a kind or higher.

A domain model

Purpose of this view

“Domain models bridge the gap between the analysis of requirements (x-ref) and the production of design specifications. A domain model represents the common understanding of a key concept in the organisation.” (

Domain models present an agreed view a domain; this allows specified services to be presented in a way that allows them to be understood across that domain. Currently most domains are articulated at a national / subject level.

An example domain model

This is a trickier example ..

If we regard our game of poker as a service, it might exist as a concept in a domain model which provided a common understanding of Friday night social activities; or within a domain model of card games.

If on the other hand we took the game as the domain, we might begin to approach an ontology through agreeing names for the players, the games, its rules, and location (taking it at this level as a domain raises some granularity issues – but these are paralleled by the issues of trying to create a domain model of a repository).

A Service Usage Model

Purpose of this view

  • SUMs detail combinations of different services required to create applications for institutional use
  • SUMs are blueprints that lead to good practice
  • SUMs link business processes and policies with the technologies required for implementation
  • SUMs are an ideal mechanism by which institutions can publish details of their work to the wider community
  • SUMs demonstrate how other institutions have solved similar problems (

An example SUM

Again not entirely sure about this example and the below is obviously not a SUM (being about 6 pages too short) but an attempt to capture what a SUM would address.

An example SUM might set out the rules of Texas Hold’Em, it might also articulate some of the dynamics of the interactions between the players as part of the the business processes the services (the game rules) support.

An ecological approach

Purpose of this view

An ecological approach provides a selective view or presentation of particular habitat or movement of resources to explain, analyze, or manage that habitat or resource. It aims to

  • Articulate the human alongside the technical
  • Articulate the complexity and messiness
  • Support better communication and management
  • An ecological example

    What makes this game of poker thrive? What would make it better?

    Entities (& Species):

    • Bill, Jake, Jim, Mike (Players/ People)
    • This game of Texas Hold’Em (Poker games/ games of Texas Hold’Em )


    • between players: conversations; established friendships
    • between players and the game: bluffing, calling, drawing, raising, dealing

    Environmental Factors:

    • Jim’s wife’s health (affects his presence (creates the probability 0.7) – indirectly affects the dynamic of the game)
    • Rules of poker (a change in the global rules would affect the game)
    • popularity of Texas Hold’em on TV (how likely they are to play this type of game; how likely they are to attract other players)

    Habitat issues:

    • background music (does it help/ hinder different players)
    • presence of mirrors in room (their removal reduces the possibility of accidental cheating)

    Resource tracking issues:

    • movement of cards
    • movement of chips

    Friday night poker ecology