Jeremy Mazner has posted a few interesting WinFS scenarios. I thought I’d add one that’s fresh in my mind.
One of the exciting new features of Mac Office 2004 is simple project management. Project management is an overloaded term, so let me take a moment to explain. Office lets you assign contacts, messages, tasks, events, notes, scrapbook items, and files to projects. There is a rich set of views that lets you manage all of the information in projects. It’s a great way to manage your data because you can see everything related to a project in a consolidated view without having to see stuff you don’t care about. You can also share projects through a simple mechanism. To share, each user basically syncs to a representation of the project sitting somewhere on a server.
Within Entourage’s database, this is pretty easy to represent. We just tag each item with the projects they belong to and can do quick indexed searches for all of the items in a project. Then, we built the rich UI and sharing on top of that. This let us support everything mentioned above, except files.
Files were a different story. Since there’s no easy way to attach metadata to files , how do you associate files with projects?  Even if you tagged them somehow, there’d be no quick way to search across all of your files for files with the tag. You could try to keep track of the files and watch for things to happen to them, but this wouldn’t work for many reasons, especially without somehow patching the OS. The solution is to use a folder for each project. Inside this folder, you can put the files associated with the projects. The next question was, when adding a file to a project, do you move the file in, copy the file in, or just copy in an alias to the file? Each has its drawbacks. If you move the files in, then adding a file to a project is somewhat destructive, and you can’t add read-only files. If you copy them in, then the user might not understand that if they have two copies of the file now, and if they edit the original, you haven’t edited the one in the project (and vice-versa). It also doubles the space required which sucks if you are dealing with large media. If you add aliases, then you risk the danger of a user deleting a file, not realizing it is part of the project, or moving the file in such a way that the alias can’t track it. There’s also no easy way for users to add things that are stored in other databases like data from Mail.app, iPhoto (I know these are files, but they are hidden), Apple’s address book, etc.
On Longhorn, WinFS solves these problems. There are a few ways this could be implemented. One would be to put all of the items in the project into a list, with holding relationships to all of the items in the list. This would allow you to quickly enumerate all of the items in the list. The holding relationships also solve the ownership issue because they have a ref-counting type model. The item will continue to exist as long as anyone’s got a holding relationship to it. And, this will work with any type of item from any application built on top of WinFS. The sharing side of things could also potentially be built on top of WinFS sync.
I only wish we’d had WinFS when building Office 2004!
 Hey, we could just put the project name in the filename! (Inside joke for Mac users who went through religious wars about HFS-style type/creator vs. extensions when Mac OS X came out)
 This is also a reason we couldn’t move to directly building on top of the Mac OS Address Book. I can write more on that if there’s interest.