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 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
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
We’ve been working on domain model visualisation in the ADoM project (led by University of Nottingham), so we’ve been wrestling with some of the issues you have identified here. Our current front runner is to use a combination of “narratives” that hold scenarios together and give context, with “characteristic scales” that allow us to capture the critical environmental factors.
As an example, we have a narrative for assessing applicants in a professional subject, using holistic methods, for a heavily selecting course in a multi-site environment. We hope that the narrative and characteristics can capture the richness and some of the variety of the domain.
It occurs to me that our approach is quite close to the ecological approach you have outlined here. I’m particularly keen to record the messier aspects of the domain, which are most important to practitioners, even if they cannot be readily captured in business models.
Pingback: Domain models and the ecological approach | John’s JISCCETIS blog
Hi Alan,
I’ve put some of my working notes on the similarities and differences between a domain model and the ecological approach in another post. I’m still trying to understand domain models though so I may be off track. It’ll be interesting to hear some more about your project.
cheers,
John
John
We’re using a definition of domain model that is close to Tom Franklin’s recent work for JISC “A High Level Domain Architecture for HE”. From Tom’s report the definition is:
“A domain model can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships. The domain model is created to
document the key concepts and the vocabulary of the system. The model displays the relationships among all major entities within the system and usually identifies their important methods and attributes (Wikipedia).”
I would slightly question the use of the term “system” in this definition, because there may not be a single clearly defined system involved, and perhaps even some stuff that isn’t actually system-like. We’re considering a ‘domain’ to be a specific area of interest or expertise, in our example, HE admissions. Domains can, I think, be at various levels of granularity; though it’s usually helpful to consider big chunks rather than fine detail.
Our work in ADoM is to develop a model for the HE admissions domain, and to develop a visualisation of this (a domain map), so that admissions practitioners can share their experiences, modify the model and suggest useful future (technological) developments in admissions. We’re gathering information from our primary project partners, University of Nottingham and Manchester Metropolitan University. We’re using Protege to hold the knowledge base and are currently working on a visualisation (a domain map) constructed by tweaking Protege’s HTML outputs and adding some of our own pages and diagrams.
Alan