Firefox plugin

Overview

Seeker toolbox implementation and SEO tools does not necessarily need to be browser plugin; could also be a standalone application using this model, but the browser plugin approach offers a few possible advantages:

• Vendor discovery process is integrated into Web browsing
• Tool itself (browser) and Web style interface is already familiar to users
• Some plumbing code is handled by the browser itself, rather than being written from scratch

This document does not yet address three key areas, though they will be addressed in the near future:

• The actual RFP/offer data format. Assumes a single format used for both RFPs and the offers that refer to them, but does not consider the issue any further.
• The details of seeker and vendor identity. Assumes that there is a distinction between public and private portions of identity, and that identity is fixed and verifiable (note: reputation management), but does not consider the issue any further.
• The mechanism for private vendor->seeker communication. Assumes that the mechanism is seeker controlled (i.e. RFPs and public identity don't contain something like an email address, which would open up spamtastic potential), but does not consider the issue any further.

NOTE: Read/Write Web points to work being done on Firefox 3 managing micro-formatted data: "Detecting information in Web pages and handing that information off to other applications changes the role of the Web browser from being solely a HTML renderer to being an information broker." LINK TO R/RW

Vendor Implementation

There are three parts to the Vendor implementation: a data store (publicly accessible location where the vendor's structured offers are stored), an agent (location of vendor agent process to which seekers can submit specific RFPs), and tagging (tags added to Vendor's WWW pages that identify the locations of the data store and agent). ?Address need for public vendor identity information?

Vendor (offer) Data Store

Publicly accessible directory containing the vendor's VRM-formatted offers. This data store allows Vendors to make general offers, in addition to responding to specific seeker RFPs. Seekers may choose to monitor one or more vendors' public data store in an effort to fulfill an RFP that the seeker doesn't want to submit to vendors or publish to their own public data store.

Vendor Agent

Process that accepts either an appropriately structured RFP, URI for a specific RFP, or URI for a seeker's public data (RFP) store.

Vendor Tagging

Vendors tag WWW pages with Technorati-style tags that identify the location of their offer data store, their Vendor Agent, and possibly identity data location, e.g.:

• href="LocationOfVendorDataStore" rel="VRMSTORE"
• href="LocationOfVendorAgent" rel="VRMAGENT"

Seeker Implementation

In this model, the seeker's personal computer becomes the primary point of focus. By storing all data on the seeker's local machine and selectively publishing (world viewable) or submitting (specific vendor viewable) a subset of that data, we provide seekers with a wider variety of possible approaches to fulfulling RFPs, greater control over their own data, and more flexibility in usage (online or off becomes irrelevant for much of the vendor management process).

Seeker Toolbox

Proposed as a browser plugin (i.e. Firefox extension). The seeker uses a browser-based interface to manage their primary identity information, personal information (including attention, perhaps), RFP creation/submission/revocation, and so on. The resulting data is stored locally, and only pushed out to the public Internet at the user's request. The toolbox need not, however, be limited to local data management.

Toolbox Local Data

Any subset of this data may be published to the seeker's public data store or submitted directly to a vendor (as part of | associated with) a specific RFP.

• Private identity information
• Private user information (demographic, vendor specific, etc.)
• Private attention data ?? (REF: attentiontrust.org/root.net)
• Location of public identity information
• Location of public RFP store
• Private vendor store (to be polled or for RFP submission)

Toolbox Functions

Not a comprehensive list, nor yet prioritized.

• Add/Update Identity
• Add/update personal information (demographic, vendor specific, etc.)
• Generate public identity file
  • Publish public identity file
  • Revoke public identity file ??
• Create/update RFP
  • Publish RFP
  • Submit RFP [to specific vendor(s)]
  • Revoke RFP
• Monitor vendor(s) data store [for match against RFP]
• Monitor external source for new VRM-aware vendors ??

Vendor Discovery

Vendor discovery process is integrated into Web browsing. Specifics of the process may be managed by user-configured preferences. Upon loading a page that contains VRM tags, the user is notified and may add the vendor's data store location or agent location to their personal seeker data store. This model of vendor discovery also allows for (but does not require) third-party participation as aggregators: third party crawls the Web looking for VRM-aware vendors, and provides an aggregated list to seekers.

Seeker (RFP) Data Store

Publicly accessible directory containing the seeker's VRM-formatted RFPs.

Seeker Agent

Seeker agent (again, integrated into browser) submits RFPs to specific vendor(s) on demand, manages the seeker's public RFP store, periodically polls specified vendor data stores in search of matches for open RFPs, if requested by the user. Probably manages vendor responses to submitted RFPs, details unknown.

RFP Fulfillment Scenarios

All scenarios below potentially depend on a vendor->seeker managed communication mechanism TBD.

Public RFP

For cases where the seeker wants the RFP to be available to the broadest possible spectrum of vendors, and the RFP does not require any vendor-specific or sensitive data to fulfill.

RFP located by crawler

Seeker publishes RFP to their public data store. That data store is accessible to all vendors' crawlers (with possible robots.txt-style vendor exclusion). A vendor's crawler finds the RFP, vendor matches to or generates an appropriate offer, and submits the offer to the seeker via mechanism TBD.

RFP located by seeker->vendor submission

As above, but seeker also submits their public data store URL to one or more vendors' agents. (Alternate formulation: seeker pings one or more vendors' agents to notify them of a new RFP. Two formulations not mutually exclusive.) A notified vendor reads the RFP, vendor matches to or generates an appropriate offer, and submits the offer to the seeker via mechanism TBD.

