My Photo


« Lookout, Software! | Main | Personal Servers and Information Clients, 2004 »


What would it take to have RSS feeds on eBay auctions?

Either eBay has to agree to start offering auction feeds, or someone has to scrape eBay auctions and offer their own auction feeds.

I'm sure eventually commerce will work this way. For an interesting related piece of fiction, see August 2009: How Google beat Amazon and Ebay to the Semantic Web By Paul Ford.


No, I get that eBay would have to start offering auction feeds. My question was - what exactly would it take to make it happen?

Although now I did a little research, I've got a basic understanding of what would have to be done. But what exactly are you looking for in them? It seems like you're better off going directly to eBay to check that, because an aggregator's only going to check it at your specified interval (right? again, just starting to understand this...), and it won't do you much good in the last minute of the auction, which is when snipers and their software take over.

Unless I've missed something entirely. Which is entirely possible, I like to live in my own little world sometimes.


Okay, now I've been told to send you to, and you'll find some happiness there. So.


I went to and if I do some hardcore developing perhaps I can program my own eBay RSS feeds.

The beauty of RSS is no programming. Just subscribe to the feed, and away we go.

Here's something a little better: a non-programming way using to create things like RSS feeds for eBay searches. Instead of programming, you fill out a form. That's a little better.

What would be best is if on every eBay page there was a little orange "XML" button that offers that page (an item, a store, search results, etc) as a feed.

Then and only then can we talk about techniques for streaming that feed out to you instead of making you have to go check it at given intervals, as you suggested in your post Emy.

The auction that comes to you -- now that sounds exciting!


Netflix joins the catablog movement!

Jim Winstead Jr. points out: "netflix now provides rss feeds, including new releases, your queue, and recommendations. (like the last link, via jeremy zawodny.)"


A word from the wise: Don't try to make a google news to RSS personal aggregator.


On the other hand, it now appears that gmail has added Atom web feeds, a format that's akin to RSS. The feeds include a summary of each new message in your Google email.


Kevin Hughes sent me an email with lots of interesting ideas:

Idea: Use the RSS model to make a quick, simple set of ecommerce
service documents.

RSS (Really Simple Syndication) is the perfect model to emulate for
this - today there are tens of thousands of RSS feeds and many
different RSS readers for all platforms. It's so popular that Apple is
building in RSS-reading capability into Safari, their Web browser, and
some sites move more RSS data than they do HTML data.

People use RSS feeds to represent news items, event listings, stories,
and other Web content. There are plenty of tools for aggregating and
validating RSS feeds in a number of programming languages.

The RSS specification:

The Atom specification (a more modern, extensible version of RSS):

For me the main reason for its popularity is its simplicity. I can
write the code to generate an RSS feed from a site myself within 30
minutes, if not less. Here's an example from the Atom specification (I
hope this is viewable in your email client):

<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="">
<title>dive into mark <link rel="alternate" type="text/html"

<author><name>Mark Pilgrim</name></author>

<title>Atom 0.3 snapshot</title>
<link rel="alternate" type="text/html"


...this is a simple news item with a title, author information, unique
ID, and HTML content.

So let's make a number of document types like RSS for ecommerce:

1) Give the whole suite of DTDs a name, like "RSE" (Really Simple
2) Make sure the language is really simple. Duh.
3) Stick to no more than a dozen of these types. Start with, say,
4) Every core DTD should be driven by a popular industry need. No
obscure stuff!
5) These DTDs are descriptive only and hold no workflow or logic.

Let's make a series of documents that describe the most-needed schema
elements that most small to mid-sized online businesses need. Let other
technologies deal with transactions, agreements, workflow, and logic.
Unlike UBL DTDs, these are not meant to be transaction initiators or
results - only descriptions of currently existing commerce-related

Use common language for tags instead of industry-specific phrases.

Everything needs to be designed towards allowing the average
mom-and-pop Web store to create these descriptions. Once enough of
these small business are on board (such as the kind that set up Yahoo!
stores), people will write aggregators to search and compare prices and

