What that line is trying to get at is that with Atom there’s a one-to-one correspondence between an identifier and a content item - typically (but not necessarily) a blog post, for Atom. For unAPI we have to deal with more “symbolic” content identifiers that exist outside of any particular content system. In this case, the server could provide multiple reference links, excerpts, reviews, or actual copies of the identified book alongside a blog post about the book. And those links wouldn’t have to be hard-coded into the HTML.

Many of the unAPI authors come from publishing and academic libraries where citation is a critical function, so we’re trying to make it possible to provide more rich citation and object retrieval functions on the web without subverting the web itself. You have to be able to cite where you found something, and it’s often good to keep a copy of what you found, but if that “something” actually has multiple forms - a web page with an abstract, a citation form or three, a full text web page, a pdf, etc., we want to help publishers offer all of that through a standard API to make it inexpensively scriptable.

For many more examples and a full rationale, see the paper “Introducing unAPI” from earlier this year.

As for the layout in IE7… yuck. I’ll see what we can do.

Also, could you explain what you mean by “interact with” when you say “using unAPI you could interact with the book through example.com/myblog/unapi?uri=urn:isbn:123456789X.”

Also, check out the layout of this page on IE7; it’s not pretty.

Thanks.