Just Find the Best Tools for the Job

I find the Enteprise 2.0 adoption discussion very interesting, and it brings to mind some lessons I had to learn the hard way.  I come from the geek mindset, where the tool itself is what is cool, because I use them directly, I read about them, and sometimes I even build them.  I get very excited thinking about semantic Web technology, tagging, user-generated content, federated identity, etc, etc.  But it took me a long time to realize that technology is just a tool, not a solution.  I get excited thinking about all the possibilities, not necessarily about solving a problem.  It’s a problem I have, and I’m working on it :)  But really, if all you have is a problem, to a large extent you don’t really care about the tool as long as it gets the job done.  I think geeks like me tend to lose sight of that, and the result is vaporware and eventual disillusionment.

Imagine if Home Depot sold Web 2.0 tools.  You could walk in and pick up an automatic tagging tool, a user-generated video tool, a rapid AJAX-ifier, social networking connectors, an RSS attachment, and of course the handy rounded-corner router.  Well, I can’t see Home Depot going and trying to sell these tools to companies that weren’t looking for them any more than they would hit the streets to hawk the newest hammers to carpenters that had no need for them.  The customer comes to them for the tools they need, not the other way around.  You don’t shove the tool down people’s throats, you wait for them to see the value in it and ask for it.  Otherwise, you’re just a glorified traveling salesman trying to sell a better mousetrap.  No Soliciting.

So, to be honest, I really don’t care when someone looks up from their beer and shouts “Eureka!  There’s no tagging for the enteprise yet!”.  There’s no YouTube for the enterprise either, that doesn’t mean there’s a hole begging to be filled.  Yet.  Unfortunately, end users take time to digest new technology before they realize they need it—before they can put the pieces together and realize that this tool solves that problem.  That’s why the dot com-boom of the 90’s turned into a dot com-bust.  It wasn’t because the technology was bad, people just didn’t realize the value yet.  That’s how I see the relationship between Web 2.0 tools and the enterprise right now.

The true secret to new tool adoption lies in the cross-functional geek.  IT folks who are not only good at what they do, but are also familiar with the business itself.  They probably even came from the business side but moved over to IT because they saw how to apply the tools there to solve real problems.  Those guys are worth their weight in gold, and if a geek is ever able to truly be successful he needs to be able to put himself in that person’s shoes.  THAT is when Enterprise 2.0 will happen.

A World-Wide Semantic Social Network

Yahoo Answers and similar “question and answer” sites have been getting a lot of publicity lately.  While I’m not too keen on the current incarnation of these sites—they seem like nothing more than glorified database applications to me—it strikes me that this is the PERFECT application for social networks and a bastardized version of the semantic Web using microformats.  (Oh and by the way, anyone from the semantic Web crowd who reads this, I'd love to see if there's a way to make RDF work for this as well, I seem to have trouble wrapping my head around the practical applications of it so any help is appreciated!)

First a word on social networks:  iIf you read my weblog regularly you’re probably aware that I’m not a fan of the closed, proprietary social networks that are in use now.  Instead, I believe that social networks should be a loosely-coupled, organic collection of individual and business Web sites that form a social network.  The missing piece, I think is the semantic Web part--a data layer that can extract structured data from the member sites.

What does this have to do with answering questions?  Well, it occurs to me that what I really want to do when I ask a question of the Internet is pretty much along the lines of what Yahoo Answers is talking about doing, that is, see if anyone in my network has answered a question.  Essentially filter the Internet down to your trusted sources and look within that network of people for your answers.  Be your own filter.

The problem with the Yahoo solution is that it’s a closed system.  In order to ask or answer questions, you have to use Yahoo’s system, and you’re locked in.  And anyone who is providing an answer also has to use the system, which means that the probability you're going to find an answers dwindles because of the closed nature of the system.  There really isn’t a “network”, per se, except for the one that exists in Yahoo’s database.  The ideal solution to this problem, in my mind, is simply to create a network of trusted sites, a la Google Custom Search, and use a Microformat parser along with an extended set of Microformats to extract “answers” and “questions” from the sites.  All you’d really need is a set of microformats to delineate  “question”, “opinion”, “fact” and so on.

The only technology that would really be necessary to make this work is to embed microformats in site text itself.  I’m really not sure why this hasn’t taken off yet, it seems like a no-brainer to me.  What I’m talking about, and I’ve actually posted some working examples of this before, is to surround chunks of text from a weblog post or text published to a public site with microformat markup so that it can be extracted as meaningful data:

