Ecological Social Science

Most of us understand that human actions are a major influence on ecology and discussion of climate control, air pollution and other ecological topics of global and local importance should not be studied without considering the impact of humans on nature. Moran's book with the same title gives a very complete overview of this new subject: the combination of ecology and social sciences. The book reviews the differences in the viewpoints and methods; it mentions many of the studies carried out and the models they use.

I missed a substantive insight, how natural and social systems interact and I was surprised that the political influence is dealt with in about 4 pages on political economy and political ecology. The book forced me to think about my personal understanding of 'social ecology':

Taking global warming as the most pressing problem, I use from Ostrom the insight, that trust among participants is necessary. It is hard to see, how trust can be built, if the major players (U.S.A. and China) are not accepting rules to play by and one of them (U.S.A.) reserves for themselves the right to a much larger appropriation than the proportional share. It is hard to see how to establish rules acceptable to all with this start point.

It seems that we live in a world with one superpower. The developed countries, under U.S. leadership, try to maintain their high level of resource appropriation. I see cooperation with the elites in the lesser developed countries, elites, who maintain equally high level of resource utilization. I imagine a economic model with only 3 players: (1) the population in the developed countries, (2) the elites and (3) the poor populations in the lesser developed countries. If each player serves his own interest, development will not happen and resource utilization will remain skewed. The majority of the world population is in the third group (poor population in lesser developed countries), making for a dangerous, non-equilibrium situation.

Avoiding the Tragedy of the Commons" (Eleonore Ostrom: Governing the Commons)

The book by 2009 Nobel price laureate Eleonor Ostrom is one of the most positive books I have recently read; it gives rise to optimism: first, for the management of common resources - which include climate and natural habitats, and second, for a realistic and empirically grounded social science, producing applicable theories.

A commons was the communal pasture in a village, where every farmer could herd as much cattle as he wanted. More cows on the commons means more milk to the farmer, thus every farmer in his own best interest increased the number of cows, even though the aggregate action of all farmers will destroy the pasture and at the end all will lose. The effects of 'best self-interest action' by the individuals lead seemingly inevitably to a loss of the resource for all. This was described by Garrett Hardin as "The Tragedy of the Commons" (Science, Vol. 162, No. 3859 (December 13, 1968), pp. 1243-1248) and it is empirically observable in many instances - the fishing industry and groundwater pumping are current examples in the public eye.

Fortunately, not all Common Pool Resources (CPR) follow the this route to destruction; alpine meadows on several continents are managed communally for centuries, irrigation systems in many traditional communities have functioned for 'time immemorial'. Eleonor Ostrom has carefully collected empirical studies of CPR management which have worked and distilled a set of principles which help to avoid the tragedy:
1. clearly defined boundary of the resource and the community it serves,
2. congruence between the rules of using the resource (appropriation rules) and the contributions (provision rules),
3. institutions to allow collective decisions making,
4. monitoring the resource and its use,
5. sanctions for violation are graduated (going from very small to substantial for repeated offenders),
6. conflict-resolution mechanism,
7. the right of the community to organize is recognized by higher level authorities.

If the monitoring methods are simple and infractions easily observable by others, trust among participants is emerging. Ostrom analyzes cases where the 'tragedy was played out' and identifies as causes: (1) a lack of political will to enforce rules, (2) complex rules based on not easily observed facts, requiring a costly staff, which is likely not functioning, and (3) general interference of higher levels of government with the local people who depend on the resource for their livelihood.

The book is an example for a new kind of social science, avoiding hypothetical examples, which cannot exist in reality (e.g. perfect markets), but starting with careful empirical studies, collecting qualitative and not only quantitative figures to analyze institutions and to deduce conditions under which the tragedy can be avoided.

For GIscience, the book is relevant as it points out that (1) studies of mechanism of a CPR based on natural science only are not sufficient but the interaction with the community exploiting the resource must be included and (2) the cost of the management rules must be considered: information collection, processing and later enforcement of rules can be expensive and ruin in practice a theoretically nice solution.

An adventure in real world programming with 5 languages

