"Real time" to me means an interaction delay in the range of milliseconds. If the delay is more in the range of seconds like the web application i am working on then "live" would probably be a better term.
The traditional meaning of 'real time' (at least in embedded stuff) doesn't really specify just how fast, just that things have to be done in a given amount of time. Generally, you're right that those things happen quickly too.
There is a range of timespans that Real Time applies to. In data acquisition, say a medical signal such as an electrocardiographic signal or an EEG signal, we are talking milliseconds.
I wouldn't think of web transactions as real-time, even though there is user expectation of response within a certain small number of seconds.
In the context of the investments mentioned, these seem like the data comes in asynchronously, not matched with a specific request, and that the interesting work to be done is to make sense out of this non-fielded data.
As someone else said here in this thread, Google made search interesting again using essentially unstructured data--no real metadata to get your ERD around. Similarly, the other sources we are thinking of also don't really have that much structure--no tag saying HERE-IS-WHAT-YOU-ARE-LOOKING-FOR. To me, this is why these are interesting problems.
I think event-driven (as opposed to
request driven) is probably a better term to describe the conceptual difference being discussed here. Obviously you could then have different latency requirements for event delivery depending on the application.
