Web 2.0 Information Access Patterns

Today's Information Management Software business (approx. $37B) is built upon providing software for information access patterns exhibited by enterprise class applications. 

1. SQL, and now emerging XQuery for patterns around structured data;
2. content CRUD, records management, collaborative document handling and business process enablement for unstructured data;
3. search, analytics, reporting and querying for business intelligence; and
4. ETL, federation and master data management for the broad EII space. 

So the question is: what are the patterns that will emerge for information needs of Web 2.0 class of applications?  As we refine our thoughts further, for us, Info 2.0 is the collection of software or SaaS delivery models to service those patterns.  I am fairly confident of a few (we are collecting the first three in our first release of Info 2.0 layer, coming very soon). 

1. Access to information that might not be in IT control -- desktop, departmental, external, email (viewed as personal information)
2. Lightweight "composition" -- mixing and mashing of information to service situational, personal productivity or lightweight process-centric applications.
3. Feed-centric information perspective
4. Simple semantics, tagging etc.

What else?  In the 1980's, the separation of data and application layer spurred phenomenal innovation in both, and it was done in a fairly open, standards based way.  I think this separation of Info 2.0 and Web 2.0 class of applications will do the same, but only if, we as a community, identify the patterns, and make sure that an eco-system evolves above, and below these pattern implementations.  So I am very interested in getting feedback on what other patterns we all see.  And what is the mechanism for us to collaborate on this evolution, while still understanding the competitive spirit (thanks Lauren Cooney and Rod Smith for drilling this into me)?

Comments

[Pingster]

I am thinking the really interesting characteristic of large collections of tagged data is the difficulty of building appropriate indexes for the data "on the fly" as access patterns emerge.

This is really quite interesting when compared to Relational Databases, where we have a lot of techniques for picking out what "the best SQL" or the "the best Index construction" would be.

In a large collection of tagged data that is directly accessable, applications would come and go, and theoretically at least, so should index techniques, since it would be improbably difficult to provide high performance access to very large amounts of data *without* something equivalent to indexing in the RDB.

Adapative indexing? I'm not sure what to call this.

Thank you for the informative blog posts by the way!