Doc Searls uses the term "sewage pump" (I'm paraphrasing) to describe the modern advertising-based economy. Modern society has created the most efficient machine imaginable to push stuff at people whether they want it or not. I gave an example in this blog post about Novatel: they're treating Twitter as a way to push stuff at me instead of as a place to relate to me.

A pump pushing sewage at you is a good metaphor for what's wrong with the marketplace we've constructed in the late 20th century. Doc has built the VRM project as a means of exploring better ways of building markets for the 21st century. Something I hadn't considered until I was going through David Siegel's book Pull is that "pull" is the right metaphor for this new marketplace and it's precisely why Doc's metaphor of a sewage pump rings so true.

David's book is about the Semantic Web and the use of data standards to enable you to "pull" the information, services, and products to you. An example from the book that really hit home for me is this: in 2010 if you order a package from Amazon, you have to give an address where it will be delivered. Wouldn't it be better if instead, you just gave Amazon an identifier and then the package would find you at the place you wanted it to go--even if that's the hotel you're currently staying at? In essence, you pull the package to you with online data. This isn't a pipe dream, but a perfectly reasonable way to think about how the world ought to work--and one that's doable now from a technical standpoint.

Doc uses different language to describe this same idea when he talks demand leading supply. The pump is all about supply leading demand. The key idea that both Doc and David would agree on here is that "If demand leads supply..., customers need to be the points of integration for their own data." More on that later.

The Four Party System

In an effort to further define VRM, Doc has introduced the notion of "fourth-party services." He says:

Among numbered parties the best-known one today is the third party. Wikipedia currently defines a third party this way (at least for the computer industry):

• Third-party developer, hardware or software developer not directly tied to the primary product that a consumer is using
• Third-party software component, reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform

In general, a third party works on the vendor's side of the marketplace. However, the vendor is not generally called the "first party" (except in the game business, as Wikipedia says here). In fact, the most common use of the term "first party" in business is with insurance, where the term refers to the insured. (The insurer is the second party.)

From » VRM and the Four Party System ProjectVRM
Referenced Fri Feb 26 2010 11:04:37 GMT-0700 (MST)

So, if third-party services are merchant driven, it stands to reason that the customer-drive services that represent them would be the fourth party. Here's a picture of these four parties:

The little horseshoe magnet looking things are called rel buttons are meant to represent customers or merchants (left and right in the above diagram) who want to relate to each other.

Fourth-party services, be theysimple or sophisticated will act as brokers that work on the user's behalf to manage their interaction with vendors of various products and services. Without such automated agents, no one would want to take on the work that would be necessary otherwise to manage the dozens of relationships each of us has with vendors. But with them magic happens.

Building 4th Party Apps

Doc and David are both thinking about very general solutions to this problem as well they should. My job, as the CTO for Kynetx, however, is slightly different. I'm trying to build things for our customers and make them work now. The Kynetx platform has always been aimed at creating client-side Web applications that help users achieve a purpose. That's a pretty good working definition of "fourth-party" in my book. The platform is designed to allow developers to use data in context to create interesting Web applications. Moreover, our corporate philosophy has been consistently in favor of respecting user rights to control data.

With that backdrop, I've thought long and hard about how Kynetx could be used in service of VRM and--by David's definition--the semantic web. I'll use this schematic to help explain my latest thinking:

To keep this simple, I'm going to avoid going down every "or they could do..." fork in the tree. There are lots of them. Here's the flow:

1. The user visits a merchant. This could be online or in person (imagine the app running on their phone and using location in context).
2. At the same time any fourth party apps that they've installed (denoted by the fourth-party rel-button) are invoked as long as they are relevant to the current activity.
3. KNS (the Kynetx Network Service) executes the rules associated with the presented apps. We're going to presume for sake of this example that those apps need personal data to work on the user's behalf and such access has not been previously granted.
4. KNS requests the required user information from the personal data store (PDS).
5. The user is asked to authorized such access and grants it.
6. The PDS requests the data from various sources as necessary and returns it to KNS. Note that as envisioned here, the PDS acts more like a virtual directory than an actual repository, although that's not a strict requirement.
7. KNS executes any relevant merchant rules (determined by the app, current context, and the data retrieved in step 6) to determine how they want to relate. Merchant rules are denoted by the third-party rel-button in the diagram. This may be specific offers, discounts, special service levels, etc. I'm calling this "the deal" for lack of a better word.
8. Finally the results are presented to the user's client.

A key feature of the scenario shown in the figure is the privacy wall (in red). That's there to reinforce the fact that in this model the user's data is never given to the merchant. The merchant's rules act against it, but they never see it. For fourth-party apps to work, users will need assurance that their data is being treated in a way that respects privacy. They will also need to trust the agents working on their behalf.

A few other points to note:

• Kynetx has no access to user data except as authorized by the user. The user is entirely in control of the experience and what data is used.
• The merchant rules could exists in a standard rule format like RuleML and be stored in any repository so long as they were discoverable.
• The same holds for user data. There's no need for it to be in a single place as long as it's in standard formats, is discoverable, and has a clear, unambiguous meaning. David calls this same concept the personal data locker and it is central to the whole idea of the semantic web, pull, and VRM.
• As envisioned the merchant rules, users data, and user apps are all orthogonal to each other. This isn't a single application, but a platform where fourth-party apps can be built using whatever user data and merchant rules are available.
• Successful fourth-party apps won't just be ways to get offers to customers but manage the relationship between merchants and users in sophisticated ways. They could, for example store receipts, initiate and mediate support issues, manage returns, and so on.
• In this demo, we're using OAuth to enable user control of the data in the PDS but that's really a stand-in for other more versatile standards that are forthcoming like UMA and R-Cards.
• The scenario above focuses on one interaction where the app and the merchant rules could conduct a complete, complex negotiation on the user and merchant's behalf. Keep in mind, however, that the key is the relationship and that is bigger than a singleton deal or negotiation and might include support and service functions, ratings, and so on. Successful fourth-party apps will be seen by users as trusted agents, not merely a way to get a good deal on a single transaction.

A key difference between this model and a traditional ad network is the idea of "pull." Ads are not being pushed (note that successful pushing requires "tracking" and "targeting" users--niether is being done here). Rather more holistic information about what I'm calling "deals" is being pulled to the user based on their purpose and intent.

I have a working demo of all of this right now that uses a PDS that has access to a user's Amazon wish lists as an example of intent data and Acxiom-held data as an example of personal data--all under user control. Getting from demo to production is more a legal and business matter, not a technical one. We're working on that too. I plan to share this demo and the ideas and techniques behind it at the Kynetx Impact conference in April and at IIW X in May.

The inclusion of intent data in the demo is important because data that signals user intent or purpose is much more useful in creating compelling fourth-party apps than mere facts like gender or household size that leave the app to infer intent. Guessing will become less necessary because users will have convenient, private means of sharing intent. In this model, attention gives way to intention just as purpose gives way to location.

Some might complain that there's too much dependence on KNS or that KNS is closed. That's not technically true: Kynetx is proprietary, not closed. Still, if that bothers you, give me the standards and we'll use them. We're all about building support for standard data sources and formats into the system. As I mentioned above, I'm open to supporting rules expressed in RuleML or some other standard format. And, of course, no one is imagining that KNS would be the only system doing this. This is just our contribution to making the idea of VRM and fourth-party services real.

We invite your participation. Signup for a free developer account. Register for Impact where you can listen to Jon Udell's keynote and discuss these ideas with us. We're happy to listen, resolve issues, and make this work.