[deepamehta-users] Thoughts about DeepaMehta

Jörg Richter jri at deepamehta.de
Sa Dez 1 05:39:15 CET 2012

Thank you, JuergeN, for the initial writeup of the philosophy page, Dennis, for starting the discussion, and, Matthias, for providing a demo map! All this triggered a lot of thoughts which I like to share with you.

DM is explicitly aimed to be all three at the same time:
1) A work environment for end users, notably knowledge workers, and workgroups
2) A modeling tool
3) An application development framework

Regarding 1) the mid-term aim is a combination of PIM/PKM/Groupware for handling email, webbrowsing, content creation (text, image, audio, video), contacts, and events. All in an unified environment where filing/search/retrieval, navigation/display and interlinking capabilities are provided at the base-level.

Regarding 2) and 3) DM can be used to model domain-specific content types and back them up with programmed logic.

Indeed, as Dennis said, JuergeN's philosophy page and most of the current website documentation focuses rather on 2) and 3) instead of 1). From my engineering point of view this reflects DM's state of affairs: DM is such a grand vision that there is no way to build 1) *before* 2) and 3). Of course here exists the danger for DM of an over-ambitious vaporware. To fight that danger we try to practice a co-evolutionary process where the platform and real world (contract) applications grow together. The DM community lounge is one stage where DM users (and contractors) showcase the developed DM applications.

About 2) Modeling: The DeepaMehta user is *not* required to have modeling skills.
The plan is that an out-of-the-box DM installation provides all the models and functionality required for the use case sketched out in 1). However, we see it as a great opportunity for the user to have an *integrated* modeling component. This provides the potential for bridging the gap between users and developers. Our hope is that this approach a) empowers the user or groups of users with heterogenous skills, and b) facilitates communication between e.g. a customer and a contractor.

Our aim is explicitly *not* to make every user a modeler. We are fully aware that modeling requires a certain inclination. A lot of people don't have it just like a lot of people have no inclination for e.g. poetry. But we see the modeling component as a *chance* for the inclined user. She might e.g. extend the music library model of his pure music-lover friend by custom fields and relationships, e.g. from who/where I was pointed to that artist? We think this form of empowerment reflects the sheer nature of the digital power -- and this form of empowerment is not provided by the majority of existing software platforms.

Regarding the learning curve: yes, when stepping from the content layer to the model layer there is a certain learning curve. DM tries to facilitate that step by 2 principles: a) An integrated environment. The modeler uses the same GUI and the same building blocks (Topics, Associations) already known from regular usage. b) Explorability: the inner structure of the DM standard model (and meta model!) is fully explorable by the user. She must not keep all concepts in her head but can visually explore how e.g. the standard Person model is constructed and can transfer this to her own use case.

IMHO, JuergeN's philosophy page is a good starting point for being extended by wider philosophical questions:

- What image of man-machine-system underlies the design of DM, and in particular its User Interface?

Look for example what Apple strives with Siri: There is the metaphor of a personal assistant, who is supposed to know everything. The user just needs to ask, and Siri will give the answer. The use of natural language suggests there *is* someone who I'm talking with. Similarly Google: they see the entire world as data, and if they manage to collect enough data an all-knowing entity will arise that can answer all your questions, even before you are aware of them. While the technical achievements of both, Apple and Google, are undoubtedly great the underlying image of their man-machine system seems to be: on one side is the all-knowing master and on the other the student who learns through questions. And that's it.

Personally, as a system designer, I feel very bad with that kind of an assistant metaphor as it a) degrades the human to an appendix of the machine and ignores hers own best capabilities, and b) blocks further exploitation of the digital power by setting the (research) agenda based on a questionable image.

An alternative image of a man-machine system is what J.C.R. Licklider describes in his "Man-Computer Symbioses". Man and computer lives in a symbiosis where each part contributes where she is good at. The machine is supposed to do the clerical work (search/retrieve/visualize data) to bring the user in the position to evaluate/recognize/think/create. This kind of setup requires the system designers to be aware of the particular capabilities of man (like perception, mental models, communication) and how they are functioning (J.C.R. Licklider is a pioneer in interactive computing *and* has a PhD in psychology).

What I like on the concept of Personal Knowledge Management (PKM) is that it starts where Apple Siri and Google ends. Today we have quick access to enough information. Now we need a computer platform that facilitates the *individual* with making sense of it.

Bret Victor, a contemporary system designer, describes what he is interesting in as building systems that facilitate
- To Learn -- changing his own mind
- To Create -- changing the world
- To Communicate -- changing other peoples minds

To provoke further discussion some more questions and statements:

- How do images and diagrams support the process of thought and remembrance?
	- What is "Visual Intelligence" / "Visual Thinking"
	- How do "Visual Queries" work?

- The relationship of the DM user and a Topicmap is like a painter and hers canvas.

- "Die allmähliche Verfertigung der Gedanken beim Reden" (Heinrich von Kleist).
	... beim Schreiben?
	... beim Malen?

- A Topic in DM is not characterized by its properties (there are none!) but by its relationships. ("MehtaGraph", https://github.com/jri/neo4j-mehtagraph)

- A Topic in DM represents the "Ding an sich" (Kant) and a "Ding für sich" at the same time.

- "The art of networked thinking consists in making complexity easier to handle and creating scope for new ideas" (Astrit Schmidt-Burkhardt: "Maciunas' Learning Machines")

- The collaborative creation of onthologies is a "Sprachspiel" (Wittgenstein).

- "We may, if we are lucky and mindful enough, learn to think together by building shared structures of meaning" (Janet H. Murray: "Inventing the Medium")


Mehr Informationen über die Mailingliste users