I wanted to build a tool which I can use on my mobile (Android, HTC Desire); not finding a path to compile Haskell to anything executable on the mobile, I decided to follow advice from Building iPhone Apps with HTML, CSS, and JavaScript to build a web application using Haskell to construct the web server with Yesod .

What I did not expect was the number of un-coordinated and slightly different languages I had to learn. The project included a total of 5 different computer languages:
- Haskell, for programming the application,
- CouchDB (fortunately accessible from Haskell),
- javascript, to code the building of the index in couchDB,
- HTML, to describe the structure of the output,
- CSS, to describe the appearance of the web page.
Modern computer languages are quite similar, but differ in small ways: how do they deal with white space and what is white space? how to insert a comment? how to 'escape' a character, which has a particular meaning?

In the process I was reading documentation, and could not, for example, find an advanced, well structured description how to use HTML and CSS; the specification is readable, but does not indicate how the various features, which seemingly are producing the same effects, are best used, to avoid their quirks. Not only had I to learn the languages, but also to find specialized editors and tools for debugging (e.g. a Firefox extension to see what HTML and CSS arrived at the browser) - each tool with its own set of 'small differences'.

I succeeded, but two questions remain, one existential, one social:
- is it possible, to build a web application in a single language (specifically: in Haskell)?
- why do the 'real programmers' accept this sorry state of the world?

The first question leads to a testable hypothesis, which I hope to report about soon; the second reminds me of an observation of a social science researcher (I do not remember who it was), who pointed out that social institutions oscillate to a middle ground of complexity. If they are so simple that everybody can understand them, ingenuous people make them more complex; if they are so complex that nobody can use them any more, efforts to simplify are made. I guess, social systems need complexity to differentiate between amateurs and experts; complexity assures income to experts. This seems not only to apply to the legal system, with layers and tax advisers, but also to programmers?

Semantic Engineering - What is the Common Ground?

There are a number of people trying to make ontologies a practical tool for designers of information systems; many are engineers and use the term "semantic engineering", e.g. the title from a paper by Werner Kuhn to which he recently refered but I find other other papers with the same title. There is even a conference ICOSE 2011 - International Conference on Ontological and Semantic Engineering . I assume that not everybody uses the term in the same sense, but perhaps there is more agreement between the Semantic Web community and the GIScience ontology community in the use of the phrase.

Reading the paper by Kuhn triggered by his comments on my blog entry "Ontologies for what?" identified much commonality in his treatment and my thinking. Presentations by Helen Couclelis at GIScience 2008 (Ontology, Epistemology, Teleology: Triangulating Geographic Information Science) and recently in Las Navas identified some common grounds as well. Even reading the slides of a presentation by Pierre Levy in Banff 2007 I find similarities to Kuhn's paper.

I am wondering, how much we agree? Disagreement may result from fundamentally different philosophical positions, but more often, it is a difference in the use of terms. For example, Kuhn uses 'concept' to describe the triad 'symbol, thought, referent' and I used it in the blog to describe 'thought' only. Would it be possible, to start a wiki in which a small group of semantic engineers tries to establish a rational, agreed base for acceptable and necessary assumptions (ontological commitments) and terminology. I hope there is more commonality hidden behind confused terminology.


For a very different use of the term "Semantic Engineering" read "American Thinker" on the "war on words" !

Applications on a mobile device

In my effort to study the ontology of space, time and persons in my life and how to organize it in a better Personal Information Manager, I want to build a system I can use to test the ontology to gradually improve it. I believe that only ontologies which are actually used can teach us anything about ontology design.

Therefore, I need a method to build applications on the mobile design in a high level language such that I can derive the code from a formally described ontology, preferably Haskell, which reveals structure of the program and does not force programming in particular ways. Simply: I need a Haskell compiler producing code executable on the mobile, because only if it is executing on the mobile and the data are synced, the application is available even if not connected to the Internet.

There are project to compile Haskell to JavaScript, which can be executed in most browsers on the mobile and small server programs running in a mobile exists. Unfortunately, neither of the JavaScript project is currently usable. They are often based on the York Haskell Compiler (yhc), which seems abandoned. Other projects are 'proof of concept' and to make them usable is beyond what I am prepared to do. It will take some time, before I can compile Haskell and run it on the mobile.

