case-sensitive tags - any chance of it happening? - discussion,tag - Diigo Community | Diigo Group Forum

This link has been bookmarked by 2 people . It was first bookmarked on 28 May 2007, by Dr. Fridemar Pache.

30 May 07

Hans Wobbe
diigo.tags Bp!we
- case-sensitive tags
- Thanks for both of your input.
- womderful
- demonstrate the potential by simply designing a layout
2 more annotations...
28 May 07

Dr. Fridemar Pache
annotation autotagging mixedcase socialbookmarking socialcooperation supportingthecase wiki wikicommunities
- SupportingTheCase
 - 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
 Add Sticky Note
- - <a href="http://google.com/search?q=SupportingTheCase">SupportingTheCase</a> 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 <a href="http://google.com/search?q=DiigoAffiliatedBookmarkingServices">DiigoAffiliatedBookmarkingServices</a> would restrict their engines on not-case-sensitive, this would be not a serious problem to stick to <a href="http://google.com/search?q=StrongCaseSensitivity">StrongCaseSensitivity</a> You could transfer to them the <a href="http://google.com/search?q=MixedCase">MixedCase</a> 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 "<a href="http://google.com/search?q=IBM">IBM</a>" (TM), the trademark of this computer-company and "<a href="http://google.com/search?q=iBM">iBM</a>", a possible rival product of IBM to the <a href="http://google.com/search?q=iPOD">iPod</a> 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 <a href="http://google.com/search?q=DiigoEngine">DiigoEngine</a>. You see not only communities of programmers will have an enormous gain, when using <a href="http://google.com/search?q=CaseSensitiveTags">CaseSensitiveTags</a>, correctly handled by the <a href="http://google.com/search?q=DiigoEngine">DiigoEngine.</a> 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 <a href="http://fridemar.com">fridemar</a> PS.:  A simple realization for Diigo-, Trailfire and other social annotation services for <a href="http://google.com/search?q=AutomaticTagging">AutomaticTagging</a> is given in the above text by manually making transforming all <a href="http://google.com/search?q=WikiWords">WikiWords</a> into <a href="http://google.com/search?q=GoogleSearchLinks">GoogleSearchLinks</a>.
 - <a href="http://google.com/search?q=SupportingTheCase">SupportingTheCase</a> 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 <a href="http://google.com/search?q=DiigoAffiliatedBookmarkingServices">DiigoAffiliatedBookmarkingServices</a> would restrict their engines on not-case-sensitive, this would be not a serious problem to stick to <a href="http://google.com/search?q=StrongCaseSensitivity">StrongCaseSensitivity</a> You could transfer to them the <a href="http://google.com/search?q=MixedCase">MixedCase</a>
 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 "<a href="http://google.com/search?q=IBM">IBM</a>" (TM), the trademark of this computer-company and "<a href="http://google.com/search?q=iBM">iBM</a>", a possible rival product of IBM to the <a href="http://google.com/search?q=iPOD">iPod</a>
 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 <a href="http://google.com/search?q=DiigoEngine">DiigoEngine</a>. You see not only communities of programmers will have an enormous gain, when using <a href="http://google.com/search?q=CaseSensitiveTags">CaseSensitiveTags</a>, correctly handled by the <a href="http://google.com/search?q=DiigoEngine">DiigoEngine.</a> 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 <a href="http://fridemar.com">fridemar</a> PS.:  A simple realization for Diigo-, Trailfire and other social annotation services for <a href="http://google.com/search?q=AutomaticTagging">AutomaticTagging</a> is given in the above text by manually making transforming all <a href="http://google.com/search?q=WikiWords">WikiWords</a> into <a href="http://google.com/search?q=GoogleSearchLinks">GoogleSearchLinks</a>.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.
 Add Sticky Note
- AllLowerCaseModeForTagsAsOption:
 - 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 <a href="http://fridemar.com">fridemar</a>
 Add Sticky Note
