Open bryanph opened 6 years ago
This is an important issue! Heterogeneous world views abound. My view: it is not the task of an IT platform (Geist) (what I call "boundary infrastructure") to resolve world views, but, instead, to find ways to federate them. In so doing, and if facilitation of conversation is available, if there are resolutions to differences, they will be found. Using structured conversation, with typed nodes, e.g. question, answer, pro and con arguments, you facilitate conversation vastly more productive than linear chatrooms (like this issue list). You can revisit a claim when new evidence is found rather than just appending the new thought to the bottom of a list. Let's talk!
I know a website that does something like this: kialo
Enabling/supporting such a structure could be very useful for gathering and refining information and developing ideas. Having something like this as the backbone of an "information node" (concept?) would really add something to a knowledge base, imho. I am not perfectly sure what "concept" and "source" really mean in this context. Would concepts be what we have now, or something else? Also: would the differentiation be context sensitive? I mean: Would concepts and sources even differ structurally, or can a concept be a source at the same time? Like: Gene Mutation is a concept. But at the same time it is linked as a source for evolution?
But I do worry a little bit about fragmentation, which is the opposite of what I want a knowledge base to be.
I'm sorry I should define what I mean by "source" and "concept" in this case.
I see a source as anything that brings new information into the world. So this can be a book, a youtube video, a conference talk, a meeting, etc. These sources are in its turn reliant on other sources, creating a sort of network of sources.
A concept is basically just anything you can refer to (yes I know, that sounds ridiculous). So a concept is really just any abstract idea. A source is also a concept. For example, the bible is a book and therefore a source but we can also refer to it as a concept by for example comparing it to other religious texts.
So the idea of identifying a source in Geist is based on the idea that the organization of a source is irrelevant to the actual content (for example, the layout of chapters in a book is irrelevant to the information that is actually in the book). This would then hopefully allow us to focus more on the underlying concepts and ideas and represent the information in different formats (perhaps by combining it with other sources).
I hope this is a bit more clear, I'll try and draw some diagrams.
So, concepts would basically be what you use to make flowcharts, decision trees, hence hierarchy, while sources would be all the other stuff that relates to it in some way? Like: sources are the net of roots in the ground, and than, above it you carefully craft your structures\concepts that sometimes reference to this fundament?
As I understand it, their internal structure does not differ, right? Every node is basically identical besides the contents of their properties? So node A would have the the properties: IsConcept = true\false; HasSources = list[...]; IsSourceOf = list[...];
And how they are displayed is figured out from there?
Yay, diagrams! Shiny stuff. ^^
Coming from the topic maps community and mindset, I tend to think this: everything is a topic. I've met people who express particular, and varying distinctions between what they believe I mean when I say "topic" and they say "concept"; to me, everything is a topic, even the lowest, most abstract "concept" you can imagine. That includes relations between topics. A relation, e.g. this statement: Joe is employed by BigCompany -- "is employed by" -- the EmploymentRelationType -- is a topic. That's because a) it is representative of an event -- the act of becoming employed occurred in the past, b) a current relationship -- that of employment, and c) there are two actors: Joe and BigCompany. Moreover, it has a biography: dates, people, places, things, and so forth. And, finally, if it's in a topic map and not current, it can be the target, as in, actor, in another relationship which asserts something new about that relationship; it ended when Joe got fired. In that context, Bryan's "source" for the assertion that Joe got fired might be another topic/event: an email to that effect. A guess: perhaps the term "provenance" applies to "source" since, by definition, provenance deals with the history behind something, not necessarily the truth or veracity of any claim, just the origins of the claim itself: who, what, where, when of the information flows behind the claim. Note that if the source of any claim, say, about climate change, happens to be a blog post from a respected climatologist, it carries one set of weights; it, instead, the post is that of a not-well-known blogger who presents nothing but claims without evidence links, then it carries a different set of weights.
In that respect, the node attribute: isConcept = true/false; leaves me wondering...
I'll try to explain myself with a diagram. The blue nodes in the image above are "sources/provenances", they bring in new information but are not information themselves necessarily. What we want from a book (in this case "thinking, fast and slow") is the information that it contains obviously. The chapters and structure of the book just function to give the reader a narrative that introduces the content but has little significance in and of itself (it is the ideas that it introduces that are important right?).
So by marking the author's structure to introduce the concepts as "sources" we can distinguish between the actual concepts that the book introduces and the mere narrative structure that was used to introduce these concepts.
Now in the example above there is one thing unresolved. What if in chapter 15 the author again expands on "the anchoring effect" to give the reader more insight on this topic (perhaps it required the introduction of another concept first to understand this insight)?. When focussing on "the anchoring effect" in the UI we would like to see all information associated with it and where this information comes from (called sources here). However, this is now possible since the parent relation to the source that introduced this information is now available whilst before we didn't make this distinction. The question of how to do this intuitively then becomes a UI problem (which can be solved I think).
Now when summarizing what I have learned in this book I will most likely not use the narrative structure the author used to do this. This narrative structure was useful for introducing the information but does not really represent the final concept graph that we has formed whilst reading the book. This is something the author wanted to convey to you from the very beginning but was unable to do so because the author needed to introduce these concepts in an understandable manner (this is the art of writing).
So in the end you end up with multiple structural representations of ultimately the same information. The initial one is the information as it is presented in the book (useful for quoting a source of material) and the second one is a conceptual representation with the goal to understand the information (after the concepts were introduced).
And now another problem arises because surely Kahneman's book is not the only source in the world that has anything to say on these concepts. There are also other authors and therefore sources that might have something to add to this knowledge (or dispute it) and they might imply a different way of organizing this knowledge. So we need a way to initially approach information from its source and later approach the information from the concepts themselves; as a structure that we make to understand the concepts better (by abstracting and creating prototypes around these concepts as demonstrated in the previous comment).
Things might get even more hairy when authors have different conceptions of what the concepts exactly entail (they might use the same vocabulary for example to mention different things). This is where collaboration comes in. When working collaboratively it is very important that we are on "equal grounding" so to say. Our vocabulary and our conceptual understanding of the concepts for the given subject must match up or we will be talking alongside one another. So we have to agree which definitions we use within the subject, what vocabulary will be used for what, etc. This then feeds back again to the personal understanding of these concepts, because the understanding of the group then influences the personal understanding. We so to say, endorse a given concept structure and vocabulary and have a mutual agreement on them. The manipulation of these concept structures and vocabulary is then again something that the software can assist with.
So there are three possible actors in the system which influence each other in different ways.
This "endorsing" of knowledge is true both for groups and for users, and what the individual decides to endorse influences the group (potentially) and vice-versa.
So to sum this up: knowing where all the information surrounding these concepts originated from is key. It allows individuals and groups to agree on what definitions to use and what the individual's/group's collaborative mind believes. This then clears the way for new ideas to form (based on new external information or new information coming from within the system).
I think sources should be handled differently in the network. This way there would be a distinction between "concepts" and "sources" providing these concepts. This would also prepare Geist for eventually expanding into a collaborative knowledge base.
The kinds of features that would become possible if this distinction was made succesfully:
Underlying ideas
The main idea is that "sources" are simply containers of concepts in the context of the author. The underlying assumption is that different persons have different views about what a concept exactly entails.