<span class="vopinion"><span class="question">What is the shape of the earth?</span><span class="answer">The earth is a flat octagon, I tell you, I've seen a corner!</span></span>

It really amounts to nothing more than coming up with some standardized CSS classes that can be used to mark up text with some more meaningful data.  I’ve really only seen microformats used as standalone information islands up to this point, such as embedding hidden contact information in an about page, which seems a crying shame and a waste of opportunity to me.  If people were to start marking up the text they publish with semantic data so that the underlying meaning could be extracted and searched, we would no longer be depedent on Google to extract that meaning for us.  Instead of asking Google for an answer, I could just ask the sites in my social network for an answer.

I guess I just don't see why we can't pick the low-hanging fruit and mark up the text we all write with richer data.  Entering things in database is all fine and dandy, but wouldn't it be better if the databases automatically extracted their data from the freeform text we all write on our sites and weblogs?

Microcontent Viewer Source

At the request of a few different people, I've zipped up and made available the source code for the microcontent viewer/Live Clipboard proof of concept I posted a few months ago.  Everyone interested can find it here.  Enjoy.

Idea #19: Take a look at MicroFormats

One of the more interesting technologies that I've noticed emerging in the past year or two is the concept of Microformats.  Essentially what microformats provide is a standard format for embedding XML data in textual content.  What this allows us to do is embed actual data in content and then automate data extraction.

There are already a ton of companies implementing this technology--you can use it today.  A lot of semantic Web people don't like it because it's far more unstructured than technology like RDF.  However, you can't argue with the fact that it's being used.  And the main reason, in my opinion, is that it gives people a concrete method to use them, unlike RDF, whose definition is very hazy when you try to wrap your brain around it.  There are a ton of standard microformat schemas that you can use and they'll start working immediately.

For an example of what microformats can do, you may want to check out the Microformat viewer I posted a while back.

Part of the 60 Ideas in 60 Days series.  Click here for the rest of the ideas.

Using, Sharing, and Securing Rich Data on the Internet using Online Identity

It makes me a happy boy to see dialogue occurring on the best way to share and syndicate rich data publicly on the Internet.  I truly believe that when this bridge it crossed it will enable the next wave of Internet technology evolution/revolution, and I'm glad people are thinking in this direction so this happens sooner rather than later.  I also think Live Clipboard will be a nice catalyst for the whole idea because it empowers microformats in such a dramatic way.  All of this technology is still in its infancy, of course, but these are the types of conversations that need to happen between early adopters, developers, and entrepreneurs before it can go mainstream.

One thing that seems to keep coming up, and understandably so, is the idea of securing syndicated data.  For example, if I wish to publish certain parts of my contact information such as my email address, but keep other parts private and secure, such as my mobile number, I can't very well publish a vcard out to the Internet.  Even hiding certain chunks of it with stylesheets won't hide the content from aggregators, search engines, and people who know how to "View Source".  It's simply not an effective security mechanism.

Related to this is the sticky question of whether the data should be embedded directly in the content (or page) itself, or if the content should simply contain a pointer to the data (in the form of a URI).  The first approach is demonstrated in my little Microcontent Viewer example from a few weeks back, the second approach is demonstrated by i-Tags.

The concept of embedding data in content and how to secure it is a tough one, and I struggled with it for a long time.  I wondered if the URI-only approach was correct so that it could actually be an application at the other end of the URI which would be able to ask the reader who he was and provide the appropriate subset of data.  However, that raises all kinds of problems with user authentication and firewalls.  For example, if I publish a blog post that contains a vcard which points to a URI inside the firewall, that vcard becomes useless to anyone on the outside, so what's the point.

Personally, I finally decided a few months back that a hybrid approach was needed:  I would embed only the public data that anyone should be able to see into the content itself, but also provide a URI that can be used to retrieve the full set of data (or the subset that the reader has been allowed to see).  It could also be used by the reader to refresh the embedded data when the URI endpoint is available and online.  This is exactly the approach taken by my Microcontent Viewer example, although the refresh piece isn't hooked up.

I'm still pretty convinced that embedding public data in content is a good way to go.  After I published my test post Technorati picked up the embedded microcontent and I was able to find it using their microformat search, and get pictures and all.  See the results here.  It actually added value to the content, which was very cool.  Progress!

