--On Tuesday, November 9, 2004 7:02 PM -0800 Tim Bray <[EMAIL PROTECTED]> wrote:
> 
> Anyhow, both PaceCategoryRevised and PaceCategoryElement are substantially
> richer than anything that's deployed in the field (a smattering of dc:subject
> and not much else).  I'd be inclined to lean to CategoryElement because it's
> simpler, but could live with either CategoryRevised, or with nothing (leaves
> us with dc:subject which is all we have now anyhow).  Since I haven't seen
> a -1 on any option, and there's damn little prior art to guide us, maybe a
> survey is in order. -Tim

OK, here is some prior art. The prior art goes back at least to 
Callimachus' catalogue for Alexandria.

This should probably go into the problem statement for a Pace.

Categories help navigation, by giving users a selection among a fixed
set instead of having to guess the writers word choice. Guessing words is
a losing bet, see "The Vocabulary Problem ...", Furnas et al, 1987.

Categories also also provide a way to group related items by 
different authors. This is the primary application in libraries.

But, categories are interpretations, so they are political and people
disagree, sometimes violently about categorization. The same document
might be categorized as "Wildlife Management" by one person and as
"Crimes Against Mother Earth" by another. No one taxonomy will ever
be suitable for all users.

Displaying category hierarchy is useful and supports good practices
like common subheads. If only the last nodes of these were displayed,
we would lose something:

   Highway > Regulation
   Highway > Safety
   Maritime > Regulation
   Maritime > Safety

On the other hand, taxonomies use quite different structures, some of
them without hierarchy. Here are some common classification graph shapes.
Most of these have more than one kind of link.

   Flat
   Tree (Dewey Decimal Classification, LC Classification)
   Tree with cross references (Yahoo, DMOZ)
   DAG (actually not used much, as far as I know)
   DAG with cross references (ANSI Z39.19, LC Subject Headings)
   Faceted (Epicurious recipes, lots of eCommerce sites)
   Spatial, either geographic or virtual

Finally, we cannot reserve a character as a path separator unless
we want to escape that character inside a category name. Which is messy.

What does all this mean for Atom?

1. Representing entire taxonomies is outside the scope of Atom.
2. Atom needs to reference external taxonomies.
3. There may be an expanded view (breadcrumb or path) as well
  as a category name.

So, a decent solution ought to have (some of these optional):

  an ID for the taxonomy
  an ID for the category within that
  a name for the category ("Safety")
  a display string for the category ("Maritime > Safety")

If we do want to navigate a taxonomy within Atom, I'd recommend starting
with ANSI Z39.19, which has the advantage of being used in real, working
systems and having a readable spec.

wunder
--
Walter Underwood
Principal Architect, Verity

Reply via email to