ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

RightNote version 3.0.0 released

<< < (5/8) > >>

I'm curious if Surfulator overcomes the tag searching shortcomings of RN mentioned in the link from peter.s above (post #13)

Otherwise, and FWIW, my sense of fairness says it's not really fair to be talking about one app in a thread about another app - unless you are comparing the two  :-[

tomos, it will - but that' not the prob.

SOME people here mix up "keywords" / additional tags within an otherwise hierarchical data repository, and a tagging system (treed or not, and where such a contextual data hierarchy simply is not there) - these are two different worlds, conceptually. All about trees and tags in the outlinersoftware forum (whilst my very first musings about the difference in paradigm was here, in a discussion with Paul, some year ago).

So some current Surfulater users might be in for a shock if they really try to switch to NextGen (and if Neville does away with the non-tag tree indeed). For the casual reader who's not willing to delve into details: Just consider that today's tagging systems do not allow for "manual sort" of the items to be found in some tag tree subtree, whilst in outliners you do manually sort siblings in order to give them more "meaning", more "accessability", in a word/term, "natural order for current context", and of course, for some 20 or 30 such siblings, and for serious / efficient work, that's an important criterion for your data repository.

And yes, for SOME, very specific data collections, tags are best (here again, details in

But tag trees try to overcome the above-mentioned endless-keywords-lists probs, but try to apply the tagging concept to stuff that had better be put into a tree, with clones. Here again, for the casual reader: Tags are best for traditional db items, i.e. stuff that sometimes is considered in "collections", to compare, but which is treated "one-by-one"; whilst "tree stuff" is data that has to be "combined" to be useful, be it combinations of items(' partial content) in order to create additional items, or be it "just" for your "consideration", and your decision-making: Here, as I have developed illic, the "manually sorted context" of the tree concept (whilst subject to necessary amendmend, I perfectly acknowledge that (keyword here: in current realizations, no variants in sorting for different contexts, let alone subgroups / easy combination variants)) should be preferred.

Current RightNote neither has clones, nor has it viable tag M, so it's not good for anything, considering its bug make it doesn't even have working Boolean search. But there certainly will be a version 4, much better than the current one.

IM is about making available anything possibly relevant info in an optimized way, and without the (academic or corporate) user going crazy in the process, i.e. complexity reduction, yes, but not to the point of leaving relevant things out; and in tagging systems for academic stuff, it's the poverty of the tool that then triggers unnecessary manual, additional work "on arrival" - dont mix up neatness and primitiveness. Join me illac, and let's see if we can find some improvement of either concept together.

Very interesting post peter. Some of it is over my head - I'm one of those causal readers ;-)
I've only used tags in fairly basic manner but am curious (and would like to get more efficiently organised).

FWIW, sorting is very important to me in file management and email client so can understand your emphasis on it.

Wondering what is
            1) a "viable tag M" is?
            2) is illac a typo of illic (I could find illic online, but not illac)

On the side: I'm unhappy with the use of the word 'clones' to indicate the same item shown in different locations, but have heard it's fairly universal at this stage - is that the case?
(If that's a clone, what do you call an identical copy :-/ )

Linkman! You mentioned tags in Linkman. I presume you are talking about the keywords? I have used Linkman for a few years now though I must admit I don’t use the keywords much anymore. Rather than a separate field for users to enter keywords, Linkman takes the keywords that the website builder uses for search bots or whatever. And Linkman pulls all of those in for each URL saved. I have some bookmarks that must have 200 to 300 doggone keywords! A lot of sites put everything in their keywords imaginable, which I don’t much like. I used to highlight and delete all the keywords that come in with the bookmark and then enter my own, but that turns bookmark saving into a PITA, in my opinion. I wish the Linkman developers would give us a separate field for our own tags/keywords, independent of the long lists that a lot of sites have. Actually if they would make importing the sites' keywords a user-configured option I'd be tickled!
-J-Mac (January 26, 2014, 12:08 PM)
--- End quote ---
Hi, Jim.  Thanks for the info about your exchange with Neville.  I guess we'll just have to wait a bit longer to find out what the features and policy on updates for NextGen will be.

I'm writing now to address your remarks about Linkman.  What you've asked for already exists.  When I started using Linkman, I quickly found that I hated the junk that often was added by companies to the keywords and description fields, but then I saw that there's a checkbox on the form we use to add and edit a bookmark to linkman that says "retrieve keywords" and  "retrieve description".  I have those UNCHECKED and so I don't get keywords and descriptions I don't want.  The only keywords and descriptions I include are those I put there.  I tend not to use descriptions, but I depend on keywords, which, as far as I'm concerned, are pretty much the same as tags.  So in Linkman not only does the user have control over which categories are used in a search, s/he also has control over what's in the keywords and descriptions sections.  

Hello, tomos,

Illic and illac - well, I once attended a German "Gymnasium", and there I got the "Big Latinum", but that was ages ago, and my tries to differenciate the two, before using those terms here, by web search, was unsuccessful; they seem to be more or less synonyms, but perhaps not in all possible cases, so I'd be thankful for an expert to inform us of the minute differences in use of both (I suppose it's a "case" thing).

As for "viable tag M", "M" being "management", in all my posts (as "IM" is "information M" and "IMS" being "IM system"), but here, I just wanted to express that of course, a VERY basic condition for ANY tagging system should be to be able to (easily) combine tags not only in applicating them, but then again, when constituting any "collections" / "items' sub-groups" by combining them. (I'm even quite sure that in SOME way or another, that might be able in RN 3, but then, I asked for HOW to do this, explicitely in outlinersw forum, and, implicitely, here, but without getting any answer, and even IF it's possible in RN, it certainly is absolutely awful.)

Re clones: There's an "official" term for it used by some author, but which I quickly forgot; my today's synonym search for "clone" didn't bring it even (but brought "mimeo" which I kind of like). Again, the real prob doesn't lie in the term, but in its application:

Most outliners, once you clone an item, will NOT distinguish anymore between the "original" and the "clones", whilst conceptually, there should be an (updatable) difference, and which I call "natural parent" and "adoptive parent" - name it as you like, but it's evident any item in a tree hierarchy should have a "natural/main context", and then, perhaps multiple, "additional contexts" - and be it only for avoidance-of-recursion reasons: btw, I mentioned this problem within a discussion of InfoQube in the outlinerswforum, where the developer of IQ, Pierre Paul Landry, suberbly said (I'm citing from memory), "IQ allows for recursion"... when in fact, recursion is a PROBLEM of IM, and which has to be avoided/contained, and certainly not a feature of IM (development illac ;-) ).


[0] Message Index

[#] Next page

[*] Previous page

Go to full version