-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distinguish between "sources" and "concepts" #167
Comments
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. |
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. 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? 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: 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 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). 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.
The text was updated successfully, but these errors were encountered: