dyslucksia wrote: For a start, how silly it would look if Types were displayed in the Plex. Which gates would you use to show their connection, Parent, Child or Jump? None is appropriate.
You are correct, which is why it doesn't use either the Parent, Child or Jump gates. It uses the TYPE gate. Look at Harlan's statement:
Harlan wrote: ...there is a single set of thoughts and there are links between those thoughts that indicate parent/child/jump/type...
Type is just a specific gate to a Thought which has been configured as such. My assumption is that there is also a specific Tag gate (which just happens to link to the same location as the Parent gate, but it is not the parent gate) to link Thought objects as Tags.
dyslucksia wrote: Imagine a Brain with 300 Thoughts, at least 100 of one Type - how ridiculous and unnecessary it would be to display a Type with 100 child Thoughts hanging from it. And what would happen if there was one Supertype with two child Types, one with a linked Thought, shown in the Plex, and you tried to link the Thought to the other type as well, or to the Supertype? No wonder that Types are not shown as Thoughts in the Plex.
Hang on, you are getting ahead of topic at hand. Let's pretend for a minute that Types and Tags did not exist. The only options available in the plex are Parent/Child/Jump Thoughts. Would PB still be useful? Of course it would. You could manage your own hierarchy and ontology by simply creating manual links for any relationships you so desired. This is how I imagine most PB users start out anyway. Users should be competent enough to manage how many children they put under a particular parent.
So then Types and Tags are introduced. Now some of the Thoughts that I was using to define my ontology really aren't Thoughts in and of themselves, they are really just a categorization. So I create a Type for that category and start assigning it to some Thoughts and I get rid of that branch because it is just redundant of the classification that Types offer and I get to put a niffty little icon on all the Thoughts of that Type. But now I miss seeing those Thoughts grouped together in the plex. So I start using Tags... and so on.
If I litterally end up with hundreds of Thoughts as "children" (and I use that term loosely) of a Type, is it really the fault of the PB application or do I need to revise my ontology and create a better classification system and hierarchy? Let's step back into the PB world of no Types or Tags and pretend a user was complaining about having 100 Thoughts as children of a particular parent; what advise would you give them? Really the same argument could be made against the way you want keywords to show up in the instant search (like you describe here: http://websitetoolbox.com/tool/post/thebrain/vpost?id=3375669&trail=30). Even if there were a lage number of thoughts in a particular type, I could still find this useful in expanded view as a huge network map.
But let's say I do actually want 100 Thoughts all of the same Type and now my plex is so full I can't read anything. Now what? The situation you are describing could easily be managed with Filtered Views or Smart Thoughts. But now we are venturing beyond the scope of my question.
dyslucksia wrote: It's like saying a train is a form or transport, just like a motor car, but would you let a car drive along railway tracks or a train go down the main street (yeah, I've heard of Brno too)?
But if the thing you are wanting to accomplish is transport a large number of people to a destination where there are no railroad tracks, you could either have them all take the train only so far and then have a car drive back and forth from the depot to the destination with only a couple of people for each trip back and forth. Or you could scrap the idea of the two separate train and car entities and create a bus that does both, carries a large number of people and is not restricted to the railways of the train.
dyslucksia wrote: On the other hand, this revelation would make it all the easier to create yet another variety of Thought, Keyword, that would fit nicely into the gap between Types and Tags, as I proposed earlier.
True, but would there be any substantially different functionality? Could you not just enhance the Tag functionality to include your > "see also" instant search / instant activate specific thought?
Quote: 1. Thoughts are just Thoughts
2. Thought Types are just Thoughts
3. And my hypothesis is that Tags are just Thoughts as well.
Yes, no and no. Just because they live as neighbors in one big database doesn't make them clones.
I didn't say they were clones. But they are the same sort of objects, which means they could easily inherit the same functionality of the others.
zenrain wrote: As far as I can tell, there would be two benefits of implementing your suggestion. The first, duplicating the list of tags and types I don't consider a benefit. Both have different functionalities (which as you said, they will maintain with the combining), but due to the different functionalities, I may/do want to have different lists.
Yes and no. I can see your point that you may want different lists. But the functionalities are not entirely mutually exclusive. You can group thoughts by Type and you can group thoughts by Tag. However, Smart Thoughts would be the ultimate way to combine this functionality and still keep things separate as they are today.
zenrain wrote: The second would be it will show types in the plex, similar to tags. I think this would be very useful, but given most everything else would stay the same (besides duplicating thought and tag lists) I'm just not sure why we would have to merge types and tags to do it.
True, being able to display Types in the plex the way that Tags can would have some benefit. And again, if we just had Smart Thoughts, then all of this would be a wash anyway.