IMV stands for Information Meta View. It is many things in one: A personally owned and managed data source, a data model in the form of graph (as opposed to tree in LDAP and relational tables in databases), a structured data aggregation framework among diversely distributed IMV data sources, and so on.
What is the main purpose? To have a framework that allows us to manage and share information in dynamically formed P2P networks. For example, if everyone shares information about the books they own (or have read) etc., it can result in a massive distributed database. The key point to note is that every individual appropriately maintains the information she owns, and subscibes/shares information that they like from among friends and contacts. We standardize the process of sharing, the data model, and capability to evolve meta data so that sharing actually happens.
This project started off some 3 years ago. It has survived till date mainly through project undertaken by engineering students. One version was also sponsored by the company I work for.
Over the time, we have learnt a lot of things. Firstly, Semantic Net does this and more. Neverthless, we don't actually have a system in place that allows us to do the things that we have envisaged. So the project is still valid.
Second, for the product to succeed in real world, it should follow rules of real world. It is opensource, and so, geeks will be the first to adopt it. However, we want to design in such a way that other communities - such as businesses, ISPs etc. find value in the model, and it should be easy for them to boot. Third, it is eventually intended for end users who are not computer savvy. They understand email well. And we want to extend the email model so that email can now be used with structured data.
Rishi Desai (http://rushi.desai.name/) and Pavan Reddy (at Persistent) - who created a WebDAV compliant IMV server. This server is now available and used by other projects. (This was first successful demonstration, and won couple of prizes too.)
Priyanka Grover (who was at Persistent earlier, and my wife) created the first server with IMAP as backend, and a Template based system as front end - with IMV metadata and tree exposed to people. Obviously, we had to learn lessons in UI: The tree view is not the right way to present the information to users.
A group from AIT, Pune (2001-2002 batch): Vinayak Sharma (email@example.com), Amrit Pal Singh (firstname.lastname@example.org), Indervir Singh (email@example.com), Navneet Singh Waraich (firstname.lastname@example.org) - contibuted IMV Browser component in Mozilla 0.9.5 using XUL. The idea here was to be able to create dynamic tables from IMV data. IMV is an arbitrary graph. However, the views need to be table centric; they can then be published on web. Vivek Shende (mailto:email@example.com) co-ordinated this effort.
In the current year, we have two main projects:
A data store for IMV and any structured data, with some interesting characteristics. The group from PICT (firstname.lastname@example.org and others) are working on this. The key point here is that we want applications to use "Structured Data Models" to interact with secondary storage. Further, we want to make it easy for end users to manage this type of storage. An example: The email client that uses this data model for the email lists will not see a file on disk. It will instead see a list that has no bottom. You put a new CD that contains a part of your emails (say from specific month during last year), and the application will instantly see the list grow - all be it with gaps that correspond to other CDs. Increasing volume of information will require a new model, and this is what we are trying to come up with.
Second project concerns modelling of IMV interfaces as seen from different stakeholders. Firstly the end users: They should just see an extension of email paradigm: They can compose a imvMail that asks "Does anyone have this book?" i.e. it requests the recipients to submit structured data to their own IMV data stores, and then allows that information to be aggregated (from the replies sent back) into a table. And then, there are 'application providers' who provide applications such as Books. (Application here is a meta data set with some basic workflow.) And then there are IMV server hosting people - like the web server hosting providers which make it possible for people to get IMV account, much like they get an email account. Note that we don't want centralized system such as yahoo or hotmail: The system has to be as distributed as possible. Two people from MIT, Pune (Amber Saxena - email@example.com is contact point.)
We are toying with different transports. First it was WebDAV protocol. But it is not popular. So now, we feel that we just use email transport, with specially formed MIME messages that carry IMV messages. And eventually we want to pave the way for email clients to enhance themselves to manage IMV data as well.
We are also working on IM based interfaces to IMV. This will be more natural language based interaction with IMV data store.
More on this later.