Allow extensible namespaces so people can extend their descriptions.
Don't try to cover every little detail in the core schema, use the
80/20 rule.

These descriptions should use the strategies learned from RSS and Atom
to allow high volumes of traffic without overloading servers.

Make only the smallest amount of elements required while still
retaining usefulness.

Here's some suggestions for the initial DTDs:

1) Product description

The product description may include product title, summary,
organization ID, manufacturer ID, manufacturer, price, and availability
information. There may be creation and expiration times and dates as
well as a refresh value. There may be a link or included copyright
description (see

2) Catalog description

The catalog description may include catalog title, summary, and number
of product descriptions. There may be creation and expiration times and
dates as well as a refresh value. There may be a link or included
copyright description (see

3) Organization description

The organization description may include address and contact
information, business summary, link to the Web site, link to one or
more RSS feeds, one or more product description links, one or more
catalog description links, security support (SSL), truste
certification, and versions of the RSE documents that are supported.
There may be creation and expiration times and dates as well as a
refresh value. This document would be available via a standard
"description.rse" or "organization.rse" link from the Web site, like
the "robots.txt" file that's picked up by content-indexing robots

An RSS/RSE reader would load the RSE description from sites and show
any linked product and catalog information. It may allow searching
across multiple RSE feeds, like many RSS readers do today, and
highlight only the most recently updated catalog and product
information. Some RSS readers allow one to create stored searches for
news items across multiple sites by topic. RSE readers could allow one
to create stored searches for desired products with desired prices
(allowing your old "shopping agents" scenario to come to life).

How would one implement this stuff?

1) Set up a site for open, free specifications, with a forum for
developer feedback
2) Encourage RSS developers (makers of RSS readers and writers) to
support the DTDs
3) Write tools that developers can make use of: validators,
generators, etc.
4) Talk with initial test marketplaces to adopt the specs (such as
Yahoo! stores,
5) Make sure the press and popular blogs know about it

An excellent test marketplace would be - their product
descriptions would be generic with the exception of only a few
industry-specific tags (author, book type, binding, ISBN). Make a small
namespace for the used book market and extend the core product/catalog
descriptions with it. Hey, didn't we talk about this effort a few years

Anyway, I'm for a solution that the thousands of small businesses on
the Web can implement quickly and easily. This is so simple and
powerful, there is no reason not to.

Regarding "RSE":

...I also wanted to add to my notes that in the product description
DTD, you'd also have a section for a link to a product description
(such as on a Web page), which might also be inline text-only data, and
you'd also have a link to actually buy the product, to add it to a
shopping cart.

So with enough sites participating, you'd actually have the ability to
create your own or portal with the
ability to search for and compare products, with the difference being
that you could make your own product "watch list" for items or types of
items that you're interested in.

How you might add support for a product/organization taxonomy is up in
the air. It's a slippery slope; you may want to omit support for
taxonomies altogether for simplicity's sake and let someone else do the

In terms of adoption, CommerceNet should also hand-pick and work with
a number of initial online stores supporting the descriptions so that
when people download a RSE viewer there's a bunch of content ready to

More RSS thoughts:

I came across this yesterday:

...basically, this company is extending RSS to support photo
syndication. This means that RSS readers could be photo browsers and
you could subscribe to photo streams from AP and other news sources.

Perhaps an easier way to kick off the idea of service/product
descriptions would be to simply extend the existing RSS and/or Atom
specifications with product and catalog specific information?

RSS-like product description streams could come in useful in the
following scenario: a warehouse can keep its suppliers informed of
current inventory by auto-generating these streams at regular

1) which items are been received, and from where
2) which items are outgoing, and to where
3) a general shipping schedule for a particular time period
4) the most popular items at any given time
5) the items with the smallest and/or longest times in the warehouse