The URI endpoint part of this is much trickier, but is also much more interesting.  It's the secret sauce that's going to really kickstart some wild revolutions in online technology.  I believe that an open source application is needed to share, provision, and publish content at URI endpoint's, and that application is currently and secretly in the works but won't be released until it's ready.  For securing data, it uses an ingenious solution thought up by M. David Peterson to securely publish URI endpoints, see his post here for the technical details.

The beauty of this hybrid solution is that you can have your cake and eat it too.  Users who you don't even know exist can use the subset of your data that you make public, and public applications have data to work with but only that which you want the entire world to be able to see.  The embedded microcontent portion enables applications like the Technorati microformat seach to pick up  and use it.  However, if somebody wants to get to know you better, they can send you a request in the form of an LLUP message and you're then able to personally decide if you want to allow more information out to that individual or not, and at what level.

There are so many more goodies that this will enable in addition to fresh data.  You get to maintain an actual list of "trusted subscribers", and actually TELL them when you update or create content instead of waiting for them or their feed readers to find it.  You'll be able to tell EXACTLY what people are doing with your data.  You'll even have the ability to let THEM edit it, and tell you about it, at which point you'll be able to determine if you want to accept their changes or not.  (I can't wait for the day when somebody I trust can update their contact info from one of my blog posts and it will update all of my other blog posts as well as Outlook, Gmail, and my Blackberry.)  All the promises of push will be fulfilled when this domino falls.

Dion Hinchcliffe, a great writer and one of the few bloggers I make it a point to read on a regular basis, has done a wonderful job of outlining one of the primary barriers in front of this technology, which is the lack of a decentralized identity system.  A decentralized identity system is vital before we can even think about securely sharing data.  And while I certainly respect the efforts that are out there such as OpenID as SXIP, I think that the misguided efforts by companies like Microsoft and Google are going to derail any attempts to unify identity in the short term.  I think the catalyst for change is going to be the point in time when people can see actual tangible benefits from an decen tralized identity system, in the form of new capabilities that such a system baked into core software can bring.

I've got some great big surprises in store in this area in the very near future, but I won't release anything until it's polished and ready.  First impressions are pretty important, ya know ;)

Live Clipboard How-To for End Users

It's the kind of thing you don't really think about when you're knee-deep in code, but Live Clipboard is really a new paradigm for the Web and it takes a  while for people to adjust and digest everything, let alone use it effeciently.  After I posted my embedded microcontent/viewer post, I started realizing from the feedback that people didn't really know what to do with it.  This is an attempt to explain, in end-user terms, how to use Live Clipboard.

To use Live Clipboard you need two things:  content to copy (the source), and somewhere to paste it (the destination).  For this example I'm going to use the viewer I wrote layered on top of an HTML file with embedded microcontent as the source, and Ray Ozzie's Live Clipboard demo site as the destination.  You can follow along in your own browser if you'd like.

Step 1:  Copying Content

I'll be using http://www.xformats.org/MicroViewer/microContent.htm as the source.  It's an HTML file that contains embedded microcontent, and links out to the viewer I wrote, which means it ends up looking like this:

The blue box on the right contains the content that was extracted from the embedded microformats.  You can do other things with it such as map an address or make a call using Skype, but we're going to focus on the Live Clipboard button in the lower-left, which looks like a pair of scissors on an orange background: 

Copy Method 1:  Selecting and using Ctrl+C or the Edit Menu

There are two ways to copy the content using Live Clipboard.  The first, and what I assume most people will end up doing at first, is to click the icon, which selects the microcontent, and then either press Ctrl+C or go to the Edit menu in the browser and click Copy.  This basically acts just like Windows.  When you click the icon, the viewer will change the look of the box containing the microcontent to let you know that you can go ahead and copy the content using Ctrl+C or the Edit menu:

Once you use Ctrl+C or the Edit menu to copy the content, the microcontent gets stuffed into your operating system clipboard.  You can even look at it by pasting it into Notepad or something, but it won't make a whole lot of sense--it's meant to be used by a Live Clipboard destination.

What's interesting is that although I think this behavior is the most intuitive, most new users don't seem to realize that you can do it.  They all seem to end up using....

Copy Method 2:  The Right-Click Context Menu

With this method, you use the same icon as before, but you right-click it, bringing up the browser context menu:

Clicking "Copy" on this menu will also copy the microcontent to the clipboard.

Step 2: The content's copied, now what?

Now that the microcontent is on the clipboard, we need to paste it somewhere.  I'm going to use Microsoft's Live Clipboard demo site:

