<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Microformats as information brokers &#8211; revisited</title>
	<atom:link href="http://thebankwatch.com/2007/01/05/microformats-as-information-brokers-revisited/feed/" rel="self" type="application/rss+xml" />
	<link>http://thebankwatch.com/2007/01/05/microformats-as-information-brokers-revisited/</link>
	<description>Tracking the evolution of financial institutions</description>
	<lastBuildDate>Mon, 13 Feb 2012 00:48:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Joe Andrieu</title>
		<link>http://thebankwatch.com/2007/01/05/microformats-as-information-brokers-revisited/#comment-6953</link>
		<dc:creator><![CDATA[Joe Andrieu]]></dc:creator>
		<pubDate>Fri, 19 Jan 2007 11:14:00 +0000</pubDate>
		<guid isPermaLink="false">http://bankwatch.wordpress.com/2007/01/05/microformats-as-information-brokers-revisited/#comment-6953</guid>
		<description><![CDATA[Colin,

I agree. Microformats should definitely help with discovery, especially hand-in-hand with tagging. That basically comes from their use of semantic html. That means either of your options 1 or 2 could work, as a browser plugin, a Technorati-style spider &amp; search, or perhaps a personal crawler/agent residing on your own machine.

However, I think the bigger win from microformats may be learning from their focus on generating community consensus. I agree with your assertion that no one tool can solve all the problems of VRM. However, that’s almost the same as saying no one online service can meet everyone’s needs. It is true. But in practice, the Internet, or more particularly, the shared protocols and formats of the Internet, allow any number of online services to emerge to fill market needs. This happens simultaneously at the network provider level (Earthlink), the server application level (Google), and the client application level (Firefox).

I think VRM can solve its challenges in a similar way. By creating a set of standard protocols and formats, we can enable a number of mechanisms for customer-centric vendor management.

In your own area, if there were a standardized format for people to submit loan requests—and that met your needs as a bank—wouldn’t banks use VRM discovery/search/registry mechanisms to find and respond to those requests? After all, the requests are out there, practically free leads, just waiting to be serviced.

I think one key to VRM is the realization that no single format is sufficient. And I’m glad you highlight that need. If we coordinate at the protocal and meta-format level, any number of request and response formats could be exchanged, allowing customers and vendors to find solutions to their problems. That’s the same way that HTML, http, MIME, SMTP, POP, and TCP/IP enable a wide range of unique, custom services.

The lesson for me from microformats is in realizing the need to find community consensus in particular subdomains. hCard works because people agree about what it means. That means one person’s hCard is interoperable with any hCard service. Similarly, I foresee community-based development of VRM standards that resolve domain-specific requirements as vendors and service providers join in to create solutions for that domain. Private formats are practically useless here, but formats shared across a community can be incredibly powerful. That’s one of the main values of microformats, and VRM can learn a lot from that experience and approach.]]></description>
		<content:encoded><![CDATA[<p>Colin,</p>
<p>I agree. Microformats should definitely help with discovery, especially hand-in-hand with tagging. That basically comes from their use of semantic html. That means either of your options 1 or 2 could work, as a browser plugin, a Technorati-style spider &amp; search, or perhaps a personal crawler/agent residing on your own machine.</p>
<p>However, I think the bigger win from microformats may be learning from their focus on generating community consensus. I agree with your assertion that no one tool can solve all the problems of VRM. However, that’s almost the same as saying no one online service can meet everyone’s needs. It is true. But in practice, the Internet, or more particularly, the shared protocols and formats of the Internet, allow any number of online services to emerge to fill market needs. This happens simultaneously at the network provider level (Earthlink), the server application level (Google), and the client application level (Firefox).</p>
<p>I think VRM can solve its challenges in a similar way. By creating a set of standard protocols and formats, we can enable a number of mechanisms for customer-centric vendor management.</p>
<p>In your own area, if there were a standardized format for people to submit loan requests—and that met your needs as a bank—wouldn’t banks use VRM discovery/search/registry mechanisms to find and respond to those requests? After all, the requests are out there, practically free leads, just waiting to be serviced.</p>
<p>I think one key to VRM is the realization that no single format is sufficient. And I’m glad you highlight that need. If we coordinate at the protocal and meta-format level, any number of request and response formats could be exchanged, allowing customers and vendors to find solutions to their problems. That’s the same way that HTML, http, MIME, SMTP, POP, and TCP/IP enable a wide range of unique, custom services.</p>
<p>The lesson for me from microformats is in realizing the need to find community consensus in particular subdomains. hCard works because people agree about what it means. That means one person’s hCard is interoperable with any hCard service. Similarly, I foresee community-based development of VRM standards that resolve domain-specific requirements as vendors and service providers join in to create solutions for that domain. Private formats are practically useless here, but formats shared across a community can be incredibly powerful. That’s one of the main values of microformats, and VRM can learn a lot from that experience and approach.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