...the warehouse might make use of a mechanism that reads RFID tags
from items and adds the data to an RSS stream, which any supplier could
pick up. You could also generate RSS streams that are secure and
personalized for each supplier. This data could help decision makers
make the supply chain more efficient. And suppliers would get real-time
information about their products, all in a standard, open way, over
HTTP or HTTPS, over the Web, on any platform. No complicated protocols,
networks, hardware, or software involved.

The online component of brick-and-mortar stores could keep the public
up-to-date as to what products are currently in stock at which
locations. Or the whole system might be kept away from the public,
exposed only to suppliers.

Another idea: extending RSS, or creating another DTD, that
encapsulates RFID data. RFID data is not necessarily human-readable,
but it might be useful as a tool for putting together product tracking
systems. It might also be a handy open storage format for suppliers. A
WalMart could consolidate all the RFID RSS streams from its suppliers
to confirm in-store inventory.

See, once you have the core objects - the nouns - of ecommerce down
(products, catalogs, maybe RFID, etc.), then you evolve another
technology - the verbs - to act on them. This would be languages and/or
servers that can deal with workflow, logic, and transactions. That's
the second phase. I don't want to get ahead of myself too far but I'd
look at the WebDAV protocol ( - which is basically all about
stateful transactions over HTTP - and see what could be learned from
that effort. WebDAV is supported by many, many clients and operating
systems now. Microsoft FrontPage is basically a WebDAV client and
WebDAV support is built into Mac OSX - you can mount a Web site on your
desktop just like a NFS, SMB, or AppleTalk share.

All modern Apache servers include mod_dav, a WebDAV module that
enables WebDAV support. Why not make a mod_eco module? That's your
business services kernel right there. There might be some P2P
capability built in, and the ability to take in a description of a
transaction or workflow and choreograph the proper nouns (products)

I know CBL and other languages did a lot of work defining many
different parties of transactions - buyer, seller, etc. Was there a
single party superclass these all derived from that one could use, one
pared down and made simpler?

Here's another example RSS feed - these are the latest items to be
added to the Internet Archive at any given moment:

EPCGlobal, PML, and ONS

I came across this article on the EPCglobal Network: mentioned in their 1.0/1.1 specs, they already have an XML
schema for describing RFID data called PML. You can support PML as part
of the eCo RSS-like language to make interoperation easier.

Here's all the specs for the EPCglobal Network:

The specs for PML:

The specs for ONS, which uses a DNS-like service to map from pointers
in RFID data to URLs:

ONS (Object Name Service) would make use of a DNS-like system of
registries for mapping EPCs (electronic product codes, found in RFID
data). There have already been plenty of suggestions to build similar
services on top of DNS.

Perhaps offer to work with those building the pilot ONS
infrastructure, and build EPC and PML support into the RSS-like
languages I propose?

RDF, RSS, and eCo

I read in the news today that Sir Tim Berners-Lee finally got his
official knighthood. Whenever I read an article on him, I almost always
see a mention on his work on "the semantic Web".

The current thinking (from the W3C) is that RDF should make the idea
of a semantic Web happen. It's not a bad technology and the ideas are
nice, but from a user's point of view I think it stinks and have said
so ever since Tim Bray worked with the initial ideas (from Apple) some
years ago.

The problem is that the syntax is just too damn complicated and people
are simply not going to describe things using RDF unless there are
simple tools out there for doing it. A semantic Web is not going to
happen unless you have people (or software) working to assign more
meaning to things, and right now the effort is just not worth it. RDF
is the big picture way to solve everything, and while it's nice to have
now, people are only just now dealing with a few puzzle pieces.

However, we can look at how the semantic Web can evolve not from the
big picture on down, but from the bottom up, where there is a need for
and definite benefit to assigning meaning to certain things.
Start by making domain-specific languages, like RSS. So many people
are finding RSS useful for encapsulating news items. But the insight
here is that search engines like Google can index these feeds, which
provide extra semantic information such as article title, creation
date, expiration date, summary, and so on!

If you start making a language that allows people to describe
products, catalogs, and organizations, then Google (and other systems)
can pick up on those as well and make use of the extra semantics
therein. That's the beginnings of your "semantic Web" right there!

So say that takes off, and people start making other domain-specific
languages. At some point tools and standards should come along to
describe everything in RDF, but only after these little languages are
in widespread use. So you bootstrap the long-term solution with the
short-term easy-to-make solution, which is pretty much how the Web has
evolved. One day one or more RDF files on your site could encapsulate
your news feeds, products, services, organization information, stock
price, etc., but I say let's get the small pieces going first.

Unfortunately RDF also has a part called RSS, which stands for "RDF
Site Summary". I'll call it "RDF/RSS". You can read about it in the RDF

Here are a number of proposed modules (extensions, namespaces) to

So in summary, if you wanted to create a de facto standard for
describing business services, you have a number of choices - here are a

1) Use whatever IBM/Ariba/other standards groups have come up with.

