VRM UI Session

Convener: Doc Attendees: Lots of r-button projects in progress
 * Joe Andrieu
 * Drummond Reed
 * John Bradley
 * Johannes Earnst
 * Nick Glvotovsky
 * Judi Clark
 * Abby Jenkins
 * Greg Biggers
 * Mary Hodder
 * Hank Mauldin
 * Kevin Marks
 * Christopher Carfi
 * Iain Henderson's Personal address manager
 * Implementation for radio apps / iPhone
 * Radio Paradise reference app

Three states; two icons  Reason for r-button: enable REAL relationships between individuals and vendors/entities; not 'fake' relationships of CRM
 * Nothing
 * Open (actions availabe, none take)
 * Closed (relationship action has been taken)

Rbutton started as ways to represent relationship

Rbutton specifies (person who marked up page) must represent entity to have relationship with URI the mechanism?

What about in chrome of browser?

What about the variety of entities?

What about scalability if you're polling 100 entities on a page?

Feasibility in practical terms - too much computational overhead?


 * Job of Relationship manager = discover all relationship services; contact them; determine if/who I have relationships with
 * User Agent uses RM to poll RS for entities
 * We don't need a standardized entity ID, but pockets of shared identifiers

You don't need a URI - could be well-formatted XRI/h-card/semantic data about an entity
 * A URI could be used as a discovery service rather than UID, showing us which RS's are available

Alternative: Quad-state r-button (only shows one half) - this would show when vendor is at the table vs. just user-driven relationship services.

How is r-button different from an aggregator that figures out preferred online service provider for users? (i.e. r-button is only part of the VRM discussion; how does this really change things?)

Answer: services must be VRM compliant

Outcome: the specific cases for r-button today are not particularly compelling, but are good for describing and specifying

Payment escrow, medical records, and personal RFP is very different from r-button service aggregation and offer a compelling vision of the future use of a distributed, user-driven relationship ecosystem
 * Three groups of RS's (vendor, user, third-party)

TWEETS & PICS: @drummondreed whiteboard of how relationship discovery works for rbutton entity relationship services #vrm #iiw2008b http://twitpic.com/lecm

Quad state r-button vs tri state r-button photo #VRM #IIW http://twitpic.com/ldmn