Hard problems of concept mapping

[elliotsayes]

This issue is more of an exploration of ideas to solve a hard problem, rather than a specific issue with the software. I hope that this is an acceptable place to talk about this.

Consider the following statement:

In the Digestive system of Humans, Acid chyme flows from the Stomach to the Small intestine (more specifically, the Duodenum) via the Pyloric sphincter.

All of the bolded statements are concepts (cotos), and the italicised flow is a process. My goal is to represent this information in cotoami, such that the relationships are represented on the graph view.

Starting with the following concept map, it shows the above concepts with a few topic cotos.

The next step is to try and represent the above statement.

Naive implementation

In this scenario the 'Acid chyme' coto is used as the base of relationships. There are obvious flaws in this approach. There would be a conflict if you wanted to describe a different process for another species, because their would be multiple fragmented processes stemming from the same coto.

Subject implementation

This scenario fixes the above problem by adding an additional coto that more accurately represents the subject of the statement. This works, but is somewhat awkward. The action flow is split into two relationships, each repeating the action name and specifying the direction.

Subject-Action implementation

This scenario couples the action with the subject, which avoids redundant double use of action. However, the coto becomes more specialised.

Hierarchical Subject-Action implementation

Same as above, but with an additional stage in the hierarchy. This is somewhat cumbersome to maintain, and is limited by virtue of the tree structure. It would be nice if there was an easy way to travel from 'Acid chyme flow in humans' coto to 'Acid chyme in humans' coto, but without having to set up a tree like shown. In other words, treat 'Acid chyme flow in humans' should be a combination of the concepts 'Acid chyme', 'Humans', and 'flow', which should be automatically a child of the concept pair 'Acid chyme' and 'Humans'. I suppose this functions somewhat like tags.

Action-oriented implementation

This is effectively uses the linking phrase flow as a coto, which other concepts can link to. This has the advantage of showing the process more naturally (the arrows representing the direction of flow). However, it is somewhat awkward to implement in the software in its current state.

Conclusion

I would say that none of these solutions are perfect, and I cannot think of the best way to complete this task using this software as it is. I invite anyone to offer suggestions for how you would do this, or if there is another possible feature that would allow this more elegantly.

[marubinotto]

Thanks for posting a very interesting issue with a great example!

This might not be the answer you're looking for, but it is an essential topic for Cotoami and I'd love to hear your thoughts about it.

I think there are no "perfect" models because any model will be obsolete when the context is changed. If you are to create a model taking into account all of the possible contexts, if that's possible, the model will become too abstract or complex to understand or use in actual situations.

So the problem is that how we should manage our knowledge base when our targets are always moving rather than static. That's one of the main themes in Cotoami.

The basic principle to tackle the problem would be continuous input and change of knowledge structure. When an input comes, you should put it into the structure in terms of what it means to you or your team in the current context. As a result, models should become personal or team-specific. That's how I proceed with the process in the "Brexit" example.

With that in mind, as for your "digestive system" example,

the coto becomes more specialised.

I think that would be no problem as long as "Acid chyme flow in humans" is important to you, or rather, in terms of continuous knowledge creation, it would be preferable to start with specifics.

There would be a conflict if you wanted to describe a different process for another species, because their would be multiple fragmented processes stemming from the same coto.

If you are thinking about a human's digestive system, you need to focus on that at first, avoiding premature generalization. You need to be skeptical about the existing categories in order to create your own categories: collecting specifics and gradually extracting concepts that matter to your context.

I understand there's a need for capturing the existing concepts or knowledge especially for educational purposes and that's what concept mapping is all about. But still, I think it would be fruitful to think knowledge creation this way in many of those situations.

I hope my explanation makes sense to you.

Apart from that, how we should describe dynamic processes in Cotoami would be an interesting topic to consider.

[elliotsayes]

Thank you for your response Daisuke. I understand you have thought about these sorts of problems a lot and I really appreciate you sharing your wisdom. I just wanted to touch on a couple of your points.

If you are to create a model taking into account all of the possible contexts, if that's possible, the model will become too abstract or complex to understand or use in actual situations.

So the problem is that how we should manage our knowledge base when our targets are always moving rather than static. That's one of the main themes in Cotoami.

This is a very interesting insight. I do appreciate that in the process of coming to understand a set of ideas or facts, you will (at least initially) not fully understand all of the abstractions. I very much admire the design philosophy behind cotoami, in that it takes this into account and facilitates incremental building of understanding, even from the first few ideas that pop into your head. I'm amazed at how much it can achieve with so few, but well thought-out, mechanisms.

However, I am also of the opinion that, as understanding grows, so should the ability to organize that understanding in more complex and nuanced ways. It can have the power to grow with the users, all the way from the most basic examples and patterns, towards total abstraction. It should make the ideal destination possible and the journey as easy as possible. My hope is that there should not be reason to switch to a more complex piece of software once the knowledge-base becomes sufficiently complex that it is no longer maintainable with the current tools.

My current feeling is that to do reach the ideal point, it would require additional mechanisms in the software. I am not sure what they would look like, and if they would inevitably break the simplicity of cotoami. Perhaps it is worth exploring anyway? An example of such a mechanism is the inheritance relationship. For example, Humans should inherit all attributes from Mammals and Primates, but Eye should not inherit attributes from Human (as that relationship is composition). This of course is borrowed from OOP principles.

I think that would be no problem as long as "Acid chyme flow in humans" is important to you, or rather, in terms of continuous knowledge creation, it would be preferable to start with specifics.