The list of boxes on the left are basically receptacles for storing microcontent.  Scroll down until you find an empty one:

You have two options now for getting the microcontent you copied to the clipboard into this receptacle (by the way, we really need a name for these endpoints).  The first option is to click the Live Clipboard icon to hightlight and then press Ctrl+V or use the Edit Menu to paste the content in.  This is what the receptacle looks like when it's selected:

Or, you can right-click the Live Clipboard icon and click the Paste menu item, like this:

After you do either of those things, the microcontent that you copied out of the other site will show up in the receptacle and look like this:

That's it, you're done!  You're now officially on the cutting edge of Web technology.  Now go demand Live Clipboard integration from your vendors ;)

P.S.  This is all developer technology preview-stage stuff, so you will probably notice some rough edges.  For example, sometimes I have to close my browser and re-open Microsoft's Live Clipboard demo site before I can successfully paste in content.  I'm sure this will be smoothed out in time, just giving you a heads-up.

P.P.S.  There has been some discussion lately on the Live Clip mailing list about the best way to visually indicate to users what they can do with Live Clipboard.  If anyone has any feedback in that area please share!

This is Not an Ordinary Blog Post

This post is a proof of concept--I've embedded microformatted content into the text of this post.  If you run this page thru a microcontent viewer you should be able to see and use the microcontent.  There aren't, to my knowledge, any viewers out there yet, so I ( this is my vcardJason Kolb jason.kolb@gmail.com 800 555 1212

) wrote a simple one that supports events and contacts (hcards and hevents).  Try viewing this post using the microcontent viewer I wrote using this URL:

• http://www.xformats.org/MicroViewer/default.htm?url=http://www.jasonkolb.c om/weblog/2006/06/this_is_not_an__1.html

