twospoons

This is open book so please feel free to review these threads for background and context (cliff notes quoted below):

http://forums.thebrain.com/tool/post/thebrain/vpost?id=1809070
http://forums.thebrain.com/tool/post/thebrain/vpost?id=3110346
http://forums.thebrain.com/tool/post/thebrain/vpost?id=3345084

Harlan wrote:
Types are used to define what a thought is - to the exclusion of all other types.

Tags on the other hand are used to define properties of a thought and a thought may have many tags.

Since a thought may have only one type, types are used for inheritable properties, such as icon, color, and label (plus more planned in the future).

Tags cannot be used to define these properties since they are singular (a thought can only have one color for instance).

For beginners, tags are probably easier to use and understand since they are more flexible and similar to what you may have seen in other applications.

Types on the other hand offer a richer classification scheme and more power due to their inheritance.

Think of it this way:

Types (and supertypes) allow mutually exclusive classification of thoughts, similar to how living things are classified by the Linnaean Taxonomy (a Genus is a supertype of a Species).

Tags allow multiple characteristics to be expressed, just like you could have tags for many living things such as "bi-pedal" or "aquatic".

One more topic: When should you use parent thoughts instead of tags/types? A lot of the things you can do with tags and types can also be accomplished with parent thoughts. Generally, parent thoughts should be used when you want to see things in plex. This is convenient if you will be navigating between all the relevant thoughts often (since they will all become siblings). Sometimes you don't want this however since you won't want to navigate between the thoughts and the parent link just causes clutter.

twospoons wrote:
By having strongly typed Thoughts, Types and Tags (and now your suggestion to add Keywords to the list of ways to categorize a Thought), it forces extra steps upon the user to manage each of these categorizations independently.

Example: In my brain, I have several thought branches coming off of the root thought, Projects, People, Religious Studies, Books, Social Networks, Music, etc.  Given Harlan's statement above, aren't these essentially groupings of Thoughts?  Why not allow these groupings, "subjects", "hubs" or whatever you want to call them, to act as Smart Thoughts?  Let's say I'm working on a project for a house that I'm remodeling and I find a good book on plumbing.  Now since I am working on this remodel project and I am already in that section of my brain, I want to link this book to the specific branch of the project associated with the plumbing of the house as a reference.  Now I am already editing the newly created thought about this book, do I also have to remember to draw a link to the "Books" thought branch all the way back at the root of my brain or can I simply select Book from my complete list of categories as the Type for this thought?

Now if I want to see all of the thoughts in my brain that are "Books", I can run a report to see a list of them (based on Type), but what if I want to see them all in the plex under my "Books" thought branch (maybe because I want to be able to navigate to the author of a book)?  Why can't my "Books" thought branch be configured as a Smart Thought so that all Thoughts where the Type is set to Book, can be dynamically populated as children? 

Well, I could also create a Tag called "Book" and also assign it to the plumbing book Thought I just created.  Now I can click on the Book tag in the Tags tab and see a list of all of the thoughts with the Book tag.  This is great, but it is double entry just to see a list of similar Thoughts in the plex.  But, now I can't browse directly to it through my Books thought branch, because it is a Tag Based Smart Thought and it disappears from the plex when I navigate away from it.  I can only get to this Smart Thought from the Tags tab or the Instant Search (there may be another way that I'm forgetting right now).  Why should PB force the user to choose one method of categorization over another?  Why not combine the functionality and add the flexibility for PB to use the same set of data in different ways, based on how the USER wants to view the data?


twospoons wrote:
Harlan wrote:
Tags on the other hand are used to define properties of a thought and a thought may have many tags.

This statement seems a little flawed to me.  I agree with the functionality as described by Harlan's complete statement (quoted further above), but I don't really see tags as defining a property of a thought (other than creating a list of keywords).  I see "properties" (or attributes or metadata or whatever you want to call it) as I do Label in the P&A window, like a Key=Value pair.

dyslucksia wrote:
You would like to see Tags and Types merged. My understanding of the way that PB is currently implemented would make this very difficult to do (if not impossible) for both logical and physical reasons.