Pros: Usable by large-scale Web services systems.

Cons: Hard to make, there are no free tools for easy generation, there
are too many "standards" at this level, this is a top-heavy solution
for the great majority of the Web.

2) Make a simple, RSS-like language.

Pros: Easy to make and integrate into existing processes. No
specialized, expensive tools necessary.

Cons: You'd have to convince RSS toolmakers and users to adopt the

3) Extend RSS (Really Simple Syndication) with your own namespaces.

Pros: Leverage all the existing RSS tools and resources out there,
while remaining easy to create. There are tons of great client-side RSS
viewers for Windows and Macs.

Cons: RSS was not meant to be a catch-all language, and problems may
arise when trying to evolve beyond it.

4) Create a language using RDF/RSS, as a RDF/RSS module.

Pros: Works with W3C standards, RDF tools, and is very extensible.

Cons: There are no client-side RDF viewers for Windows or Macs. Most
Web developers could care less about RDF.

I would definitely not go down the path of 1). Plenty have tried and

I myself prefer 2) or 3), and then evolve into 4) if and when the time

But if you think you can get developers and lots of people behind a
no-nonsense, real-world use of RDF, go for 4) first.

In terms of quick adoption, 2) or 3) is the way to go, because you
could leverage so many existing tools out there. And when Safari adds
RSS support, other browsers will follow. Imagine viewing a concise
product list of any online store in a consistent, searchable format,
right from your Web browser...

Anyway, more food for thought. Discuss amongst yourselves.

Take a look at these RSS readers, for Mac OSX. Download and play with
them if you like, or at least just take a look at the screenshots:

Note the "ticker alert" feature and search capability here:

This RSS client won an Apple Design Award: imagine, using these very same real-time tools:

  • a store owner browsing through their product inventory as well as
    the inventory of all their suppliers, with wholesale purchasing links
    on each product, AND getting news alerts from suppliers on product
  • a consumer searching through multiple product catalogs to find a
    jacket, AND getting news about store specials on certain products,
    applicable in the next three hours only
  • a stock clerk confirming the last results of their RFID inventory
    scan, AND seeing a list of incoming items that have not been scanned
    yet, along with location and pallet number you can see from all my typing over the last few days, this all
gets me excited, because the friendly, compelling user interface
already exists!


John Battelle writes in his piece, "The Transparent (Shopping) Society":

First, the entire UPC system, which I must admit I do not fully grok, must be made open and available as a web service. Second, merchants must be compelled to make their inventory open and available to web services. Third, mobile device makers must install readers in their phones, essentially turning phones into magic gateways between the physical world and the virtual world of web-based information. And fourth, providers like Google must create applications that tie it all together.

Ross Stapleton-Gray addresses these points in the comments section, and a lively discussion ensues, including Sergei Burkov of Dulance, which just announced an RSS comparison shopping application.

Also, Tony Gentile pointed out a new move by eBay releasing pricing data as a Web service:

Today, eBay announced the availability of Pulse, a tool that aggregates bids to provide up-to-the-minute (and historical) values for goods (and some services).

Yes, that's right... eBay, who, unlike your local newspaper, has transactions that clear (i.e., you know that the item was sold and how much it was sold for), knows the fair market price, globally, of millions of different goods... and they've just opened it up for mining!

Many implications:

1) We've seen the high-water mark for The Kelley Blue Book's value (and similar companies). Through Pulse, eBay Motors can be mined to provide near real-time and historical pricing information, on any make or model, in a narrow geographic region (i.e., local search), with car photos documenting the condition of the car, etc. Nice.

2) Data availability will impact marketplace participant behavior, likely resulting in Meta-marketplaces, 'day-sellers' and increased competition. For example, much as built a meta-marketplace by arbitraging SEM marketplaces (Google, Overture, etc) until finally finding a profitable niche in home mortgages, the ability to monitor demand on eBay for a particular good or service may result in speculative and opportunistic seller behavior, resulting in more (and more immediate) competition in eBay's marketplace.

Interestingly, just as with Overture/Google, tools that make the marketplace more efficient, as described above, may have a negative short-term impact on revenue (as anything that decreases the avg selling price of an item on eBay would), but will likely result in significantly greater long-term impact as the increased transparency leads to greater trust, allowing more transactions to move online.

3) eBay continues to ensure its Web 2.0 relevance by extending its existing services 1: Classified Listings and Transaction clearing (core marketplace), 2: Payments (via PayPal), and 3: Reputation (core marketplace), by adding its first data product service, Pricing.


Via Bill Lazar I discovered that Green Day has an RSS feed. By offering fans a feed of the band's news, they create a closer marketing relationship with their customers, and are just a step away from offering a full-out catablog of Green Day merchandise.

If 1994 was the year when it seemed like everyone had a web page, 2004 is the year when it seems like everyone has a feed...

Account Deleted

There are at least three things about Kevin's comment that made Rohit smile: the invocation of physics, the notion that 30 is relative, and the thought of seeing you next week.

porno video sikiş sikiş porno izle porno porno izle sikiş sikiş dizi izle film izle