Second best:

Use another language, e.g. JavaScript, lua or python which execute on an Android mobile. I fear this will detract from identify the ontology, ontological issues obfuscated by the particulars of the language. I briefly looked at OCaml, a functional language close to Haskell, but the code read as text was quite misleading ("ignore" all over the place - my brain follows the advice and ignores the rest of the line...).

Restrict the application development to make it usable only when connected to the Internet; then I can write in Haskell and hopefully drive the code from the ontology - as much as possible from a formal description of the ontology deriving the code automatically. Later, the code can be hand-translated to a language executable on the mobile (today, I would probably use Lua) and run there.

I want a better Personal Information Manager!

I have a mobile phone and it could be used for keeping track of the phone numbers and addresses of my contacts, my appointments and the things I have to do. Unfortunately, it is not quite as usable as the good old calender I used 15 years ago; the companies that produce paper organizers are still in business and perhaps I should get one again!

What are the issues?

Contacts: Initially, on my first Nokia phone, only phone numbers with a short name were stored. On the iPhone i managed to have two (or more) different lists on the phone and in my different mail accounts. They are all stored in my gmail account and sync works; on my Android phone it is really fully automatic; all my contacts were available, minutes after I switched the phone on for the first time! Open issues are:
- the mobile phone interface is not suitable to select among a large number of contacts; HTC Sense uses a T9 input system which works quite well, as long as I know a word in the contact.
- there is only one type of contact: what is the first name of a company? how to register a person in a company for whom i do not know the first name? obviously several types of contacts should be offered.

Notes: My electronic notes are as disparately distributed over many systems as my paper notes on my desks. Tomboy, using couchDB, syncs nicely all notes on my computers, but not on my mobile phone! Notes should link to other parts of my life.

Calender: The reason for having an electronic PIM is mostly that others, especially my secretary, has access to my calender and can enter appointments for me. I am not fond of the Google calender interface, but it syncs with my phone and produces alarms on midnight for 'all day events'...

Tasks: The task manager GTask, which I use on the Android, has a usable interface and syncs with the tasks in my Google calender, where the interface is barely usable. Not connected to anything else.

In brief:
- synchronization is an issue, especially if I am not connected to the Internet, which is the case whenever I am outside of Austria (data roaming is a financial risk in Europe!)

- user interface

- linkages between the items and other items i have to collect: expenses, photos, mail, folders related to the tasks I work on; there are weak links between the parts, but much more exists.

- persons and time are organizing principles, but location is equally dominating my life: I am always at one place and interact with people.

In one sentences: the ontology of the information that should go into the Personal Information Manager is not properly designed; it is a "bad" ontology, because it does not fit my reality!

Bloat or "as simple as possible, but not simpler"

Most software tools grow over time, only a small number stays the same. These are not increase in functionality, because they have already all what is needed; they are perfect. What is the receipt to achieve that?

In my own work I see the following pattern which leads to bloat: underestimating complexity and building something too simple. The pattern, once recognized, may lead to improved designs, such that software bloat can be avoided. Here two examples:

I tried to build a tool to automate the construction of graphical user interfaces from ontology and I included facilities for conversion between the screen representation and the representation in the application program. Different applications had different requirements for this conversion and the functionality grew ...
What was wrong? the complexity of the conversion requires a full programming language and I was, step by step and functionality by functionality inventing my own. Bad move!
What can be done? have the part which converts between GUI and application written in an ordinary programming language (in my case, Haskell) and remove all functionality which can be provided in the conversion functions written in the general programming language. - Progress: the tool becomes smaller and simpler!

I found the same approach in couchDB: parts, where complexity of the application comes in, are programmed in a programming language (e.g. views - compare with the complexity of special languages for report generation of old). CouchDB just manages the code (in javascript - a nice functional programming language!).

Bloat occurs slowly if we try to build something that is too simple, and then realize that a bit of functionality here and a bit of functionality there must be added and before we see it, we have BLOAT. It is a sign of not factoring out complexity in parts where it can be handled with the ordinary programming language and can be avoided in many cases.