I believe it would be much, much easier than you think.

Harlan wrote:
Yes - Actually, if you really want to warp your mind, the fact is there is a single set of thoughts and there are links between those thoughts that indicate parent/child/jump/type. In other words, types are just thoughts who have a special link relationships with other thoughts. Thus a thought can be a type for another thought, which may be a type for another thought...


See, even Harlan agrees (I kid, I kid)  But here is why I believe it would be easy enough to do.
  1. Thoughts are just Thoughts
  2. Thought Types are just Thoughts
  3. And my hypothesis is that Tags are just Thoughts as well.
The only difference between these identical objects is how the links between them are defined.  As a result, the plex is designed in such a way that it displays these identical objects in various ways based on their internally defined type (for lack of a better word and not to be confused with Thought Type).

If you think about the concept of Filtered Views, what if you had a view that only displayed the hierarchy of Thought Types in the plex?  If you don't have any SuperTypes defined then it would be a flat representation of all of your Thought Types under a 'type' root.  Or if you have actually started using SuperTypes properly, your would see a root with branches stretching out for all of your nested Types.  Then if you turned off this filter to display all Thoughts, you could navigate down your Thought Type hierarchy to the individual Thoughts under each Thought Type (maybe with a default Untyped category for everything else).  Wow, that's almost the same thing that Tags are doing today (except that Tags don't have a hierarchy) and this is starting to sound an awful lot like a report in the sense that you can run a report of all Thoughts of a particular Thought Type.  I seem to remember during one of the beta releases that someone was having trouble with the plex because all of his Thought Types were showing up as Thoughts in the plex.  What a coincidence, because THOUGHT TYPES ARE JUST THOUGHTS.

Now on the other hand, Properties (metadata) of a Thought are quite different.  Right now in version 5.0.x this is limited to things like the color, label, icon, (and I would venture to say events).  Previously in version 4.x Tags were simply just a Property of a Thought.  Now Tags have been moved from being just a Property of a Thought to being a Thought themselves, with special links to other Thoughts.  If users were able to define their own metadata, I see this as being more like the old version of Tags and the current Label, but with the user being able to select the type/format of the data (like string, number, date, etc), simply just KEY/VALUE pairs in a form.

My proposal to merge Tags and Types would be VERY simple.  Keep the existing functionality!  But change how the list of available Tags and Types are displayed.  Here are the things that we would need to make this work:

1) Drop the internal distinction between which objects are Types and which ones are Tags so that there is a single consolidated list including all Types and all Tags.  Lets call this consolidated list of Type/Tag objects a Category List for the purpose of this discussion.

2) We need a better way to manage the hierarchy and properties of this new Category List.  Yes this consolidated list would in essence create a way to build hierarchies of Tags as well (because it the same list of Tags and Types).

3) When I right click on a Thought the menu options for Type and Tag would still exist just like they do today.  The only enhancement will be that the list of available Types/Tags would be identical because there is only one Category List.

4) Users should be able to create new Types like they can today and assign Properties to that Type (color, icon, SuperType, etc).  These Type Properties would only apply to a Thought if this Category List object is applied to the Thought AS A TYPE.

5) Users should still be able to create new Tags like they can today and assign Properties to that Tag (display Tag Hint, Set Color, etc).  These Tag properties would only apply to a Thought if this Category List object is applied to the Thought AS A TAG.

6) Users would still only be able to assign one Type to a Thought and would still be able to assign many Tags to a Thought.

7) When a user assigns a Type to a Thought, that Type should also be applied to that Thought as a Tag, because the current grouping functionality of a Tag should not be limited to just Tags.  Grouping by Type should work the same way.

