|
Broadcatch Concepts Relating to VOS
Overview
Broadcatch is a suite of systems that provide increasingly more accurate and fine-grained profile information to and about customers over time. These profiles can be used by:
- the customer, to better filter information sources and content,
- the provider (in our case, the MediaBar), to gain visibility into customer usage and thus be able to provide e.g. new services perhaps even before they are specifically asked for,
- marketing, who will be able to determine and reach precise market segments to direct their advertising towards.
The MediaBar provides 3 of the four technological requirements necessary for Broadcatch. The "ubiquitous, multi-path network" is simulated by the 100-BaseT intranet LAN pervading the venue.
In order for Broadcatch to be effective, information on customer usage must be gathered regularly. On the net, this can be gathered e.g. by a server noticing when someone clicks on a link. In the MediaBar, the several client applications will communicate with the VenueOS/Database through a series of writelog operations.
Broadcatch technology creates an environment for trusted, secure cooperation and social advertising by creating an expandable set of default mechanisms for:
- secure (privacy enhanced) reputation-based customer usage data collection,
- data driven fitness function creation and operation,
- gather (seek) & filter operations,
- negotiation, and
- transactions in an anonymous digital marketplace.
Basically, Broadcatch employs an open-ended set of mechanisms to enable the discovery of customer usage trends or information of probably interest to a customer. Fitness functions are employed by software agents as well as in the heads of intelligent (wetware) agents to determine when datums become relevant for increased attention. Negotiation may be employed to further the data sharing and thus refine recommendations, or even to determine the exchange rate (items as well as values) for transactions in an agoric, market-driven environment.
While not mentioned above, it is important to keep in mind the importance of reputation, and thus the need for e.g. PGP-based certification of all entities in a transaction. Note, of course, that the true name of the person behind an avatar is not relevant -- only the behavior of the avatar over time would be considered.
Phase 1 - known verbs & preferences
Initially, the MediaBar's Venue OS is designed to accept information (indexed by a known set of verbs) that indicate changes in avatar profile, including avatar (personal) preferences. These preferences operate in much the same way as a set of preferences that a game may store in e.g. the Preferences folder on a Macintosh. The key added benefit provided by the MediaBar's VOS architecture is the ability for each user to support several avatars, each with its own unique set of preferences. (Note, too, that preferences can also be shared between avatars.)
Just having access to simple sets of preferences like this, especially having access to a history of them, allows for the discovery of trends. Such trends can be
- intrapersonal -- what one person likes over the course of their cumulative experiences at the MediaBar,
- interpersonal -- how people interact with each other, and
- global -- how people as a group tend to respond to the goings on at the MediaBar venue.
We need to be able to version incoming data. Timestamps are one mechanism for doing this, but you mentioned another? In any case, we need to support time travel on every profile and preference table so that we can keep tabs on their history. I know that the Illustra/Informix Universal Server will no longer support "time travel", but that's OK as I wouldn't want to lock us into a non-standard SQL mechanism anyway. This is an area for further research.
Phase II - unknown verbs
Beyond customer (avatar) preference, the ability to record an avatar's session over time provides information that could potentially be useful to a watching process/agent. As application developers become more aware of how customers will use their application, they may also begin to get a feel for how their apps could respond "intelligently" according to historical trends noticed both in the current customer's session as well as perhaps accumulated across all customer sessions together. To achieve this end, information will need to be made available to the various applications and to any agents than may find such information useful in the determination of such trends.
A mechanism existed for the posting of such data. This mechanism was, simply, posting an unknown verb, and then documenting that verb by e.g. sending email to Fen for inclusion on the Verbs page.
Phase III - collating unknown verb information
Once such "unknown" verbs are being regularly recorded and initial fitness functions are defined, then simple Broadcatch agent-based notifications and data-modification can occur.
Phase IV - subscribe & publish
The real power of Broadcatch becomes apparent when the system is opened for use by the customers. I envision a Broadcatch application that allows an avatar to
- view & modify its own profile,
- conditionally publish selected profile sections to defined or computed (perhaps via a negotiation process) groups,
- create social advertisements for self-published information or services, and
- gather (seek) information of interest that others have published, perhaps conditionally adding it to its own profile.
