Closed GoogleCodeExporter closed 9 years ago
From my perspective, the advantage of Catalog nomenclature is that it is well
understood by target publishing audiences, whereas technical ATOM based
terminology
is opaque to most. In presentations, I have personally not made a distinction
between a Catalog as a compilation of direct resource links vs a (meta-)
aggregation
of other compilations of resource links, and I think there may not necessarily
be
utility to one, at least in the kind of casual marketing/ business development
conversations that I tend to engage in.
Original comment by naypi...@gmail.com
on 5 May 2010 at 8:52
I agree that we could make things slightly easier to understand.
Maybe we should avoid some terms like "Hierarchy" and "Publication" when we
describe
a feed.
Essentially, we have two different refinements: feeds that are used for
navigation
and feeds that are used for acquisition. A feed can't be both at the same time.
Roger is right when he says that a "Publication Feed" could contain anything.
Cart
even has an example of such a feed where they distribute audiobooks rather than
ebooks.
Therefore, maybe we should rename it to "Acquisition Feed" (a feed where you
can
acquire content) or something similar, while the other type of feed could be a
"Navigation Feed" (a feed where you can access other feeds).
A Catalog for me means something different: it's the aggregation of all feeds
and
entries for a single source of content.
Original comment by hadrien....@gmail.com
on 6 May 2010 at 10:29
Hadrien's suggestions make sense to me.
"Navigation" more accurately describes a feed from which you access other feeds
than
"hierarchical collection."
"Acquisition" succinctly underscores what this feed does that Atom-plain
doesn't.
On first consideration, "Content" (eg, content feed) appealed to me with its
universal application, but an atom:entry links to a (full) blog post, and just
as
some people are blogging books (like Pepys' Diary) there's really no reason a
plain
Atom feed couldn't serve complete books, section by section. So content feed
has a
tinge of ambiguity we probably should avoid. "Content acquisition" is clear but
carries no information that "acquisition" alone doesn't as well.
I've often approached the OPDS effort as a natural use of Atom, with our steady
flow
of new titles needing to be brought to readers' attention. In that guise, OPDS
answers the question of "How do we represent our spring catalog
electronically?"
Peter's statement, however, reminds me that a library catalog doesn't represent
just
new releases and re-releases, a publisher's frontlist, but the entire
collection.
And if entries do indeed have the metadata needed to find a particular book or
set of
books — as well as that ever-significant acquisition link — then "catalog"
is a more
meaningful label than "feed" with its roots in the need to
stay-current-with-ever-
changing-blogs and keep-up-with-things-changing-in-internet-time.
Like Peter, I'm not sure the distinction between navigation uses and
acquisition uses
matters in general discourse. So I'm happy enough with "OPDS catalog" as a
description of what our spec describes. I just want it clear that when we say
"pouring our type of content into an Atom feed makes it act like this," people
implementing the OPDS spec see how to use what they know about Atom; and when
we say
"this is something we need that blogs don't," they know why we're using terms
that
don't appear in [RFC4287].
Roger
Original comment by rsperb...@gmail.com
on 6 May 2010 at 2:06
Original comment by abdela...@gmail.com
on 12 May 2010 at 5:19
I've consolidated the vocab in this draft:
http://code.google.com/p/openpub/source/diff?
spec=svn227&r=227&format=side&path=/wiki/CatalogSpecDraft.wiki
Original comment by abdela...@gmail.com
on 12 May 2010 at 7:18
Original comment by abdela...@gmail.com
on 25 May 2010 at 5:44
Original issue reported on code.google.com by
rsperb...@gmail.com
on 5 May 2010 at 8:02