I suppose that the implication I was trying to give is that Acid chyme flow in humans is not such an important concept (at least, not on the same level of something like Acid chyme itself). The example statement is a simple fact that relates some of the preexisting concepts, and defines a (admittedly semantically complex) relationship between those concepts. The content of the coto itself provides not additional information, and can be derived from its context alone. Essentially it functions as a sort of base for a 'linking phrase' between many concepts. Linking phrases offer a useful convenience when the number of concepts involved is two and have directionality, but to my mind this only a subset of relationship semantics. I have little idea how you could generalize this convenience to other scenarios such as mine. Perhaps it is possible to borrow concepts or rules from natural language?

Please let me know your thoughts on these ideas. I know you have much experience in this space, and maybe my ideas sound naive to you, so please bear with me. My fear is that there is a fundamental trade-off between simplicity and powerful abstraction, but maybe both can be achieved with some careful thinking. What do you think?

[marubinotto]

Perhaps it is worth exploring anyway?

Yes, of course!

I understand your concern about the capability of expressing complex knowledge. But it would be also important to balance simplicity and expressiveness because Cotoami is aiming at smoothly connecting from chat-like lightweight note-taking to structuring complex knowledge.

An example of such a mechanism is the inheritance relationship.

I think the problem of OOP inheritance relationships would be its classic view of categories. Human cognition of categories is actually more fluid and flexible as it has been discussed in the prototype theory and family resemblance. It might be suitable for programming, but not for knowledge representation (and that's why I think object-oriented analysis has not been widely accepted).

In order to support the fluidity of categories, I've been experimenting with a concept of "vertical/horizontal relationships" in the recent versions of Cotoami. The main feature of it is the "linking phrases": https://github.com/cotoami/cotoami#linking-phrases

Why are the Linking Phrases feature so important? Concept mapping is a good way to demonstrate this feature, but an important difference is that Cotoami's linking phrases are optional. That means you should avoid annotating connections unless the relationships are obscure to you. Those obscure relationships are possibly valuable knowledge for you (since you didn't know them well before), and should be highlighted in your knowledge-base (that's why annotated connections are rendered so that they stand out). I personally call them Horizontal Relationships. - cotoami/README.md

How does it work to support the fluidity?

For example, if you are a table tennis fan, the connection below should be obvious:

[Table tennis] ----> [Jan-Ove Waldner]

But if you are not, there’s a need for some explanation:

[Table tennis] --(legendary player)--> [Jan-Ove Waldner]

I call the former a "vertical relationship" and the latter a "horizontal relationship". So whether a relationship is horizontal or vertical depends on your current knowledge and context.

It would be also important to note that the larger your knowledge-base becomes, the more difficult it'll be to follow vertical relationships in a graph. That would be one of the problems of the digestive system example if you are to cover the hierarchy of concepts thoroughly. And it is the problem I'm currently working on in the Cotoami development.

[elliotsayes]

Thanks Daisuke, I think I am in agreement with most of what you are saying.

I understand your concern about the capability of expressing complex knowledge. But it would be also important to balance simplicity and expressiveness because Cotoami is aiming at smoothly connecting from chat-like lightweight note-taking to structuring complex knowledge.

I agree with this. My hope is that Cotoami will be able to express complex knowledge without compromising on simplicity during early stages of learning. One of your tweets says:

Cotoami considers knowledge as ever-changing highlights or underlines you make when you intake information. In that sense, Cotoami is a learning tool rather than a modeling tool.

In some sense, I see learning as constructing a model - usually within your head, but in this case we can mirror that model in software. I think in early stages of learning, the model is ambiguous and simple and can be constructed well enough with simple paradigms. I think in it's current form Cotoami effectively facilitates this early stage, but my feeling is that it lacks paradigms to scale up to represent nuanced and complex understanding. The question is, what paradigms might these be?

It would be also important to note that the larger your knowledge-base becomes, the more difficult it'll be to follow vertical relationships in a graph. That would be one of the problems of the digestive system example if you are to cover the hierarchy of concepts thoroughly. And it is the problem I'm currently working on in the Cotoami development.

This is true. I would say it can also be difficult to follow horizontal relationships, if they become complicated enough.

[marubinotto]

In some sense, I see learning as constructing a model

That's true.

I've been thinking about what I wanted to say by the tweet. Any outputting tools inevitably involve some aspects of learning processes. Probably, the important thing is focus. In Cotoami, I want to focus on the process of producing structures rather than how we express our ideas structured in advance. I don't feel right about separating the early stages of learning from the whole process because it's a continuous process.

A model is not a planned goal, so I think ideally we should not have any predictions on it. As for Cotoami, we should not consider graphs as aimed goals. They are just snapshots of learning process.

my feeling is that it lacks paradigms to scale up to represent nuanced and complex understanding. The question is, what paradigms might these be?

Cotoami is just about connecting things, simple and sufficiently flexible to express any knowledge, but your concern is lack of ways to express specifics, right? I'm curious to know concrete cases where that could be a problem. Maybe you could elaborate on your "digestive system" example?

I would say it can also be difficult to follow horizontal relationships, if they become complicated enough.

You can control the number of horizontal relationships since linking phrases are optional. They are highlighted connections and should be changed as your learning progresses. While you should consider splitting a graph into cotonomas when it becomes too large to grasp, this highlighting is a way to deal with the complexity when the number of connections has increased. In such situations, vertical relationships become less important in a graph (that's why they are rendered in light-colored dashed line).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.