Disadvantages:
  1. The combined list of Types/Tags may be longer than the users existing segragated lists of Types and Tags.  This could potentially pose a problem to the selection of Types/Tags in the current UI (this potential already exists it just hasn't been voiced as a problem yet).

Advantages:
  1. This Category List can be managed in one place and dupilcation of categories does not have to exist in two separate lists.


So here is the question: Why would this not work?

Please list any more advantages/disadvantages you can think of.
Wes
Quote
zenrain
My original post on this was:
Quote:
Sorry, I don't agree with rolling tags back into types.
With tags we now have two ways of assigning additional data to thoughts to further break them down/categorize/search etc. Rolling them back into types takes away an alternate identifier or meta-data needlessly. Even including the recommendation to allow a primary and secondary/tertiary types would still remove another way of combining data.

I also disagree that the difference is in the programming. In OSX there are quite a few programs that have tagging capabilities, and there is a lot of value of assigning tags to files as far as searching, or to create groups of documents regardless of location. Using the same analogy, types are like file labels which are assigned a color in OSX and have a one to one relationship. I use both for different reasons.

If people don't wish to use them, then simply ignore the tab, and continue using thought types. Sometimes choice is good!


I still don't see much of an advantage for tying the two together on the back end. Most of the functionality as you described would mean things stay the same on the front end, with the main change of only having to maintain one list.

Lets say I use tags primarily as priority (1, 2, 3) and types primarily as categories (books, people, places). I also have subtypes of books as fiction, non-fiction, biographies, and people as friends, family and co-workers.
To set a tag of priority I would have to browse over my types and subtypes, and vice versa. Also, if I accidentally set a subtype of friends as a tag, I lose the ability to include it in the supertype report for people.

My main concern about keeping types and tags separate is that I can use them both to narrow down reports. For example, I can do a search on all Priority 1 tagged thoughts that have a type of friends. This gives me much more flexibility than only being able to report on Types, or only Tags.

I would prefer to see Types get the same love as tags as far as how they display in the plex. I know Harlan was mulling this over in the early 4x days, and I hope it's still being considered. If it would be possible to have the type plex display cross-reference to the tag display (for example, you select Priority 1 tags and the friends type and you see both tag and type in the plex with thoughts that belong to both) that would be... Well, pretty darned awesome.

Quite frankly though, I would really, really, really love to see Smart-thought implementation. I know Twospoons and several other people including myself have touched upon this quite a few times. I imagine Smart-thought functionality to be the current reporting functionality combined with advanced keyword searches that are saved to an automatically updating thought. Thus I could pin a smart-thought that would automatically show me any thought in the plex that I'd given a tag of media, was created in the last week, and contains "Apple" in the thought name.
Holy crap, I get shivers just thinking about it. Even better, you could assign a view to the Smart-thought, so when you activate it, it will list all those thoughts in outline view.

Sigh. Got a little off topic there, sorry.
Windows 7
J-1.6.0_22
--
OSX 10.6.3
Java SE 6
Quote
Steeph
Exactly my idea Twospoons.
Actually, I proposed the exact same idea in this thread

In short, assign a main tag to serve as type, and use other tags as they are now.
PB user since 1998

Mind over matter?
I don't mind and it doesn't matter.
TB 8.0.2.1 Pro on Win10.1 Pro 64bit JVM 1.8.0-112
Quote
twospoons
zenrain wrote:
Sorry, I don't agree with rolling tags back into types.
With tags we now have two ways of assigning additional data to thoughts to further break them down/categorize/search etc. Rolling them back into types takes away an alternate identifier or meta-data needlessly. Even including the recommendation to allow a primary and secondary/tertiary types would still remove another way of combining data.

 
I'm really not suggesting that we roll Tags back into Types.  I use both Tags and Types fairly extensively, but it is frustrating when I have to create both a Tag and a Type FOR THE EXACT SAME CATEGORIZATIONS, just because I want the flexibility to view MY DATA in different ways.  I do object to your claim that consolidating Types and Tags, somehow takes away some functionality.  Could you provide some more examples?
 
zenrain wrote:
Also, if I accidentally set a subtype of friends as a tag, I lose the ability to include it in the supertype report for people.


No, with what I am proposing, you would not lose any of that functionality.  Instead of defining "friends" as a Tag or a Type up front you would define "friends" as a Category with the either the Properties of a Type or Tag or BOTH.  You would be able to use it interchangably and even simultaneously if you wanted to (although you would still be restricted to only one Type, but multiple Tags per Thought).

zenrain wrote:
My main concern about keeping types and tags separate is that I can use them both to narrow down reports. For example, I can do a search on all Priority 1 tagged thoughts that have a type of friends. This gives me much more flexibility than only being able to report on Types, or only Tags.


There is no reason you couldn't still do this.  I am not wanting to lose any of this functionality.  I'm only pointing out that there is huge overlap in the ways people are currently using Types and Tags and to make this easier to manage, the list should be consolidated. 

zenrain wrote:
I would prefer to see Types get the same love as tags as far as how they display in the plex. I know Harlan was mulling this over in the early 4x days, and I hope it's still being considered. If it would be possible to have the type plex display cross-reference to the tag display (for example, you select Priority 1 tags and the friends type and you see both tag and type in the plex with thoughts that belong to both) that would be... Well, pretty darned awesome.


This is the perfect example of why I am suggesting this.  Why limit the plex to only normal Thoughts and Tags when Types are also Thoughts?  Why shouldn't they be displayed in the plex with the same grouping/categorization functionality that Tags have?  Why shouldn't Tags be able to have a hierarchical structure?

zenrain wrote:
Quite frankly though, I would really, really, really love to see Smart-thought implementation. I know Twospoons and several other people including myself have touched upon this quite a few times. I imagine Smart-thought functionality to be the current reporting functionality combined with advanced keyword searches that are saved to an automatically updating thought. Thus I could pin a smart-thought that would automatically show me any thought in the plex that I'd given a tag of media, was created in the last week, and contains "Apple" in the thought name.
Holy crap, I get shivers just thinking about it. Even better, you could assign a view to the Smart-thought, so when you activate it, it will list all those thoughts in outline view.

Sigh. Got a little off topic there, sorry.


My same sentiments exactly.  I see Smart Thoughts as the next true evolution to PB.  This thread is merely a feeler to get some feedback about the differences and similarities of Types and Tags.


Wes
Quote
zenrain
Thanks for your reply, discussion is always good.

Quote:
I do object to your claim that consolidating Types and Tags, somehow takes away some functionality.

That first quote was one of my replies in the original posts you referenced to. It was in response to:
Quote:
I sorta made the same suggestion, but then that types be merged into tags.

and
Quote:
This hurts my head. Sometimes too many options is not always the best option

Sorry, I was carrying my original reply forward so there was a bit of background. I should have been clearer.

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.

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.

Edit: after giving this a little more thought, I also think that the merge could be very confusing for newcomers to the software. You have the option of creating a type/tag which you can make behave one of three ways, possibly at the same time. As a Tag which allows multiples, as a type which does not, and as a supertype which is the equivalent of a types parent. Given that types and tags already causes some confusion as to the differentiation, having tags be types and possibly supertypes would be very confusing to anyone not familiar with the original implementation and the evolution of types and tags, possibly to the point of just not using any of them.
Windows 7
J-1.6.0_22
--
OSX 10.6.3
Java SE 6
Quote
westbroek
Disclaimer: skimmed over a whole bunch of stuff...

To me this is a pretty moot discussion and certainly not something I would wish any development time to go into. Doing this wouldn't have me fork over another 75 dollar down the line to another major or "major" upgrade...
Quote
twospoons

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?

dyslucksia wrote:

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.


Wes
Quote
twospoons

westbroek wrote:
Disclaimer: skimmed over a whole bunch of stuff...

To me this is a pretty moot discussion and certainly not something I would wish any development time to go into. Doing this wouldn't have me fork over another 75 dollar down the line to another major or "major" upgrade...

Yeah, this in and of itself probably wouldn't justify and upgrade for me either.  I'm just throwing stuff out there for people to think about.

Wes
Quote

Newsletter Signup  Newsletter        Visit TheBrain Blog   Blog       Follow us on Twitter   Twitter       Like Us on Facebook   Facebook         Watch Us on Youtube  YouTube       

TheBrain Mind Map & Mindmapping Software     Download TheBrain Mind Mapping Software