I make the sticky note on your last comment: "Strange, but I don't notice any hiLites. ...  I wonder, what happens, if you modify or delete your last entry. I suppose, that the hiLite becomes an ordinary comment. I also clip the whole space, i.e. archive it and you should be able to see it. If not, try yourself to clip it and let's see, what comes out.. .--Fridemar

Hana, do you use the newest download from diigo.com?

A work around is, copy the old edit, delete it, and make a new annotation, based on the old one, pasting and editing it.

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

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.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.

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

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

This is a subset of a SocialCommonWealth, where wealth is created and
shared by the peers of online-communities, that tag  under
WikiCommonWealth.

WikiCommonWealth
SocialCommonWealth

This page has the DiiGo tags: "StayPoor", "CreatingAndSharingWealth" and at the same time it is a TrailMark in the wiki-mode FireTrail, next to the right of this DiiGo annotation. It is intended to foster open SocialCollaboration communities, that include a revenue model for their members. -- fridemar

Trails can be subscribed. Could someone please leave a link here, where this can be done?

By the way, I just made this a Diigo annotation within Trailfire annotation.
Currently I don't see this feature a Diigo: making a TrailFire annotation within a DiiGo annotation.

I just noticed, that Diigo comments within Diigo annotations cannot be edited. Right? Or did I miss something. So my corrected text follows:

By the way, I just made this a Diigo annotation within a Trailfire annotation. Currently I don't see this feature at Diigo: making a TrailFire annotation within a DiiGo annotation.

by fridemar less than a minute ago

By the way, I just made this a Diigo annotation within Trailfire annotation.
Currently I don't see this feature at Diigo: making a TrailFire annotation within a DiiGo annotation.