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.
Public Stiky Notes
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
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.
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.
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
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
Advantages
programmer too, knowing how powerful this option for "identifiers" is)
DiiGoForums and annotations (in which case as an example our
contribution would be much more valuable for the social annotation
community)
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.
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...
annotation wiki SupportingTheCase MixedCase SocialBookmarking SocialCooperation WikiCommunities AutoTagging
Hopefully the system doesn't "swallow" them. -- 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.
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.