Why IDML exists (was: What are the problems with IDML?)

Jeff Leane (leane@emerge.com)
Mon, 26 Aug 1996 11:24:25 -0700


Message-Id: <v03007804ae479ae5f4b7@[205.158.249.103]>
Date: Mon, 26 Aug 1996 11:24:25 -0700
To: www-html@w3.org
From: leane@emerge.com (Jeff Leane)
Subject: Why IDML exists (was: What are the problems with IDML?)
Cc: lord@emerge.com, donohoe@emerge.com


On 8/16/96, Marc Salomon asked:
>I know of no research going on to standardize product and service description
>on the WWW.  It will be fun, though, to see profit margins drop to nil when
>programs we write can do price comparisons across the world in
>real-time...will
>anyone be able to afford to do business on the internet?

Interesting question.  Last year I built just such a program to do price
comparison in real time:  BargainFinder (http://bf.cstar.ac.com/).  It
shops at a bunch of CD vendors and presents its comparison in a little tote
board.

If you use BF today, you may notice two idiosyncrasies.

First, one third of the vendors it visits have locked it out.  They
complained about the increased system load caused by its repeated queries.
They also complained that BF misses the point in comparing vendors based on
price alone, and that vendors have lots to offer that is not reflected in a
pure price-by-price comparison.  In short, BF attacked their brands, so
they fought back. I believe that vendors will fight back against any agent
that threatens to make "profit margins drop to nil."


Then on 8/23/96, Jim Taylor asked:
>Why go to all the trouble of duplicating information (product name,
>description, price, etc.) that may already be in the document in
>human-readable form?

Second, another third of the stores BF visits have become incomprehensible
to it.  The stores changed and BF did not.  All the information is there on
the page, but BF's ability to "read" a page could not keep up with the
store's ability (and incentive) to keep tweaking and upgrading the UI.  In
the absence of standard landmarks, the very process of enhancing the page
for human readers made the page incomprehensible to the agent.  One
solution is to build a much smarter agent that can "read" pages like a
human; a more attainable solution is to standardize machine-readable
product descriptions in a way that will persist across other system changes.

So if you were going to build a shopping agent today, what would be its key
features?  First, it can't alienate vendors, but should help them talk
about their products in a way that makes them happy and builds their
brands.  Second, it should go hand-in-hand with standardized descriptions
for products and services.  It should be easy for the intended business
audience to learn and use.  Finally, it should balance all these needs with
the need for compatibility with existing systems.

That's the problem.  I believe that no e-commerce agent can succeed without
solving this problem.  How would you solve it?

-- Regards, Jeff



+-----------------------------------------------------------+
|Jeff Leane               V: 415-328-6700                   |
|V.P. for New Ideas       F: 415-323-3281                   |
|Emerge Consulting        E: leane@emerge.com               |
|171 Forest Avenue        W: http://www.emerge.com          |
|Palo Alto, CA 94301         http://www.identify.com        |
|                            http://www.well.com/user/leane |
+-----------------------------------------------------------+