Go ahead and play with the viewer a little.  Click the links, map an address, make a call with Skype, copy and paste contacts using Live Clipboard.  (Anyone who's never used Live Clipboard before should read this other post for a step-by-step.)  It's purely Javascript and CSS-based, which makes it very simple to plop on top of any AJAX application out there (including RSS readers).  It's also a small piece of a larger project I'm working on, but I wanted to throw it out there because I see a lot of misunderstanding right now about the potential of microformats.  Although I think it's very cool that search engines like Technorati are beginning to understand and aggregate microformatted content, that's only half the equation.  The other half is that we need to allow PEOPLE to use microcontent as well.  This post is an example of that capability.   Viewing this post with a compatible viewer gives the reader the ability to not only read the text, but to do things with the content as well.   (To my knowledge this is the only public text in existance right now with embedded microcontent, although I'd love to learn about some more examples!)

Using Microcontent

Admittedly, there aren't many fun things to do with microcontent yet. However, it's very enlightening the first time you move data around between applications using Live Clipboard.   Try copying a contact out of this post and pasting it into Ray Ozzie's Live Clipboard demo site.  Another site that supports Live Clipboard is M. David Peterson M. David Peterson m.david@xmlhacker.com 800 555 1212

's Global Clip demo (which is super cool because what you paste in gets stored in Amazon's S3 online storage service).  The sites that support Live Clipboard are a little rough around the edges at the moment, but I would assume that things will start coming together nicely over the next six months.

Here's an example embedded event just for kicks: Web 2.0 Conference

. Just to give you an event to copy & paste using Live Clipboard.

To me, this is what microformats promise.  They enable us to turn regular old content into rich media, with little to no effort on the part of content creators.

More Examples from Around the Web

Now, let's have a little more fun ;)  You can actually use the viewer I wrote to look at things other than this blog post.  You can either hit the viewer directly using http://www.xformats.org/MicroViewer or you can append the URL to the query string to automatically load up a page like I did with the link to this post earlier.  Go find some microformatted content and plug it in, here are some links to content that I found from poking around on http://www.microformats.org:

• http:/ /www.crowley.nl/hcard.html - An example vCard

• http://www.w3.org/People/Connolly/events/ - This one gets really crazy.  It has events with embedded vcards for speakers.  Looks like rainbow sherbert in the viewer.  Oooooh, pretty colors!  (Live Clipboard-compatible.)

• http://www.iowamilitaryveteransband.com/members/ - This one takes a while to parse, it's got quite a few contacts.

• htt p://www.jasonkolb.com/about.html - My vCard.

• You can also use http://microformats.org/code/hcard/creator to create your own vCard that can be embedded into text like I've done here.

Disclaimer:  if it doesn't work or your computer bursts into flames or you break out in a rash or something, tell me about it--but I accept no blame in perpetuity for anything :)  This isn't even beta software, this is like... whatever comes before alpha.  Also, people are doing lots of weird stuff with Microformats such as embedding <script> tags in them, so you'll often find that although the cards will render, they will choke Live Clipboard if you attempt to paste them into another site.  If you're technically minded, try pasting the contact into Notepad or something so you can fix it.

These links also aren't really examples of inline microcontent like this post is, unfortunately to my knowledge this is the first example of that on the Web.  If anyone has any other examples I'd love to know about them.

Technicalities

If anyone's interested I'll post some more technical information about all this, but I'm still refactoring it for broader use in actual products.  All of the code for this example is licensed under the Creative Commons Share-Alike license, so you're free to use and/or modify it if you wish.  I'm still adding to it and refactoring it quite a bit; however, I got it to a stable point and I figured I'd see what people thought of as it stands now.

Oh and by the way, listen up Microsoft:  we need an editor for this stuff.  If you really want to leapfrog the competition, do us all a favor and build Live Clipboard and microformat support into the next version of Word and Outlook.

Thoughts?

Home away from home

1600 Pennsylvania AveWashington DC 20500 USA

Started October 5, 2005

Ended October 7, 2005

Argent Hotel, San Francisco, CA

Work

350 Fifth AveNew York NY 10118 USA

Cutting Out the Middleware

With the looming rise of the clipboard to transport XML, disguised as a text and using Microformats, the use of the clipboard to transfer data from one place to another is just going to explode.  And by data, I mean full records including contacts, events, reviews, and eventually I'm sure, orders, invoices, quotes, and products.

The Live Clipboard vision gives users the ability to transfer data without having to rely on software.  It'll be the end of exporting and importing files from one program to another, or copying and pasting fragments of a record from one program to another.

The onus of keeping information secure will be almost entirely on the user, because he'll be able to share whatever information he has access to simply by copying say, an invoice, and pasting it into an email or instant message as microformatted HTML.

Here's how I see the market unfolding:

1. Social software sites will begin (and already have, see AimPages amd Yahoo Tech) adopting Microformats
2. Web commerce sites will begin accepting Microformats.  Amazon and eBay will probably be the first large sites that accept them, followed by PayPal at some point.
3. Microformatted content will be so readily available and easy to use that commercial enterprise software will begin to support it.
4. Since microformatted content is now so prevalent and easy to use that it's everywhere else, CxO's of smaller companies will start folding it into their internal development projects.
5. Once these all happen, users will be able to easily transfer data between the Web sites they use, the software they use, their personal records, and their job.

And something very cool will eventually happen where companies will be able to transfer data between each other using RSS (or ATOM) feeds filled with Microformatted content.  Synchronizing two databases on two different networks will no longer be a chore, but a 30 minute exercise.  Users will be able to email orders to their partners by copying and pasting them into an email (their partners would then hopefully be able to copy the order from the email and paste into their sales system).

Security will become an issue I'm sure, because this really places the onus of filtering what data is shared on the user himself.  A whole slew of new issues will spring up around that, simply because data will be so much more accessible than it ever has been, and software will no longer be a roadblock in the process.  Right now the only way to share data is via email, but the emails will also become much richer and more meaningful.

It will be an interesting time to be involved in Enterprise software, I'm sure.

Language and Microformats - The Tower of Babble

There's an interesting discussion going on right now about Microformats and language.  What it boils down to is, we're trying to standardize Microformat classes, but how do you do this when half the users don't speak English?  To them, "vContact" might as well read "::838fjs!!".  Not exactly conducive to using it in casual blog editing.

I think I'm beginning to see the real problem--there's no good way to create microformatted content.

Live Clipboard Extension

I believe an extension is needed for Live Clipboard.  Right now it only has the capability to copy & paste the information contained on the page it resides in.  In Ray Ozzie's example, all of the contact and calendar information is embedded on the example page itself.  However, there are two big problems with that:

1. The page itself will get real fat, real fast.  A contact could contain several addresses, several contact methods, links, and hey what about a blog feed?
2. The information contained in the page will get stale.  What if somebody changes the time of an event?  Somebody who has an old post cached in NewsGator might not know.

There's a simple solution to this, however.  The microformat needs to tell the clipboard what it contains, but not embed the information in the page itself.  (Or, if it does, it should be bare bones info, and only information that rarely if ever changes.)  Instead, the Microformat should tell the clipboard where to look for the master copy of the information--the URL where the fully fleshed out information can be obtained.  This solves both of the problems, and creates a kind of "object authority" where the master copy is always fresh and authoritative.

This will require some further refinement of the microformat specs (keep an eye on xFormats.org for details) to include the location of the full object spec, but certainly nothing that can't be easily overcome.

Enterprise 2.0 Adoption Hinges on Microformats and Knowledge *Integration*

Andrew McAfee had some great points about the hurdles to Web 2.0 technology (RSS, blogs, wikis, etc) adoption in the enterprise.  His points can be summarized as follows:

• Most workers don't have time to generate information
• Web 2.0 technologies would have to replace existing information-sharing processes
• Most people don't like producing information (the "long tail" contains most of the content producers)
• Companies will be reluctant to let unfiltered information flow freely as it may disrupt the culture

These are all very good points.  People already share information with email and IM.  He then goes on to make the argument that adoption will be driven by the eventual realization of how much more effective these technologies are.  HOWEVER, I don't think information sharing will be the driving force for the adoption of these technologies in the enterprise. 

The thing that is really going to drive home the value of these technologies is when the information produced by people can be integrated with information that's being produced already.  This is why I'm such a huge believer in microformats, they are going to turn the tide and make these arguments irrelevant.

When people are able to cut and paste a link to an order into their blog post, or paste a link to a customer contact into a comment about a customer service call, THAT delivers real value.  When people can subscribe to a feed of new orders as they roll in, and cut & paste questionable orders into their blog feed, which is fed directly to their supervisor, THAT delivers real value.  They're not just sharing content that they produce, they're acting as the information filter.  The company becomes an organic being that passes information around like instant messages.

-j

Microformat Standards

I appreciate the efforts of the Microformats.org guys, but really, who is policing these standards?  Not only are the names of the formats not consistent (hCard, XOXO, XFN), but the way they're used isn't consistent either.

I'm probably going to start my own open Microformats site sometime in the near future, simply because I need to get this standard moving more cohesively and quickly.  There need to be some naming conventions put in place while we still can... and how about some useful code guys??  Why not include the Live Clipboard javascript needed to actually use these microformats.  And maybe an XML schema definition?  Otherwise these definitions are all over the board.

I'll probably also release a database script in SQL, mySQL and Oracle formats that can house all this microformat data in a relational way.  I mean, if we do this right, everything will be structured, so to me that means that systems will be generating most of the microformat data, not people learning how to write "rel-tag" into their blog posts.

-j

Desktop and Web Integration

Can you drag a contact from an online application to your desktop or a folder in Windows or Outlook? I can't.

There is a big disconnect between the Web and the desktop that's just begging to be bridged.  Sometime soon a multi-platform thick client application that understands Microformats is going to clean up.  I can think of a million different things that the client should be able to do, but here's my hit list, what I'm going to make it do if nobody gets there first:

• Drag and drop to and from the browser.  When I drag a picture from the browser to my desktop, it should save the file to my desktop.  When I drag a picture from my camera to a blog post, it should upload the image to my hosted filesystem of choice (preferably Amazon S3) and auto-insert an <IMG> tag to that file.
• Right-clicking on a file to send it to my online file system.
• Right-clicking on a folder to set up synchronization to my online file system
• Dragging and dropping microformats.  When I drag a contact out of my browser into my OS, it should be dropped as VCF format, not a URL link.
• Right-clicking a folder to set it up as a synchronized feed to an online RSS or ATOM feed.  As microformats become more prevalent, and as better software gets written (wink, wink) you'll have the ability to subscribe not just to articles but to all kinds of stuff.  If I want to subscribe to a feed that contains files (say, podcast recordings for the time being), I should be able to set up a local directory that gets synchronized with that feed.
• Two-way syndication.  With WSS, it's going to become common to use feeds as a way to send and receive data other than blog posts.  I should be able to set up a directory that is a feed I share with another company via WSS and drop order files (via a Microformat) into that folder, and WSS will transmit that order to the company on the other side of that link.

If Microsoft was smart (and I think they are--Ray Ozzie is a SMART dude), they'd be doing this stuff in Vista.  (Wonder if that's what some of the delays were about.)  They're part of the way there with FolderShare and Groove, but they need to open it up more.

-j

PS  Ray Ozzie needs to update his RSS button to conform to Microsoft's new standard syndication button... like the one I have B)