DiigoTrailfireWikiCollaboration
Trails you can add marks to (including your own) are marked with the pencil icon.

A trail of 17 pages, marked with comments, by fridemar
About this trail:
DiigoTrailfireWikiCollaboration

The initiator of a group at Diigo with this name , which is at the same time a MixedCaseTag , opened this WikiTrail to stimulate collaboration between the two great social annotation communities and diverse wikis.

As this AnnotationEngine is not yet a TagWiki, the author presets all wiki words manually to GoogleSearchLinks.

This FireTrail started in the midst of some discussions on the DiigoGroupForum
The following pseudo-links are made to illustrate, how much work could be taken away from users of annotation systems, if the software itself transformed any WikiWord automatically into a LongTag  or into a GoogleSearch. (Estimated less then 100 LOC Lines of Code)


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
17 marks in this trail
1
DiigoTrailfireWikiCollaboration

The initiator of a group at Diigo with this name , which is at the same time a MixedCaseTag , opened this WikiTrail to stimulate collaboration between the two great social annotation communities and diverse wikis.

As this AnnotationEngine is not yet a TagWiki, the author presets all wiki words manually to GoogleSearchLinks.

PS.:
The author also detected to use linkrich wiki-texts, to copy them into annotations, that reserved richtext formats. See Meatball: WikiMark
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
3
DiiGo TrailFire Wiki Collaboration is a win win situation for all parties involved.
5
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.
7
See the tags under TrailFire, from whom we can learn a lot.

Suggestions:

(1) Add trails to the diigo annotation system to make
WebRingsOnTheFly.

(2) Add at least the reduced wiki-mode of FireTrail to Diigo.

(3) Get rid of the 5000 words barrier for clipping. (On TrailFire it is not a problem to make a html-snapshot of a whole wikipage. This is an excellent backup mechanism and doesn't harm the original life wiki page, that could have changed in the meantime. Of course you need the consense of all involved wiki-authors of the page. No problem for heavy duty authors, who initiate a lot of pages.)

(4) Offer only rich-text input fields (in Wysiwyg and in HTML text-mode) as TrailFire does it.

(5) Make sharing-in public the default. It's always a nuisance to lose time for rechecking for privacy-mode=public. We are primarily a social annotating community, aren't we.

(6) Make a true RecentChanges (and not only a "hot topic RecentChanges", which looks like censorship) Most of the time I didn't see my contributions in the general RecentChanges.

(7) Make each annotation an UrlBasedAnnotation, just as TrailFire did.
This way, annotations can talk to each other, by linking to their MarkUrls. And they show up in Google.
8
Hi donalconIon, hi Maggie,

thank you donalconion for this excellent suggestion.
LongMixedCaseTags are really helpful to connect clear cut concepts in different social communities.

They appear indispensable for open SocialCollaboration (and IntraCorporateCollaboration too).

By the way, what about not only allowing long tags, but making the tags sensible to uppercase and show them in CaseSensitive form. This way the readers can overlook them at least twice as fast.

MayAllBeHappy

fridemar

PS.: For the sake of widest open SocialCollaboration, specially for DiiGoTrailFireCollaboration, I make my posting a TrailMark annotation too and tag this accordingly.
10
You are here: Groups > Diigo Community > Forum > View Topics +New Topic Delete Topic

New Group: DiiGo TrailFire Wiki Collaboration collaboration diigo trailfire wiki Enable Email Notification

  • #1fridemar said ...(less than a minute ago )

    fridemar
    Dear Diigos, dear Maggie:

    it's a great feature of Diigo: Diigo groups.
    I am wondering, why this tool for focussing on a special area of interest is not used more widely.

    So I opened a group, that has its roots all over the web. This group is for cross-fertilizing and hopefully a fast growing plant, where all participants may care for and enjoy the fruits.

    DiiGoTrailFireWikiCollaboration

    MayAllBeHappy
    Fridemar