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.

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.” (http://www.jiscinfonet.ac.uk/InfoKits/creating-an-mle/mle-design/domain-models)

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 (http://www.e-framework.org/)

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 )

    Interactions:

    • 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