Catablog

I believe that RSS is the single-biggest-real-world-useful example of TAPOX (The Awesome Power Of XML). I'm reminded of that daily, as Rohit has been fond of regularly using the word "catablog" lately to connote

Using an RSS feed to deliver catalog notifications such as sales, closeouts, news, best sellers, reviews, release dates, and other special deals.

A search on the word catablog yields no such definition. Still, there's a lot of promising work in that direction; for example:

1. Nick Bradbury points out eBay's general announcements and system announcements feeds. That's a step in the right direction. Hey eBay, how about feeds for every auction so I can get all those eBay alerts out of my email?

2. On the other hand, Amazon has wholeheartedly jumped on the RSS bandwagon, so now there's lots of Amazon Syndicated Content Feeds: "Amazon.com Syndicated Content is delivered in RSS format. RSS is a standard XML format for delivering content that changes on a regular basis. Content is delivered in small chunks, generally a synopsis, preview, or headline. Selected categories, subcategories and search results in Amazon.com stores now have RSS feeds associated with them, delivering a headline-view of the top 10 bestsellers in that category or set of search results. Using RSS, you can easily track any type of information that changes on a daily or even hourly basis (view an example RSS feed for topselling DVDs)... The RSS feeds generated for Amazon categories and search results are based on the existing XML feeds delivered by Amazon's Web Services platform."

3. Even boutique eCommerce sites like ThinkGeek makes a new stuff and announcements feed available on its What's New (s) page.

The button has been slowly but profoundly changing my life over the last five years, allowing me to get more and more content out of my ever-cluttered email inbox. Catablogs have even more potential to get eCommerce notifications out of my email, so I salute the concept.

Comments

[Emy]

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

[Adam]

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.

[Emy]

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.

[Emy]

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

[Adam]

I went to developer.ebay.com 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 FreeBiddingTools.com 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!

[Adam]

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.)"

[Adam]

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

[Adam]

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.

[Adam]

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:

http://blogs.law.harvard.edu/tech/rss

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

http://www.atomenabled.org/developers/syndication/atom-format-spec.php

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="http://purl.org/atom/ns#">
<title>dive into mark <link rel="alternate" type="text/html"
href="http://diveintomark.org/"/>

<modified>2003-12-13T18:30:02Z</modified>
<author><name>Mark Pilgrim</name></author>
<entry>

<title>Atom 0.3 snapshot</title>
<link rel="alternate" type="text/html"
href="http://diveintomark.org/2003/12/13/atom03"/>
<id>tag:diveintomark.org,2003:3.2397</id>
<issued>2003-12-13T08:29:29-04:00</issued>
<modified>2003-12-13T18:30:02Z</modified>

</entry>
</feed>

...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
Ecommerce)
2) Make sure the language is really simple. Duh.
3) Stick to no more than a dozen of these types. Start with, say,
three.
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
information.

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
products.

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 http://validator.creativecommons.org/).

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 http://validator.creativecommons.org/).

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
today.

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, bookfinder.com)
5) Make sure the press and popular blogs know about it

An excellent test marketplace would be bookfinder.com - 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
ago?

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 shopper.com or froogle.google.com 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
categorization.

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
go.

More RSS thoughts:
------------------------------------------------------------------

I came across this yesterday:

http://blog.flickr.com/flickrblog/2004/07/the_feed_thicke.html

...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
intervals:

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 (webdav.org) - 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)
around.

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:

http://www.archive.org/services/collection-rss.php

EPCGlobal, PML, and ONS
------------------------------------------------------------------

I came across this article on the EPCglobal Network:

http://www.rfidnews.org/library/2004/06/24/an-internet-of-lessthansolid-things/

...as 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:

http://www.epcglobalinc.org/standards_technology/specifications.html

The specs for PML:

http://www.epcglobalinc.org/standards_technology/Secure/v1.0/PML_Core_Specification_v1.0.pdf

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

http://www.epcglobalinc.org/standards_technology/Secure/v1.0/WD-ons-1.0-20030930.pdf

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
spec:

http://www.w3.org/TR/rdf-primer/

Here are a number of proposed modules (extensions, namespaces) to
RDF/RSS:

http://web.resource.org/rss/1.0/modules/proposed.html

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
few:

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
language.

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
died.

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

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:

http://ranchero.com/netnewswire/

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

http://www.makienterprise.com/newsfan/index.html

This RSS client won an Apple Design Award:

http://freshsqueeze.com/products/pulpfiction/screenshots.fss

...now 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
  shortages
  
• 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

...as 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!

[Adam]

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 NexTag.com 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.

[Adam]

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