May 2 2007 Meeting notes: Difference between revisions
(→Status) |
Joe.andrieu (talk | contribs) |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
Drafted by Joe Andrieu, May 2, 2007 | Drafted by Joe Andrieu, May 2, 2007 | ||
== | ==Other Calls== | ||
[[Category:conference call]] | |||
[[:Category:conference call]] | |||
==Attendees== | ==Attendees== | ||
| Line 21: | Line 16: | ||
* Britt Blaser | * Britt Blaser | ||
* Deborah Schulz | * Deborah Schulz | ||
* Chris Carfi | |||
==Status== | ==Status== | ||
| Line 40: | Line 36: | ||
|Set up Jabber Host for conference calls||doc||no date||''new'' | |Set up Jabber Host for conference calls||doc||no date||''new'' | ||
|} | |} | ||
Unfortunately Doc won't be able to join us today. | Unfortunately Doc won't be able to join us today. | ||
| Line 60: | Line 54: | ||
Consider a use case where Alice is specifying the RFP, but Dad is paying for it. This is discussed on the [[Technology]] page. | Consider a use case where Alice is specifying the RFP, but Dad is paying for it. This is discussed on the [[Technology]] page. | ||
===Social Use Cases=== | |||
The thought of this term triggered some concerns about a data mining case. | |||
Think of gift registries. I'm a Bride or Groom. Where the good is registered in an identity-capable registry. Liberty's People Service enables this to allow access to the invited people without needing a unique account. The relationship specified by the Bride and confirmed upon login could be used by a VRM system to integrate this information, mapping the desires of the bride against, for example the budget constraints of a particular guest (assuming such constraint is also made available via a People Service for the guest). | |||
In an RFP, there are two different pieces of information: what I want and what I'm willing to pay. In a social application, those might be controlled by separate people. | |||
One scenario is that we don't actually need a means to reconcile offered prices, accepted bids, etc. Just a means to engage in a sales conversation. | |||
We need mechanisms for discovering the guests and their price threshold information. People Services can handle that. | |||
===Information RFPs=== | |||
We could also put out RFPs that are inquiries regarding informational needs rather than just purchase criteria. | |||
Thus, the implicit relationship embedded the RFP can provide some interesting services. | |||
===Personal Data Silos=== | |||
The liberty model seems to support this as well. For a movie-list provider, I would define what conditions the provider releases the RFPs or personal data. Some might be public. Others might be restricted. | |||
So how about being able to specify "Movie Services" as a restriction, rather than explicitly as NetFlix or Amazon or BlockBuster. | |||
Ping ID used to provide a similar service. It'd be nice to have a Hoover's or D&B to offer a categorization service for vendors. | |||
===Making this available=== | |||
How do we make this available to the vendor? WHen a user authenticates to the vendor, they wouldn't generally sign in at the vendor, but through an identity provider. So they authenticate, for example, to Google, then go to Amazon. As the user has single-sign-on in, then Amazon uses the SSO to secure information such as shipping or geolocation in the course of the interaction at the web site. | |||
So, Amazon kicks things off by querying an identity search for that users VRM providers they are engaged with (kept track at the identity provider, Google in this case). Amazon gets this list back, filters out inappropriate VRM providers, and sends a query to the chosen VRM provider (perhaps including the user in the process), asking for Joe's RFPs. The VRM provider responds by delivering the RFPs to Amazon. Amazon tries to match the RFP to viable products, making those available to the user. | |||
There are other models where the discovery of the VRM is more distributed. In theory, I could just put the RFP on my blog and let Amazon discover it. | |||
We could perhaps set up a neutral clearinghouse for vendors and users to have a trusted safe place where the user is the arbiter: including syntax and business practices that enable these sorts of transactions. | |||
There needs to be some mechanism for quickly identifying the scope or purpose of an RFP. Vendors should not have to filter every RFP. | |||
The Liberty Model is that the Vendor queries the RFP when the user shows up, rather than trying to scan the entire Internet. | |||
One thing VRM might fix is the problem of finding things. If I could submit an RFP and never have to visit an vendor site. | |||
The challenge remains that when the vendor finds a user. | |||
One option: put the RFP as an Identity-filterable blog post, tag it as a particular type of RFP, ping a clearinghouse, then allow access and comments by selected vendors (hopefully selected as a class of Vendor). the structure and usability of such a service *must* be presented and developed in such a way that it is easily integrated into existing software and ops in use by vendors. Acceptance, more so, the ability for vendors to grasp and use the service, is critical to succees. | |||
The choice of response channel should potentially be set by the user, allowing either email-style responses, "comments" on an RFP blog, or some other mechanism. | |||
We've talked about two extremes, where visiting a vendor triggers the vendor. The other where the user posts the personal RFP on its own. Another alternative is that visiting a site could establish the relationship and then participate in a VRM conversation outside the context of the website. | |||
===Tracking quality vendors=== | |||
There isn't any current way for users to know whether or not a given vendor is a good actor. Reputation is one vehicle for addressing this, but we also perhaps need to establish codes of conduct or rules of engagement that vendors are accountable for, either through reputation, legal recourse, or some other means. | |||
===Automation=== | |||
It may be challenging for individuals to actually respond to RFPs, so we need some sort of streamlining or automation. However, shopatron is one system that actually requires humans to make a commitment to fulfiling an RFP. | |||
In fact, that is how Shopatron gets around the apparent need to know all the inventory of all the retailers that might fulfill the order. | |||
===Dictionaries=== | |||
There is a challenge for understanding what users really want. An explicit dictionary can help address this. One way of solving this problem is some sort of taxonomy or folksonomy. | |||
We've talked a variety of different ways that people could support this. From Twitter, we've seen them provide access via a large number of different on-ramps. | |||
Part of our task is how do we integrate through as many media as possible? | |||
Both what is the XML document and what does the content mean (dictionary)? | |||
And how do people interact with systems that use that document? (on ramps) | |||
In considering accessing data from multiple web-based silos, every website has its own vernacular. So, one option is that every site change to use a canonical dictionary. Alternatively, one could support a translation capability into a canonical dictionary. And even more distributed, translation to /any/ shared dictionary would enable communication. And if any series of translations can convert a source term into an understandable term, that would work too. Taking this one step further, anyone could provide a translation mechanism if there were a central registry that could maintain quality controls and resolve queries against potential source data. | |||
===Organic results=== | |||
It would also be nice if successful VRM transactions could be coordinated as a sort of "automatic recommendation" for users who submit similar RFPs. For example, if Bob puts out an RFP for a particular type of running shoe, and finds a vendor. It may be useful to recommend that vendor to others who post similar RFPs. This is a sort of bottoms-up architecture for automatically generating "organic" recommendations in response to RFPs. | |||
===IIW 2007=== | |||
The next major live even for VRM development, evangelizing, and camaraderie is the [http://www.windley.com/events/latest/announcement.shtml Internet Identity Workshop] in Mountain View, May 14-16. Many of us will be there. We hope you can join us. | |||
==Action Items== | ==Action Items== | ||
Latest revision as of 12:17, 25 July 2007
Conference Call Notes
Drafted by Joe Andrieu, May 2, 2007
Other Calls
Attendees
(please update with last names & IM if you'd like a backchannel during the call...)
- Paul Madsen
- Keith Hopper on AIM: hopperomatic
- Ben Laurie
- Joe Andrieu on AIM: jpandrieu
- Leif Chastaine
- Dean Landsman On IRC: deanland On AIM: deanlandsman
- Britt Blaser
- Deborah Schulz
- Chris Carfi
Status
| what | who | when | status |
| ---------- | ---------- | ---------- | ---------- |
| open id on wiki | david | no date | |
| static website development | doc, dean, joe, chris | no date | |
| group blog/RSS to wiki (venus) | doc | no date | up, but only one author |
| project VRM definition | doc | 1 week | still working on it |
| brainstorm Initiatives | all | ongoing | |
| Set up Jabber Host for conference calls | doc | no date | new |
Unfortunately Doc won't be able to join us today.
Joe: remind Dean about transcript.
Report from Brussels
Doc led a session at the Open Identity event last week. Britt took a look at how Liberty Alliance's architecture might help.
One foundation of VRM is the personal RFP, a way for individuals to express their buying desires in a way that vendors can respond directly. Britt sees a personal RFP as an aspect of a person's Identity. That would be put on the web so buyers could find them, analyze them, and discover with them a potential match for what they could provide me. At its basic, the WSF (web services framework) is a way to do just that: provide aspects of identity securely over the Internet.
Liberty Alliance is a standards body for federated identity and identity services.
VRM still needs to define and XML syntax for what this RFP looks like. Some sort of product number, useful meta-data, etc. Some way for users to describe what they want to buy, maximum price, timing on purchase, etc.
The web services is really about moving around that type of identity-centric document.
So, we have schemas that specify, for example, a calendar format that allows people to share calendar data through this framework.
Consider a use case where Alice is specifying the RFP, but Dad is paying for it. This is discussed on the Technology page.
Social Use Cases
The thought of this term triggered some concerns about a data mining case.
Think of gift registries. I'm a Bride or Groom. Where the good is registered in an identity-capable registry. Liberty's People Service enables this to allow access to the invited people without needing a unique account. The relationship specified by the Bride and confirmed upon login could be used by a VRM system to integrate this information, mapping the desires of the bride against, for example the budget constraints of a particular guest (assuming such constraint is also made available via a People Service for the guest).
In an RFP, there are two different pieces of information: what I want and what I'm willing to pay. In a social application, those might be controlled by separate people.
One scenario is that we don't actually need a means to reconcile offered prices, accepted bids, etc. Just a means to engage in a sales conversation.
We need mechanisms for discovering the guests and their price threshold information. People Services can handle that.
Information RFPs
We could also put out RFPs that are inquiries regarding informational needs rather than just purchase criteria.
Thus, the implicit relationship embedded the RFP can provide some interesting services.
Personal Data Silos
The liberty model seems to support this as well. For a movie-list provider, I would define what conditions the provider releases the RFPs or personal data. Some might be public. Others might be restricted.
So how about being able to specify "Movie Services" as a restriction, rather than explicitly as NetFlix or Amazon or BlockBuster.
Ping ID used to provide a similar service. It'd be nice to have a Hoover's or D&B to offer a categorization service for vendors.
Making this available
How do we make this available to the vendor? WHen a user authenticates to the vendor, they wouldn't generally sign in at the vendor, but through an identity provider. So they authenticate, for example, to Google, then go to Amazon. As the user has single-sign-on in, then Amazon uses the SSO to secure information such as shipping or geolocation in the course of the interaction at the web site.
So, Amazon kicks things off by querying an identity search for that users VRM providers they are engaged with (kept track at the identity provider, Google in this case). Amazon gets this list back, filters out inappropriate VRM providers, and sends a query to the chosen VRM provider (perhaps including the user in the process), asking for Joe's RFPs. The VRM provider responds by delivering the RFPs to Amazon. Amazon tries to match the RFP to viable products, making those available to the user.
There are other models where the discovery of the VRM is more distributed. In theory, I could just put the RFP on my blog and let Amazon discover it.
We could perhaps set up a neutral clearinghouse for vendors and users to have a trusted safe place where the user is the arbiter: including syntax and business practices that enable these sorts of transactions.
There needs to be some mechanism for quickly identifying the scope or purpose of an RFP. Vendors should not have to filter every RFP.
The Liberty Model is that the Vendor queries the RFP when the user shows up, rather than trying to scan the entire Internet.
One thing VRM might fix is the problem of finding things. If I could submit an RFP and never have to visit an vendor site.
The challenge remains that when the vendor finds a user.
One option: put the RFP as an Identity-filterable blog post, tag it as a particular type of RFP, ping a clearinghouse, then allow access and comments by selected vendors (hopefully selected as a class of Vendor). the structure and usability of such a service *must* be presented and developed in such a way that it is easily integrated into existing software and ops in use by vendors. Acceptance, more so, the ability for vendors to grasp and use the service, is critical to succees.
The choice of response channel should potentially be set by the user, allowing either email-style responses, "comments" on an RFP blog, or some other mechanism.
We've talked about two extremes, where visiting a vendor triggers the vendor. The other where the user posts the personal RFP on its own. Another alternative is that visiting a site could establish the relationship and then participate in a VRM conversation outside the context of the website.
Tracking quality vendors
There isn't any current way for users to know whether or not a given vendor is a good actor. Reputation is one vehicle for addressing this, but we also perhaps need to establish codes of conduct or rules of engagement that vendors are accountable for, either through reputation, legal recourse, or some other means.
Automation
It may be challenging for individuals to actually respond to RFPs, so we need some sort of streamlining or automation. However, shopatron is one system that actually requires humans to make a commitment to fulfiling an RFP.
In fact, that is how Shopatron gets around the apparent need to know all the inventory of all the retailers that might fulfill the order.
Dictionaries
There is a challenge for understanding what users really want. An explicit dictionary can help address this. One way of solving this problem is some sort of taxonomy or folksonomy.
We've talked a variety of different ways that people could support this. From Twitter, we've seen them provide access via a large number of different on-ramps.
Part of our task is how do we integrate through as many media as possible?
Both what is the XML document and what does the content mean (dictionary)?
And how do people interact with systems that use that document? (on ramps)
In considering accessing data from multiple web-based silos, every website has its own vernacular. So, one option is that every site change to use a canonical dictionary. Alternatively, one could support a translation capability into a canonical dictionary. And even more distributed, translation to /any/ shared dictionary would enable communication. And if any series of translations can convert a source term into an understandable term, that would work too. Taking this one step further, anyone could provide a translation mechanism if there were a central registry that could maintain quality controls and resolve queries against potential source data.
Organic results
It would also be nice if successful VRM transactions could be coordinated as a sort of "automatic recommendation" for users who submit similar RFPs. For example, if Bob puts out an RFP for a particular type of running shoe, and finds a vendor. It may be useful to recommend that vendor to others who post similar RFPs. This is a sort of bottoms-up architecture for automatically generating "organic" recommendations in response to RFPs.
IIW 2007
The next major live even for VRM development, evangelizing, and camaraderie is the Internet Identity Workshop in Mountain View, May 14-16. Many of us will be there. We hope you can join us.
Action Items
| what | who | when | status |