More I think about RFID, more doors open up.  While thinking about the privacy issues rising from associating RFID with a person via purchase records, I thought of a couple of unique ways RFID might be used.

One idea is to record RFID tags on people and things moving in and out of an area through gates.  An alarm is raised when an unknown RFID is detected within the area.  Software is simple, just a database of RFID tags with optional good-til timestamp so Pizza can be delivered within the area.

Another idea is to use a set of RFID for authentication like "Please Wear Yesterday's Underwear to Authenticate".  Seems silly at first, but requiring a minimum number of RFID known to be owned by a person or asking for a specific RFID to authenticate is not entirely useless.

Update #1:

Alient Technology RFID tags can be read 15 feet away.  That's enough to cause concerns.  In fact, I think RFID tags with wider range than average 'personal space' is of concern.  RFID tags with smaller range usually requires violation of personal space like waving a hand-held metal detector around your person.  Of course, hidden readers like 'shoe-readers' embedded in a line of bricks along a walking path is a problem.

Perhaps some legislation is necessary to require readers to be clearly marked and readers for RFID tags with wide range be licensed to be usable within specific areas.   Requiring RFID readers to have embedded long range RFID tags is can help so one can walk with a RFID detector and not worry about RFID readers.  Same can be used to make sure long range RFID readers stay where they are licensed to operate.

Another thought is that 'Opt-Out' RFID tags might be a good compromise.  I could wear one as a necklace and it could tell RFID readers to ignore any RFID tags I might have on.  Again legislation is necessary so this behavior can be built-into RFID readers.

Mark Roseman of CourseForum Technologies, a commercial Wiki vendor, contributed via e-mail, his perspectives on the ongoing discussion over commercial vs. open source Wiki products and comments on using Wiki for blog comments.