Selective or Private RFP

For cases where the seeker does not want the RFP to be available to the full universe of vendors and other denizens of the Internet: if the RFP requires vendor-specific information (frequent flyer number) or RFP contains or implies personal information that the seeker does not wish to disclose to the general public.

Selective submission of RFP

Seeker generates RFP but does not publish it, instead dubmitting the RFP directly to one or more vendors' agents. Only the contacted vendors know about/have access to the RFP. A contacted vendor reads the RFP, vendor matches to or generates an appropriate offer, and submits the offer to the seeker via mechanism TBD.

Seeker private RFP

Seeker generates RFP, but does not publish it or submit it directly to vendors. The seeker configures their own agent to monitor one or more vendor data stores for offers that match the specific RFP. Seeker's agent locates an offer that matches the RFP, and passes offer to the seeker for evaluation.

Working Notes

Not ideal, but interesting, as it's an implementation that reduces the dependency on crawlers (which are complicated from a totally distributed seeker perspective) and/or third party warehouses of pointers to seeker and vendor data store locations.

Vendors may tag pages with Technorati-style information: href="locationOfVendorAgentOrDataStore" rel="VRM"

Seekers install browser plugin and configure with basic information (private identity, location of public identity, public RFP store location, default behaviors, etc.). When the seeker visits a page that's tagged with VRM information, that information is either automatically or manually (user option) added to their local data store.

RFP creation can then be handled locally, from within the browser (online or offline), and the RFPs passed to vendors when a network connection becomes available. Plugin could also periodically poll known vendor data stores for offers that match the user's outstanding RFPs; this model also means that seekers can set up an entirely private, passive monitoring system as "watch these vendors for offers that meet these criteria, but don't publish the RFP to my public space."

Could work bi-directionally, as well, offering user the option to submit their own data store information (if they have a public location for RFPs, which becomes optional in this model) to individual vendors, who then periodically poll the user's public RFP store.

This approach also fits well with third-party participation, as third parties can act as aggregators: visit a third-party aggregator site and get offer data store information for 10, 100, or 1000 vendors all at once if desired. Conversely, user could submit their public RFP location to 10,100, or 1000 vendors all at once.

Interestingly, this model does seem to jive well with Doc's ca. 2004 "actively but selectively notify vendors" requirement from the minidisc recorder post.

REF: attentiontrust.org/root.net Stockholm