CategoryBoundaries

CategoryBoundaries refers here to a strategy for writing our ForwardIndex pages.

Specificly, it’s the idea of, on most every ForwardIndex, telling:

And, whenever possible, for the excluded ideas, telling where they should go instead.

For our first example, see: CategoryCommunication.

For our second example, see: CategoryHierarchy.

Motivation

When we talk about things, we want to do so with some memory of previous related conversations. We don’t want to repeat previous conversations, after all, and we want to link to the other pages whenever sensible. Further, there are other advantages to our understanding (unarticulated, so far) that come with having a map of what we have said about some subject.

So, in CommunityWiki, and many other wiki, we create categories. We put a category tag (link?) at the bottom of a page. The category tag points to related pages. This way, we can see the general context. (need link to page that describes category pages process.)

This works great for awhile, until we reach a significant density of concepts. At this point, subjects start to become confused. We need to clarify what words we’ll be using for our clumps of ideas. If we don’t, we’ll have poor maps of ideas, because cities that are in the US will be listed in Europe, and cities that are in Europe will be listed in the USA. Our goal is to find the context of our ideas. If the ideas are all found in the wrong contexts, we obviously have a problem.

You might think that we would always put an idea in it’s proper context. But, in practice, we find that this isn’t true. It’s true for a little while, but once you have hoards and hoards of ideas in place, it just doesn’t work anymore. “Is this CategoryCommunication, or CategoryDiscussion, or CategoryConflict, or CategoryWikiConflict, or CategoryDecisionMaking, or, …?” You can see how it can get confused, right? The lesson of IdeasLikeStarsAndSymphonies: from afar, we confuse ideas with one another.

So, to help resolve this all, we articulate our category boundaries.

We say: “This is what this category is for. This is what goes into it: X, Y, and Z.”

Just working by inclusion doesn’t work, though; You also need to have exclusion. Because, you’ll make mistakes, and interpret something overly broadly. So you need to be able to say, “Ah, but X3 doesn’t go here- X3 actually belongs over there.

That is, if there’s a there for there to be. If you’re just saying, “It doesn’t belong in here,” but can’t name where it goes to, than it just goes out into limbo, to be picked up some day in the future, if need be.

Discussion

In my notebook system, (ed : Dead link)there were pages called “Purpose & Principles,” or P&P for short.

They did exactly this: They said what a “subject” (the rough equivalent of a category, here) was about, what was on-topic, and what was off-topic. It pointed to neighbers, in case of confusion, so that you could put thoughts in the right place.

You can read the original- search the intra-subject architecture chapter (ed : DeadLink?)for the text “boundary of the subject”.

The P&P was created for exactly this problem, from exactly this motivation: Confusion of subjects.

When I was keeping track of my thoughts, I quickly discovered that my mind mis-attributed ideas to wrong categories. Or rather, it didn’t have the time to think in detail about where they should go. It just had a thought, assigned it to a “close enough” subject, and then let it go from there.

When placing thoughts to their proper location, I needed a system for segregating thoughts into their proper CategoryBins. So: P&P was born. It worked great, and I think it will work great here too.

One neat thing that comes from this is clarity. This is because you see the relationships between subjects.

I found that in most cases, seeing ideas in their context was more enlightening than the ideas themselves. Ideas in themselves can seem pretty obvious, once you’ve had them. But once you start integrating and organizing them, you see new things that you have never- that nobody has ever- seen before.

I firmly believe that most of us who are learned or skillful in some territory- we don’t really understand our understanding.

For example, I’m a programmer. I understand lots and lots of stuff about programming. I taught programming for free for 2 years, roughly 4-6 hours per week, every week. It was more an exercise in “attempting to rub off knowledge,” than it was a tactical or clear education process. This is not to say that it was worse than schooling; I mean to say: I believe this is how schooling works as well. That is, at all levels, I believe we do not understand our understanding. I believe that it is possible for us to understand our understanding, but that it requires a real work. Not only is it a real work, but it’s a real work that people have not even understood how to do. I think that exploration of mind maps is really just the very beginning of this real work. I believe that what we’re talking about here, and the social construction of knowledge artifacts (things like people working together on a wiki, or wikipedia, or even OpenSource software (integrated knowledge)) and the coming Futures:GraphRevolution are really where it’s at.

I look forward to one day pointing at a map of “what it is to be a programmer,” and simultaneously gaining some new insight into programming beyond what I know, fulfilling that map. Every time that I took my existing crowded ideas, and arranged them by following this process, the end result was deep understanding, clear new strategies, clear knowledge of where the boundaries of my understanding was (and where to go poking,) things like that. I see no reason why it should be any different with programming, life, everything we can think about.

The reason I believe these things are possible is because I did it on a personal level. And I see us now, here, doing exactly the things I was doing in my paper notebook, for the exact same reasons; I see no reason why the outcome should be significantly different.

Define external redirect: DeadLink

EditNearLinks: OpenSource

Languages: