case-sensitive tags - any chance of it happening? - 383 views
started by jeffreyjflim on 27 May 07
started by jeffreyjflim on 27 May 07
started by jeffreyjflim on 27 May 07
started by jeffreyjflim on 27 May 07
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.
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. ...
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.
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.
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 :-)
> 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...
Actions
Add Comment
Delete
Highlight
Help...
Comments from the Diigo community
by fridemar less than a minute ago
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
...
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.
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
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.
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...
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.
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.
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.
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
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
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
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.
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.
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.
Can you do the same for plurals? ;-)
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 :-)
Seems to work well for the majority of use cases. Thanks :)