Skip to main content

Home/ Diigo Community/ case-sensitive tags - any chance of it happening?
jeffreyjflim

case-sensitive tags - any chance of it happening? - 381 views

discussion tag case CamelCase case-sensitive help suggestion

started by jeffreyjflim on 27 May 07
  • jeffreyjflim
     
    as per subject. I was wondering whether this would be implemented... It may not sound like much, but hey, mixed-case and selective-case tags can be good for organizing, and for the visual effect...
  • Dr. Fridemar Pache
     
    Thank you Jeffry for supporting this powerful idea of CaseSensitiveTags in AnnotationEngines:

    Advantages

    • BetterOrganizing (as you state, letting me suppose, you are a programmer too, knowing how powerful this option for "identifiers" is)
    • WikiFyingAnnotions: each MixedCaseTag could be a WikiWord reference, integrated in all DiiGoForums and annotations (in which case as an example our contribution would be much more valuable for the social annotation community)
    • AutoTagging: each MixedCase word in any posting or annotation could be auto-tagged, i.e. the DiiGoEngine could automatically make a tag out of it, what would save millions of hours for our community peers.
    • FineTargetedSearch (This would make any AnnotationEngine even superior to Google, because the Google SearchEngine doesn't support mixed case)
    What a pity that the current annotation system hasn't yet realized the blessings of  the WikiPrinciples, although I preach this in public since years. In this case all the MixedCase words in this contribution would be automatic links.

    MayAllBeHappy
    Fridemar

    PS.: I make this excellent idea (as always a public annotation and a blog), to support it within the wider community. DiiGo has the chance to realize it . At least It would make no great effort to transfer the raw MixedCase to the associated social bookmarking communities by SimultaneousBookmarking, so that they can support it. I bookmark this highly community-relevant contribution with public bookmarks CaseSensitiveTags and AnnotationsAsWikiPages, AnnotationTitlesAsWikiPageTitles , AutoTagging,  so that you can find it by searching it via DiiGo.
  • Maggie Tsai
     
    Thanks for both of your input.

    Tagging impacts both organization and search result. Although there are certain pros as suggested, we also need to carefully consider many cons the case-sensitive tags will bring, such as existing tags, potential bigger mess in retrieving community tags (information ended up less easily found because everyone has different tagging convention, misspelling due to different cases, etc....), not a convention supported by all other services and search engines - this may lead lots of complication in data import / export / sync, etc, etc. ...
  • jeffreyjflim
     
    thanks, Maggie for ur consideration of the input. First of all, i would like to say that what i am suggesting is case sensitive storage of the tags - and not so much case *differentiation*. ie., (using an example) the tag "CaseSensitive" should NOT somehow be differentiated from the tag "cASeSeNSiTivE" (as if we cared about using the 2 separately!). So in that sense i understand ur points about the cons (potential mess, information not found due to case differences).

    I understand the concerns that u may have, but for me, the use of capitalization info would just make the tag *so* much more information rich. Implementation-wise, this is what i would suggest:
    - the first time a tag is created, it is stored as is case-wise. This will in future be the "reference case implementation" for the tag
    - for all future tags: to check for tag equivalence in future tag operations, simply just do a lowercase() operation, and then compare. All tags that are found to be equivalent through this process to an already created tag should therefore be switched to (with the appropriate case copys) the already existing tag. Therefore, tagging an article with "rubyinsight" would be the same as tagging it with your first "RubyInsight" tag.

    Would this help to take care of the cons? Search engines (+ other services) -wise, diigo can carry on to use the already default lowercase (so that the exising links + PR are still there, and will be preserved). I only ask that we be able to have the case as stored presented to us as we originally meant it... ie. in the "My Bookmarks" display, and in the tag cloud.
  • Hans Wobbe
     
    Maggie...

    I fully understand your reservations about supporting case sensitive tags, but after considerable research I have come to the conclusion that I personally should not hold back, just because many others are not yet concerned about something. (Since my obvious bias in favour of this is already showing, I should probably state that it comes from years of integrating wikis into Information Technologies; even going so far as to accept them as one of my primary productivity tools.)

    One suggestion that may 'bridge the gap' is the use of a presonal preferences switch. Unfortunately, I do not know enough about the DiiGo (see... I'm such a creature of habit that I automatically used CamelCase) to know if this would be so obviously prohibitively expensive, that it should be ruled out immediately, or not.

    One of the reasons that I am supporting this request is evident if you look at the Tags that I've been creating here. Obviously my needs for visual distinction are such that I've gone to considerable lengths to devise tags that use special characters to differentiate them. This is even more important to me since one of the very nice features I rely on DiiGo for , is its generation of RssFeeds for tag sets that are 'intersections' of tags (logical ANDs). These feeds are automatically routed to other web services applications I rely on, dramatically increasing the value of the Bookmarks that I create here and apply Tags to.

    For you additional information, this is of sufficient value to me that I now frequently find myself wondering about DiiGo's Business Model. After all, I would be negligent if I become dependant upon something wthout knowing what I am likely to have to pay for it in the longer term. In effect, what I'm saying is DiiGo is sufficiently valuable to me, that I worry about its financial viability, since I don't see how you are generating Revenues to offset the obvious Expenses.

    But, I've "digressed."

    DiiGo is a womderful service. I sincerely hope it prospers since I find it very helpful and obviously would like to be able to keep using it. Ideally, I'd even like to be able to offer reasonable suggestions regarding possible enhancements.

    Regards,
    -- HansWobbe.
  • Maggie Tsai
     
    Thanks for more helpful input from you all. We will discuss more here to consider preserving tag cases for display, not for search. Of course, we need to figure out a good way to resolve the long tag UI display issue as well...

    Glad you like Diigo. Judging from your comment, you should be quite an expert user- love to have your feedback and active participation.

    Despite lots of hypes and noises out there, we're focused in executing our vision - it will only become richer and richer in all aspects and become even more useful. We're idealists with lots of practical business sense. Diigo plans to be around for a long, long time :-)
  • jeffreyjflim
     
    maggie_diigo wrote:
    > Thanks for more helpful input from you all.

    :)

    > We will discuss more here to consider preserving tag cases for display, not for search. Of course, we need to figure out a good way to resolve the long tag UI display issue as well...

    yup. Imposing an artificial "12-character limit" on a tag doesnt sound like good information management (which of course, i presume diigo is all about!).

    >
    > Glad you like Diigo. Despite lots of hypes and noises out there, we're focused in executing our vision - it will only become richer and richer in all aspects and become even more useful. We're idealists with lots of practical business sense. Diigo plans to be around for a long, long time :-)

    that's good to hear. I'm starting to think about the feasibility of actually putting all of my stuff into diigo. And if i ever get to start on my research project, i'll likely recommend to the team taking a look at diigo as well...
  • Dr. Fridemar Pache
     

    Comments from the Diigo community




    Suggestion: CaseSensitiveTags

    If you preserve case for viewing in
    your database anyhow, then it would be a neglectable overhead (in terms
    of computing time)
    to offer the users of the tag-search function both
    options:


    CaseSensitiveSearch: (with Case enabled)
    CaseInsensitiveSearch: (with Case disabled)

    MayAllBeHappy
    Fridemar

    by fridemar less than a minute ago





  • davido T
     
    I second the vote for case-sensitivity. Doesn't need to differentiate for searches, but just for personal use, saving them how I type them would be lovely.
  • Dr. Fridemar Pache
     
    SupportingTheCase

    Thank you Davido,

    for supporting the "case" :-).

    But why restricting this time-proven concept of MixedCase only to personal tagging.
    Aren't we not an an initiative for SocialBookmarking and SocialCooperation?

    And why excluding it from searches?
    MixedCase better interfaces with the thousands of WikiCommunities.

    MixedCaseTags are a great filter for this purpose.

    MayAllBeHappy
    Fridemar

    Manually tagging all WikiWords as tags. AutoTagging would be a great help:

    SupportingTheCase

    MixedCase
    ...
  • Wade Ren
     
    there are basically three options regarding the issue of case-sensitive tags

    1. not case-sensitive -- to my knowledge, this option is actually taken by almost all social bookmarking services. please advise if you see otherwise.

    2. case-sensitive for both display and search --- basically treat them as separate tags

    3. case-sensitive for display but not for search. In this case, if you use both "TAGS", and "tags", we need to show just one of the two and merge their usage counts. but which one should be displayed. A simple
    solution is to display the first one used --- for example, "TAGS" instead of "tags", if you used TAGS in any bookmark first. You can also edit the displayed tags of course.

    what do you think of option 3), which is easier to implement than option 2?

    also, note that option 2 can make searching by tags a little problematic.
  • Dr. Fridemar Pache
     
    SupportingTheCase



    Hello Wade,

    thank you for taking the "case" seriously. The decision for supporting case is a strategic one.


    Ad
    1) Not case-sensitive: Even if all other
    DiigoAffiliatedBookmarkingServices would restrict their engines on
    not-case-sensitive, this would be not a serious problem to stick to
    StrongCaseSensitivity You could transfer to them the MixedCase and
    leave them the decision, wether they apply a
    "converttolowercasefunction", hampering the reading quality and
    depriving them from a lot of fast analytical operations on tags.


    Ad 2) Case-sensitive for both display and search: If the underlying database respects case, then"IBM"
    (TM), the trademark of this computer-company and "iBM", a possible rival product of IBM to the iPod of the Apple (TM) company, are indeed different and need to be respected as valuable tags. It is no problem
    to delete the "converttolowercasefunction" call somewhere in the DiigoEngine.

    You see not only communities of programmers will have an enormous gain,
    when using CaseSensitiveTags, correctly handled by the DiigoEngine.


    Ad 3) Case-sensitive for display but not for search: Please don't put this
    unnecessary burdon (of editing tag appearances) on millions of Diigo
    users.


    MayAllBeHappy

    fridemar
  • Soul Book
     
    i definately wouldn't want case sensitivity to cause different tags.. eg: "Tech" and "tech".. that would be very annoying.. as for case display, I guess that would be ok... but it'd probably make my tags look much more messy and confusing..

    I'd probably capitalise some tags, but forget on others, and to the TYpo thing of capitalising 2 letters accidentally.

    I think that merging singles and plurals would be a much more useful addition. Eg: "game" and "games" would both be merged into the same tag automatically.
  • Hans Wobbe
     
    May I ask why it would be definitely annoying?

    My interest for asking is that I am currently of the opinion that I (personally) would really like to have Case sensitivity for reasons that I consider to be "pros". Since there obviously, there may be "Cons" that I've over-looked, I'm curious as to the reasons you may have.

    Thanks, in advance...
  • Dr. Fridemar Pache
     
    #2
    AllLowerCaseModeForTagsAsOption:

    alllowercasemodefortagsasoption

    Hi Soulgrind:

    I can feel with you and all the other peers, who are used to work in a relaxed way without the need to bother about the case. As long as Diigo is used for private tagging, why not.

    But when subcommunities within the DiiGo sphere want to build SocialCollaboration they need precise tags. Think of distributed teams of C++ programmers, who are very sensitive in questions of case.

    For non-programmers, please rethink the iPOD (TM) versus iBM (TM) example.

    Your example could be used for differentiating tags by TypingShortCuts

    Tech=HIghTech
    tech=LowTech

    In the author's view this is not at all "annoying". It is indeed very convenient.

    It takes some carefulness of the SocialTagCommunityUser, but they will learn the advantage of CaseSensitivity very fast, as soon as they see more examples. On the other hand, as Maggie pointed out, the (private) tags remain editable.

    Even the PluralSingularIssue, well known in the different WikiCommunities, would have a total different importance in TagCommunities.

    "game" and "games" could precisely
    differentiate between a site, devoted to one game only versus a site,
    where more than one game is offered.

    MayAllBeHappy
    fridemar
  • Dr. Fridemar Pache
     
    Dear Maggie, dear Diigos,

    please see the above page with manually inserted Google-links, to get a feeling of the power of AutomaticTagging, based on WikiWords.

    By the Way. There is some bug in the annotation engine. It doesn't support HTML, as this forum supports it. As test, please click the following links in the forum posting. Then for comparison click the links in the annotation.

    fridemar.

    SupportingTheCase

    Hello Wade,
    thank you for taking the "case" seriously. The decision for supporting case is a strategic one.

    Ad 1) Not case-sensitive: Even if all other DiigoAffiliatedBookmarkingServices would restrict their engines on not-case-sensitive, this would be not a serious problem to stick to StrongCaseSensitivity You could transfer to them the MixedCase
    and leave them the decision, wether they apply a
    "converttolowercasefunction", hampering the reading quality and
    depriving them from a lot of fast analytical operations on tags.

    Ad 2) Case-sensitive for both display and search: If the underlying database respects case, then
    "IBM" (TM), the trademark of this computer-company and "iBM", a possible rival product of IBM to the iPod
    of the Apple (TM) company, are indeed different and need to be
    respected as valuable tags. It is no problem to delete the
    "converttolowercasefunction" somewhere in the DiigoEngine.
    You see not only communities of programmers will have an enormous gain, when using CaseSensitiveTags, correctly handled by the DiigoEngine.

    Ad 3) Case-sensitive for display but not for search: Please don't put this unnecessary burdon (of editing tag appearances) on millions of Diigo users.

    MayAllBeHappy

    fridemar

    PS.:  A simple realization for Diigo-, Trailfire and other social annotation services for AutomaticTagging is given in the above text by manually making transforming all WikiWords into GoogleSearchLinks.
  • Dr. Fridemar Pache
     
    Thank you wade,

    so my work to convince you, wasn't a waste of time.

    You might want to have a look at http://www.usemod.com/cgi-bin/mb.pl?TagWiki and on
    http://c2.com/cgi/wiki?TagWikiContest.

    I keep my fingers crossed.
    fridemar

    PS.:
    By the way, why don't you offer a uniform WysiWyg input field for all postings, comments, sticky notes? You have the modules. Your rich text input offers more options, than the input-field of TrailFire, but it would be practical to have the sourceview too.
  • Hans Wobbe
     
    Fridemar...

    Would you like to join me in structuring requests into a bit more of an "architecture"? What I mean by that is...

    * The many of the wiki solutions you are promoting already contain WysiWyg capabilities, so it should be possible for us to design a few effective HyperText "pragmas" that provide a relatively seamless way of melding the best function of each core component. Consider, for example, the ability to merely have a Diigo Sticky appear within a wiki page as as part of a standard oddmuse TransClusion.
    ** I think this would avoid "re-inventing" the wheel AND would allow individual SubWikis to retain their own "look and feel" through their existing ability to overlay local CSS.

    I think it would be relatively easy to demonstrate the potential by simply designing a layout and a static HTML prototype using the free resources of the .../ODD/ wikiHive.

    Interested? -- HansWobbe


    > By the way, why don't you offer a uniform WysiWyg input field for all postings, comments, sticky notes? You have the modules. Your rich text input offers more options, than the input-field of TrailFire, but it would be practical to have the sourceview too.
  • Maggie Tsai
     
    This will be very helpful. Ideas cannot be translated into reality, unless everything is carefully thought out and architected.

    Also, without sounding disrespectful, some of the messages are extremely cryptic and hard to follow. To facilitate productive discussion, may I suggest as much "plain" language as possible.

    I suggest we take this new line of discussion to another group
  • Dr. Fridemar Pache
     
    WikiAnnotationByTransclusion

    Hello

    Dear Maggie, dear Hans

    the idea of combining annotation with transclusion is an excellent idea of HansWobbe. This solves several problem with one clap:

    * UrlBasedAnnotation: now each annotation can have it's own Url like TrailFire does it, but with the added advantage, that those WikiPageUrls have the form: WikiPrefixColonFollowedByWikiPagename and not only coded by cryptic numbers. So the readability in GoogleSearchResults is improved.

    * GlobalWikiEngineSupport:
    ** EachWikiAnnotationAsPartialPageOrFullpage 'quite normal windows, no more tiny stickies, that must be manually resized.'
    ** EachWikiAnnotationWithLookAndFeelConserved

    * LocalWikiEngineSupport 'where each wiki word is tagged automatically by a TagWiki'

    The main advantage appears to be using host wikis as source for RichLinkContext and NestingOfAnnotations in the sense of KaPingYee, who invented WebAnnotation. This means each WikiPage itself can be annotated or edited, thus CreatingSpaceForSocialCollaboration.

    Some people may object, if you have a WikiPage, you don't need annotations.

    If millions of peers of the social annotations communities, would edit the WikiPedia, what a mess.
    Unobtrusive annotations solve the problem.

    MayAllBeHappy

    -- fridemar
  • Daniel Eldridge
     
    Has this discussion been moved to a new group?

    If so, what is it?

    In any case (no pun intended) please note my vote IN FAVOR of maintaining the case of the characters entered by the user.

    Isn't there some maxim of User Interface Design that states: Do Not Change What the User has entered--unless, of course, you're the Post Office.

    As for being difficult to maintain the proper case for other bookmarking services...Oh What a PITA--that Pain In The Ass--it is to be a leader. Worst case maintain a field for each foreign service with which you support import/export and keep this field in the appropriate case.

    --Dan
    maggie_diigo wrote:
    > This will be very helpful. Ideas cannot be translated into reality, unless everything is carefully thought out and architected.
    >
    > Also, without sounding disrespectful, some of the messages are extremely cryptic and hard to follow. To facilitate productive discussion, may I suggest as much "plain" language as possible.
    >
    > I suggest we take this new line of discussion to another group
  • Wade Ren
     
    we hear you. it will be made case-sensitive soon.
  • Nigel Gale
     
    This was a bugbear with me - but just tested it - it's working - thanks Diigo!
  • Dr. Fridemar Pache
     
    Hey wade,

    what is "soon", within 1day, 1 week, 1 month, 1 year, this decade ... ;-)

    MayAllBeHappy

    -- fridemar

    PS.:
    This posting is not blogged on my SocialCommonWealth blog.
  • Soul Book
     
    *skipping to the end of the thread*

    I'd like to vote against case sensitive tagging. Several other services i used had it, and people were asking for it to be removed. Ideally I'd like everything reduced to lower case, so its consistent.. and if possible plurals to be ignored too.

    With case sensitive tags its too easy to end up with loads of similar tags that you really wanted to be all the same thing. eg: Book, book, BOok (typo), Books, books, BOoks, etc..

    keeping things simple, single case, and having book = books makes autocomplete work faster, and makes all your tags more organised. (half the reason delicious needs tag bundles is do deal with the problems of duplicate tags.
  • Wade Ren
     
    well, we are making it even smarter than what you want :-)

    so tag case will be preserved while displaying, but ignored for search.

    in tag cloud, if you used both "book" and "Book" as tags at different times, then we only show the last one you use.
  • Soul Book
     
    awesome!

    Can you do the same for plurals? ;-)
  • Dr. Fridemar Pache
     
    Hi wade,

    even, if you don't make EachCamelCaseWordAnAutomaticTag in an annotation, saving the user from the stupid work, to rewrite/copy+paste them each in the tag-list....

    ...please, please make them at least simple automatic Google-searchlinks. (In addition you can make them later double-links [one pointing to some internal or external host WikiDatabase, and another one pointing to Google's or another database].)

    Google really indexes very,very long Tags as you can verify in http://google.com/search?q=GoogleTagWiki , take the first Meatball entry.
    These search-words are not buried under thousand other irrelevant hits.

    The longer the mixed-case tags, the more precise, the more probably it becomes, that community-oriented cooperative people can find each other via Google to collaborate via the Web in a very profound way.

    And Diigo could take a leading position in Web 2.0.... But don't sleep to long.
    As soon as Google realizes the idea itself with built in micro-payment, then it has the better cards.

    I hope, that not all is lost.

    Fridemar


    wade wrote:

    > well, we are making it even smarter than what you want :-)
  • Graham Perrin
     
    > tag case will be preserved while displaying, but ignored for search

    Seems to work well for the majority of use cases. Thanks :)

To Top

Start a New Topic » « Back to the Diigo Community group