Feedback on scenario #1 and the meta-crap challenge

Before going on to my next scenario, I wanted to address feedback I’ve gotten so far.


On the general usefulness of WinFS, Stephane Rodriquez commented that “It’s not about information, it’s about MESSAGE.”  You can quibble with my language, but we both mean the same thing – you need a simple way to get at the stuff that’s important to you, when you need it.  We showed a demo at PDC of trying to find documents written by Bill about Longhorn.  Using the Longhorn document library, which exposes a simple query interface on top of data stored in WinFS (yes Michael, I agree that a great user experience is what really makes WinFS shine,)  it takes two clicks (one to stack by Author, a second to stack by Project) to go from 1100 documents down to just the 40 or so where Author=Bill and Project=Longhorn.  Or to stick closer to my first scenario, two clicks to find music where Genre=Jazz and Mood=Mellow or what have you.


Both Mario and Harold (in comments and in his blog, respectively) want to see an easy way to get meta-data out of WinFS for use by other systems.  Right on – that’s why the system includes an extensible demotion engine to write meta-data back into the filestream as appropriate.  Of course you can also query for meta-data using SQL, if you want, and even request the results in XML format.


Regarding my first scenario, I’ve got Dare agreeing that “scenario is compelling”, although he suggests “that there doesn’t even need to be explicit inter-application sharing of data” to make the scenario work.  Along the same lines, Simon comments that “I can already do this by selecting details view and letting explorer show me all of the meta-data stored *inside* my mp3 files.”  It’s certainly true that for this scenario, you don’t need WinFS to get access to the meta-data for an individual file.  But you do need WinFS to get to it in a consistent way across multiple kinds of items, stored across multiple folders, and to do it fast.  Mario addresses some of this in his comments, but I’ll be more explicit.


Let’s say you use iTunes to purchase AC3 files, you’ve got some old MP3’s lying around, a collection of WMAs, and maybe some Oggs as well.  And they’re spread across a hierarchy that’s 10 folders wide and 10 deep.  Now you’re in Movie Maker, and you want to find that mellow jazz tune to add.  What you need is a queryable index across all those files.  You need a storage engine that extracts the genre information from the files, stores it in a common schema, and indexes it, so that you’re not grinding through the hard drive every time you want to find a piece of music.  That’s where WinFS adds value in this scenario.


A few more comments worth pointing out: Asbjørn suggests this kind of common store with a schema that allows for relationships would be useful for organizing his inbox such that: “My e-mail is basically in a pool altogether, and is placed with pointers (shortcuts) in different views (compare them to database views, as there is no physical moving of files going on) that I can create.  David wants to get the same sort of quick and easy sorting/filtering experience I mentioned above for the PDF files he downloads, and Mario points out that the promotion engine in WinFS is designed for exactly this case.


Okay, moving on to the next scenario…

Comments (5)

  1. Stephane Rodriguez says:

    Sorry to repeat myself but I haven’t only talked about info vs message. I have pointed elements just as important (to me) :

    – information overload. cf. an Encyclopedia software product that would turn, because of information overload, every single word into clickable ones, making the whole encyclopedia barely useable from the user stand point.

    – about the necessity of WinFS when it comes to a contact API or so : where do you think we would now if MS made their protocols and file formats open rather than keeping them closed? Don’t you think that a lot of software out there would have taken advantage of some contact API. In other words, this is just not correct to say that WinFS enables things. Whether WinFS will come up with a consistent API and so on is not the problem, I hope it will. The fact that there has been so little interoperability between say client emails and other software is for policital reasons and is because you decided it first. Today, writing an Outlook express add-in requires to hack everything : from hooking windows to add menus, to hooking other user actions to insert yours. Any thought on that?

  2. Simon says:

    Good point – thanks. I just wish I had more time to play with the longhorn PDC build at work – so much fun stuff to toy with!

  3. milbertus says:

    As for the e-mail idea, you can already do that (to some extent, at least) using Outlook 2003’s search folders. Just create a new one, define your search criteria, and any new messages which meet that criteria will automatically be added to the search folder. It’s one of the main reasons that I’m running Outlook 2003 right now, in fact.

  4. Jeremy says:

    Responding to Stephane:

    info overload: totally agree it makes no sense to turn every single word into a hyperlink.

    interop and file formats: Actually, I think WinFS takes a huge step in terms of making data in custom file formats accessible. WinFS itself doesn’t define new data formats, but it does offer a common schema that’s documented, see If apps store their meta-data in WinFS, rather than in custom file formats, that meta-data will be accessible to anyone who understands the WinFS schema and queries using the API or SQL.

    The promotion engine allows all sorts of file types to move meta-data out of their custom file types, and into WinFS. As long as there are promoters for MP3, AC3, WMA, RMA, etc, meta-data from all these file types will be available via the same common schema in WinFS. I also hope we have promoters for PDF, DOC, PPT, etc. And then email programs like Outlook, Yahoo Mail and AOL Communicator can store their email items in WinFS as well, so that again you can access these items using the common schema.

    Regarding proprietary file formats, we’ve taken some steps to be more open with Office 2003’s XML-based formats, has a nice write up of what we did, and where it falls short still.

  5. Mark says:

    Recently I tried with an unofficial OEAPI at: , I don’t know how this is achieved.