The comments to this entry are closed.



  • John Battelle: The Search

    John Battelle: The Search
    My favorite book of 2005. Period.


  • Steven D. Levitt: Freakonomics : A Rogue Economist Explores the Hidden Side of Everything

    Steven D. Levitt: Freakonomics : A Rogue Economist Explores the Hidden Side of Everything
    "Just because two things are correlated does not mean that one causes the other. A correlation simply means that a relationship exists between two factors -- let's call them X and Y -- but it tells you nothing about the direction of that relationship. It's possible that X causes Y; it's also possible that Y causes X; and it may be that X and Y are both being caused by some other factor, Z.

    Economics is, at root, the study of incentives: how people get what they want, or need, especially when other people want or need the same thing.

    Incentives are the cornerstone of modern life. The conventional wisdom is often wrong. Dramatic effects often have distant, even subtle, causes. Experts use their informational advantage to serve their own agenda. Knowing what to measure and how to measure it makes a complicated world much less so." (*****)

  • Malcolm Gladwell: Blink

    Malcolm Gladwell: Blink
    A book of anecdotes about the power of thinking without thinking; this book is a more interesting read than Gladwell's previous, The Tipping Point.

    New York Times: "Gottman believes that each relationship has a DNA, or an essential nature. It's possible to take a very thin slice of that relationship, grasp its fundamental pattern and make a decent prediction of its destiny. Gladwell says we are thin-slicing all the time -- when we go on a date, meet a prospective employee, judge any situation. We take a small portion of a person or problem and extrapolate amazingly well about the whole."

    David Brooks, who wrote that review, adds: "Isn't it as possible that the backstage part of the brain might be more like a personality, some unique and nontechnological essence that cannot be adequately generalized about by scientists in white coats with clipboards?" (*****)

  • Paul Graham: Hackers and Painters

    Paul Graham: Hackers and Painters
    I don't agree with some parts of this book, but I truly loved reading it, and it really made me think. I referenced it in my weblications and superhacker and phoneboy posts. Favorite chapter is How to Make Wealth. (Thanks, Ev.) (*****)

  • Joel Spolsky: Joel on Software

    Joel Spolsky: Joel on Software
    Joel is really good at wielding "diverse and occasionally related matters of interest to software developers, designers, and managers, and those who, whether by good fotune or ill luck, work with them in some capacity."

    Joel on Software embodies the principle of "Welcome to management! Guess what? Managing software projects has nothing at all to do with programming." This book, a compendium of the website's wisdom, is useful for everyone from team leads estimating schedules to software CEOs developing competitive strategy. (*****)

  • Bruce Sterling: Tomorrow Now: Envisioning The Next Fifty Years

    Bruce Sterling: Tomorrow Now: Envisioning The Next Fifty Years
    Bruce wrote this book to come to terms with seven novel aspects of the twenty-first century, situations that are novel to that epoch and no other. It's about future possibilities.

    "This is the future as it is felt and understood: via human experience... The years to come are not merely imaginary. They are history that hasn't happened yet. People will be born into these coming years, grow to maturity in them, struggle with their issues, personify those years, and bear them in their flesh. The future will be lived." Here here, well-spoken, Bruce. (*****)

  • The World's 20 Greatest Unsolved Problems: John Vacca

    The World's 20 Greatest Unsolved Problems: John Vacca
    "Science has extended life, conquered disease, and offered new sexual and commercial freedoms through its rituals of discovery, but many unsolved problems remain...

    If support for science falters and if the American public loses interest in it, such apathy may foster an age in which scientific elites ignore the public will and global imperatives." (*****)

  • Paul Hawken, Amory Lovins, L. Hunter Lovins : Natural Capitalism: Creating the Next Industrial Revolution

    Paul Hawken, Amory Lovins, L. Hunter Lovins : Natural Capitalism: Creating the Next Industrial Revolution
    I had the pleasure recently of meeting Amory Lovins and hearing him talk about Twenty Hydrogen Myths and the design of hypercar. (He also talked about Bonobos... wow.) I'm a convert to the way of thinking espoused in Natural Capitalism. I used to be cynical about the future, but Amory's work has made me a believer that many great things are about to come. The best way to predict the future is to invent it. (*****)

  • Merrill R. Chapman: In Search of Stupidity: Over 20 Years of High-Tech Marketing Disasters

    Merrill R. Chapman: In Search of Stupidity: Over 20 Years of High-Tech Marketing Disasters
    In hilarious prose, this book catalogs lots of stoopid high-tech marketing decisions. It offers clear, detailed analysis of many a marketing mishap, with what happened, why, and how to avoid such stupidity. Might just be the best. book. ever... (*****)

  • Paul Krugman: The Great Unraveling: Losing Our Way in the New Century

    Paul Krugman: The Great Unraveling: Losing Our Way in the New Century
    A book exposing the pitfalls of crony capitalism, from corrupt corporations straight up to the executive branch of our government. Krugman is nonpartisan -- what he exposes is foolish short-term thinking on the part of recent United States policies. The patriotic thing to do, he advises, is to fix these economic problems now before they become much harder to solve.

  • Henry Petroski: Small Things Considered: Why There Is No Perfect Design

    Henry Petroski: Small Things Considered: Why There Is No Perfect Design
    "Design can be easy and difficult at the same time, but in the end, it is mostly difficult." (*****)

  • Alexander Blakely: Siberia Bound

    Alexander Blakely: Siberia Bound
    One of my favorite books of the past few years. Xander is a master storyteller. (*****)

  • Susan Scott: Fierce Conversations

    Susan Scott: Fierce Conversations
    How to make every conversation count. One of my favorite books of the last decade. (*****)

Blog powered by Typepad
Member since 08/2003