- alllowercasemodefortagsasoption
- WikiAnnotationByTransclusion
- AnnotationInWikisByTransclusion
 - <a href="http://google.com/search?q=WikiAnnotationByTransclusion" _fcksavedurl="http://google.com/search?q=WikiAnnotationByTransclusion">WikiAnnotationByTransclusion</a> Hello Dear Maggie, dear Hans the idea of combining annotation with transclusion is an excellent idea of <a href="http://google.com/search?q=HansWobbe" _fcksavedurl="http://google.com/search?q=HansWobbe">HansWobbe</a>. This solves several problem with one clap: *
 <a href="http://google.com/search?q=UrlBasedAnnotation" _fcksavedurl="http://google.com/search?q=UrlBasedAnnotation">UrlBasedAnnotation</a>: now each annotation can have it's own Url like
 <a href="http://google.com/search?q=FireTrail" _fcksavedurl="http://google.com/search?q=FireTrail">TrailFire</a> does it, but with the added advantage, that those
 <a href="http://google.com/search?q=WikiPageUrl" _fcksavedurl="http://google.com/search?q=WikiPageUrl">WikiPageUrl</a>s have the form: <a href="http://google.com/search?q=WikiPrefixColonFollowedByWikiPageName" _fcksavedurl="http://google.com/search?q=WikiPrefixColonFollowedByWikiPageName">WikiPrefixColonFollowedByWikiPagename </a>and
 not only coded by cryptic numbers. So the readability in
 <a href="http://google.com/search?q=GoogleSearchResults" _fcksavedurl="http://google.com/search?q=GoogleSearchResults">GoogleSearchResults</a> is improved. * <a href="http://google.com/search?q=GlobalWikiEngineSupport" _fcksavedurl="http://google.com/search?q=GlobalWikiEngineSupport">GlobalWikiEngineSupport</a>: ** <a href="http://google.com/search?q=EachWikiAnnotationAsPartialPageOrFullpage" _fcksavedurl="http://google.com/search?q=EachWikiAnnotationAsPartialPageOrFullpage">EachWikiAnnotationAsPartialPageOrFullpage</a> 'quite normal windows, no more tiny stickies, that must be manually resized.' ** <a href="http://google.com/search?q=EachWikiAnnotationWithLookAndFeelConserved" _fcksavedurl="http://google.com/search?q=EachWikiAnnotationWithLookAndFeelConserved">EachWikiAnnotationWithLookAndFeelConserved</a> * <a href="http://google.com/search?LocalWikiEngineSupport" _fcksavedurl="http://google.com/search?LocalWikiEngineSupport">LocalWikiEngineSupport </a>'where each wiki word is tagged automatically as a <a href="http://google.com/search?TagWiki" _fcksavedurl="http://google.com/search?TagWiki">TagWiki</a>' The
 main advantage appears to be using host wikis as source for
 <a href="http://google.com/search?RichLinkContext" _fcksavedurl="http://google.com/search?RichLinkContext">RichLinkContext </a>and <a href="http://google.com/search?NestingOfAnnotations%20" _fcksavedurl="http://google.com/search?NestingOfAnnotations%20">NestingOfAnnotations </a>in the sense of <a href="http://google.com/search?KaPingYee" _fcksavedurl="http://google.com/search?KaPingYee">KaPingYee</a>, who
 invented <a href="http://google.com/search?WebAnnotation" _fcksavedurl="http://google.com/search?WebAnnotation">WebAnnotation</a>. This means each <a href="http://google.com/search?WikiPage" _fcksavedurl="http://google.com/search?WikiPage">WikiPage </a>itself can be
 annotated or edited, thus <a href="http://google.com/search?CreatingSpaceForSocialCollaboration" _fcksavedurl="http://google.com/search?CreatingSpaceForSocialCollaboration">CreatingSpaceForSocialCollaboration</a>. Some people may object, if you have a <a href="http://google.com/search?WikiPage" _fcksavedurl="http://google.com/search?WikiPage">WikiPage</a>, you don't need annotations. If millions of peers of the social annotations communities, would edit the <a href="http://google.com/search?WikiPedia" _fcksavedurl="http://google.com/search?WikiPedia">WikiPedia</a>, what a mess. Unobstrusive annotations solve the problem. <a href="http://google.com/search?MayAllBeHappy" _fcksavedurl="http://google.com/search?MayAllBeHappy">MayAllBeHappy</a> -- <a href="http://fridemar.com" _fcksavedurl="http://fridemar.com">fridemar</a>
 Add Sticky Note
4 more annotations...

Public Stiky Notes

Dr. Fridemar Pache on 2007-06-01

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
Dr. Fridemar Pache on 2007-06-07

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.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 on 2007-06-07

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 on 2007-06-03

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 on 2007-06-08

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 as 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.
Unobstrusive annotations solve the problem.

MayAllBeHappy

-- fridemar

Page Comments

Dr. Fridemar Pache on 2007-05-28
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.

MayBeAllHappy

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, AnnotationTitlesAsWikiPages , AutoTagging, so that you can find it by searching it via DiiGo.

jeffreyjflim wrote:

>
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 on 2007-05-28

Note: Although I tagged in MixedCase, the current DiiGoEngine, made them all lowercase. What a gain, if case would be preserved. Thank you for changing this.
Dr. Fridemar Pache on 2007-05-28

Now that all tags are lowercase, they should show up, when searching them via DiiGo.
Dr. Fridemar Pache on 2007-06-01

I added the following public tags:
annotation wiki SupportingTheCase MixedCase SocialBookmarking SocialCooperation WikiCommunities AutoTagging
Hopefully the system doesn't "swallow" them. -- fridemar
Dr. Fridemar Pache on 2007-06-07

Posted by
fridemar
on 6/7/2007

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.

case-sensitive tags - any chance of it happening? - discussion,tag - Diigo Com... - The Diigo Meta page

Would you like to comment?

Top Tags

Check out another URL