The response from Ross about Socialtext touched on what a commercial system (like theirs or ours) can offer. As you say, issues surrounding support, hosting, integration, documentation etc. are fairly obvious. Let me elaborate a bit more about a few things.
Ease of use
Tools like TWiki do a reasonable job of covering the 'geek' market, but when it comes to making tradeoffs about adding more power features vs. keeping things simpler and more accessible, tend to lean towards the former. Our system tends to keep the markup simple, add features designed to help new users such as preloading forums with some default content, page templates, allowing people to post comments without going through the full edit interface, etc.
At the same time, the system is fully featured to suit what people need to do, has things like user tracking, decent security models, versioning, archiving etc. that aren't necessarily fun to code but are needed when Wiki's are used in "real" environments. But the application as a whole is designed in a way that features are presented in an accessible but not obtrusive way. You don't always get that mindset from developers who haven't done a lot of commercial systems before (ok, or some that have!).
Ease of install/setup/admin
This is one area where the open source packages usually fall down, because they rely on many other packages which must be installed and configured.  Something like Twiki usually needs setup of Apache, configuring MySQL databases, various other modules, setup CVS to do version control, etc. Further, most of the configuration is done through manually editing configuration files or variables at the top of code files.
We like to point out this article about what is usually involved as compared with ours (just double click a single executable, no configuration needed, and later administration done via a web-based interface).
On top of the configuration hassles and software dependencies, most of  the open source systems are fairly platform-specific; one differentiator for ours is that it runs well on not only Unix, but also Mac and Windows.
This (and the previous point) really help bring the whole Wiki concept to a much wider audience; going in to configure software and then making it hard to initially figure out really restricts who can take advantage of the software (and we've had more than a few hard-core geeks buy our stuff after getting frustrated trying to get Twiki or similar systems installed!)
Multiple workgroups
Most Wiki's grew out of personal use projects hacked together (your comments are astute; rip everything away and there isn't necessarily much there).
As such, they tend to hardcode a lot of assumptions. Many of these mean that its very difficult to setup multiple separate workgroups/wikis on a single server, or that you need to install multiple copies of the software to do so. Changing that would be a major redesign (and its not an issue for most of the open source developers working on those systems).
In ours, multiple distinct workgroups can seamlessly exist on the same server; this was designed in from the start and is important for our target audiences (in most places you'd have one person maintaining a server for a lot of other people, rather than everyone running their own copy of the software).
Wiki's replacing blog comments
I think this is on the right track. We've seen a comparable thing in our educational product, where instructors would post slides from a lecture on a Wiki page, and then students would post their comments and questions on the same page. The parallel with blog posts and followups is fairly natural.
The sticking point with doing this for a lot of Wiki's is that you don't necessarily want people deleting or changing each other's comments. Some of the more advanced Wiki's would help with this. In ours for example, you can:

• make it so that people can post to the end of the page but not edit existing contents
• have a more closed forum where users are authenticated
• track a history of changes to the page, so if something was deleted or changed, you can find out what, when and who did it

Bottom line
Ok, I think I'd better stop before I overwhelm you. 🙂
But I really do want to second Ross' comments about commercial Wiki's complimenting rather than competing with open source alternatives.  I've been working on collaborative systems for a long time, and was really impressed with the potential inherent in the core Wiki idea (no matter, or perhaps because of, how simple that idea is).
What we're trying to do is take that core idea and make it a lot more accessible, bringing it to a wider audience, people who would never really be able to benefit from it with existing tools.

FYI, CourseForum Technologies has two products: ProjectForum for business (demo) and CourseForum for education (demo).  There is also a large public project based on their software.

After reading News.com's Retail takes stock of radio tags article, I wondered what the US government might be doing with RFID to stem waste in government.  US government is monsterously wasteful, particularly the military, and could potentially benefit from using the RFID technology.  I doubt today's RFID tags can be placed in each bullet or even artillery shell, but other items should be tagged and accounted for.

Same goes for the medical and insurance industries.  Knowing the location and quantity of medical supplies matters to hospitals.  Knowing where insured objects are matters to a insurance company.

What about the waste management business?  I could see RFID information collected by garbage trucks being valuable to some one.  This brings up the idea of RFID information market.  In the future, RFID data harvesters will not necessarily be the RFID tag planters.  If information has value, it can be sold and a market is needed.

Speaking of RFID, I recently found out that "Dave"'s younger brother Peter Winer is deeply into RFID.  Peter is CEO of Big Chief Partners, Inc, a RFID expertise provider.

Hey, Peter.  Restart your blog so we can all learn about RFID.

In my Bleeding Edge of Wiki-Blog Hybrids post, I wrote:

There is also Socialtext, of course, but I don't know what differentiates their commercial Wiki implementation from popular free open source Wiki implementations other than service.  Perhaps Ross or Peter can explain.

Ross Mayfield, CEO of Socialtext, responded by explaining how Socialtext's commercial product is different from open source wikis in Commercial and Open Source Alternatives.

1. Simpler and easier to use
2. Fully integrated wiki & weblog
3. Administration capabilities
4. Support for multiple workgroups
5. Extensions
6. Integration with enterprise systems
7. Secure hosted service
8. Optional Appliance deployment
9. Service & Support

In closing, he wrote:

We don't compete against open source alternatives, we compliment them.

<

p dir=”ltr”>While appreciate Ross's response, most of the difference he pointed out are what I expect from commercial products.  I would like to understand #1-5 in detail.  I guess the bottom line question is: how does Socialtext differ from taking TWiki and adding #6-9?

My posts managed to send Michael Wilson in pursuit of Wiki API.  Keep abreast of his progress on his Programming Projects blog and read his first post on the subject titled WikiRpc Blathering v0.1.

Update 7:32 PM:

Joe Gregorio is deconstructing Atom API to see how it might be applied to wikis.

This is contiznuation of my Linking Blogs and Wikis  post.  Other related posts are Blogging to Wiki and Bleeding Edge of Wiki-Blog Hybrids.

Using a Wiki Page for Blog Comments

I think wikis can replace blog comments right away.  Most blog comments are text-only so use of wiki text formating rules and WikiWords is optional.  When a comment about a post is received either directly from blog tools/services or indirectly via a spider, monitor, or another blogger, receiving script can create or find a wiki page to add the comment and the original post to the page.

One great benefit is that comments are no longer second class information: isolated, unindexed, and often overlooked.

Wiki to Trackback and Congregate

The script can also walk through links mentioned in the comment or original post to discover related blog posts and drop a comment as breadcrumb for other bloggers to follow.  This functionality is like trackback but with added benefit of congregating bloggers and commenters to a shared space.

Duplicates

There is the possibility of multiple wiki page being created for a single 'conversation', but most of them should be mergeable automatically.  Still, more thought is needed here.

Blogs within Wikis and Pageroll

In wikis I have seen, some users create a personal wiki page mapped to the user's name as WikiWord, where users can add personal information there.  There is also a way to retrieve a wiki page containing the history of a user's activity within the wiki.

I think these pages can be redesigned to resemble a blog with its own set of RSS feeds.  User activity history can become a category within that blog.  Auto-population of blogroll is also possible here with names of people the user interacted with.  In this context, wiki pageroll listing wiki pages the user frequents makes sense.

My brain is still humming with thoughts on ways to combine blogs with wikis.  Between the two technologies, Wiki is the fragile one so I am trying to take extra care not to kill the humming bird.  Stay tuned.

Update: Richard MacManus responds with Tracking conversations with Wikis and Extending blogrolls.  Sheesh.  I wouldn't have to do this by hand if Wiki replaced both blog comment and trackback.

Janne, author of JSPWiki, reveals what is going on at the bleeding edge of Wiki-Blog hybrid technology.

"First, a short explanation on the tech behind this weblog: This is an instance of JSPWiki, where each entry is a separate WikiPage?. The Main page aggregates then all of the pages which have a certain signature in their name onto the front page, producing the weblog you see right now. This allows cool stuff like doing collection pages, such as Ropecon2003, or EGC2003, where I just insert a string like [{WeblogPlugin startDate='310103' days='31'}] to get all of the entries from January 2003, for example." – Butt Ugly

In essence, JSPWiki is a Wiki with the ability to pull together a blog-like page out of Wiki pages.  Throw in page template to add style and other blogging essentials like calendar and blogroll, you got a blog.  Neato.

Janne also talks about his XML-RPC-based API for JSPWiki.  JSPWiki also supports MetaWeblogAPI.  Les Orchard, Mr. 0xDECAFBAD, has implemented the API for TWiki, UseModWiki, and MoinMoin.  Les is considering REST version currently.

On the syntax front, Janne mentioned the WikiML initiative by Eric van der Vlist, an old pal from my XML/SML days.  There is also WikiXmlDtd effort by UseMod folks.  Wiki Interchange Format page is also worth a read.

<

p dir=”ltr”>Based on my recent scouring of the Wiki technologies, JSPWiki (Java/LGPL) and TWiki (Perl/GPL) are worth keeping an eye on, JSPWiki on the wiki/blog/api front and TWiki on the extension front.  There is also SocialText, of course, but I don't know what differentiates their commercial Wiki implementation from popular free open source Wiki implementations other than service.  Perhaps Ross or Peter can explain.

Some folks are experimenting with using Wiki to build websites.  I particularly like what Matt Haughey did with PHPWiki and a bit of CSS magic dust.  Looks nice, eh?  [Via Seb's Wikis are Ugly? post at Corante]

Janne Jalkanen's Wiki-based Weblog is interesting too.  Hmm.  Maybe blog API(s) can be used for Wikis too.  That reminds me, shouldn't Wiki formatted text have their own MIME type?  Is there one?  "text/wiki"?  For now, different dialects of Wiki formatting rules will have to be accounted for like "text/wiki+moinmoin".

Update #1: I found this nice page listing Wiki and Weblog hybrids.