Subject: PaceCategoryRevised posted

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 20:22:38 +0100

Very similar to PaceCategoryElement but reducing the lock on the
hierarchical/slash scheme. I believe this should be usable with most
categorization schemes.

== Abstract ==

Add an atom:category element to both atom:head and atom:entry.  It can
appear multiple times.
 
== Status ==

Open.

== Rationale ==

Most blogging and other content management tools allow the user to
categorize their posts. The atom:category element allows that
information to be communicated in the feed.

== Proposal ==

Add new sections 3.7, 4.2.13, and 5.13 to the atompub-format-03 draft.

==== 3.7  The Category Construct ====

The atom:category element contains information about a category to
which an Atom feed or entry is associated.  It has three attributes,
"scheme", "term" and "label". The "scheme" attribute is a URI that
identifies a categorization scheme. The "term" attribute will be a
string which identifies the category within the categorization scheme 
to which the entry or feed belongs. The "label" attribute provides a
human-readable label that may be displayed in end-user applications.
Both the "scheme" and "label" are optional, but the "term" attribute
is mandatory.

==== 4.2.13 The "atom:category" element ====

A Category Construct identifying a category to which the feed is
associated.  atom:head elements MAY contain
any number of atom:category elements.

==== 5.13 The "atom:category" element ====

A Category Construct identifying a category to which the entry is
associated.  atom:entry elements MAY contain
any number of atom:category elements.

== Notes ==

Example:
<category scheme="http://dmoz.org" term="/Arts/Animation/" label="Animation" />

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 11:48:24 -0800

On Nov 9, 2004, at 11:22 AM, Danny Ayers wrote:

> "scheme", "term" and "label".

Rather than a "label" attribute, why not just use the content of 
<category>?  That way you could decorate the human-readable version, 
e.g. with HTML markup.  -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 9 Nov 2004 11:54:54 -0800 (PST)

> Both the "scheme" and "label" are optional, but the

I can't think of any reason why one would need both
term and label. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 9 Nov 2004 14:55:12 -0500

I like this proposal from the perspective of 
the publishing protocol where I believe 
both 'term' and 'label' are important pieces
of information that the user would want to
manipulate.

I would prefer the element name be switched to 
'subject' because it's use closely matches that of the
dc:subject element. 

I would also prefer 'term' not be an attribute but
be the element content.
 
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Zhang Yining <[email-masked]>
Date: Wed, 10 Nov 2004 03:54:31 +0800

Hi Danny,

>Add an atom:category element to both atom:head and atom:entry.  It can
What would the semantic be if feed has category "programming/java" and 
one entry of it has category of "photography"? Or we leave the 
consistency to producer to manage?

>Both the "scheme" and "label" are optional, but the "term" attribute
This term/label might solve the issue when the user changes the 
name(label) for a category, but the user has the extra burden to 
maintain the terms, labels and their mappings.

>any number of atom:category elements.
Does the absence of category construct for entry imply the category of 
the entry defaults to that of the feed? I guess not. Need to clarify 
this bit.

><category scheme="http://dmoz.org" term="/Arts/Animation/" label="Animation" />
Do we allow multiple category construct with the same (scheme, term) but 
different labels? In following example, the second label is the Chinese 
translation for "Animation".

<entry>
    <category scheme="http://dmoz.org" term="/Arts/Animation/" 
label="Animation" />
    <category scheme="http://dmoz.org" term="/Arts/Animation/" label="动 
画" />
</entry>

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 9 Nov 2004 15:02:07 -0500

> e.g. with HTML markup.  -Tim

LOL. And I just suggested putting @term in the content.

My reasoning goes like this, the @term is the *real* data, in the 
case of using an existing schema, this the key into that schema.
The @label is just a human readable name that may have no
meaning beyond that one site. For example I will point out 
Mark Pilgrim's category labels which include:

# Those that have just broken a flower vase
# Those that resemble flies from a distance
# Those that tremble as if they were mad

    -joe

---

From: Zhang Yining <[email-masked]>
Date: Wed, 10 Nov 2004 04:04:05 +0800

One case I can think of would be a blog hosting service wants to provide 
a common category catalog that its users can look up and apply to their 
blogs, and at the same time gives user the freedom to personalize the 
display name of the same category.

Yining

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 21:09:20 +0100

> I can't think of any reason why one would need both

scheme="http://dewey-decimal.org"
term="398"
label="Folklore"

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 21:14:38 +0100

> consistency to producer to manage?

That's tricky, but I'm not sure we can really say much without
treading on individual schemes. Maybe just have a default assumption
that in such a case the entry would be considered to be in both
categories.

> maintain the terms, labels and their mappings.

Hopefully their software would look after that.I imagine that in many
cases the term and label would be the same string.

> the entry defaults to that of the feed? I guess not. Need to clarify

Good question. Suggestions?

>     <category scheme="http://dmoz.org" term="/Arts/Animation/" label="动

Oo, again, tricky. Suggestions?

I'm not entirely sure how best the label language should be dealt with either.

Cheers,
Danny. 

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 21:17:51 +0100

> LOL. And I just suggested putting @term in the content.

Heh.

> # Those that tremble as if they were mad

I honestly don't know - there's certainly merit on both sides. I went
for all-attributes because that seemed easiest in RDF/XML (*ducks for
cover*)...

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 21:19:33 +0100

> 'subject' because it's use closely matches that of the

I'd have no objections to that. 

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 13:40:19 -0700

> the entry defaults to that of the feed? I guess not. Need to clarify 

My first reaction is that entry/category would need to override 
feed/category to avoid weirdness when an off-topic entry gets posted. 
If there's an entry/category, override, otherwise inherit. That could 
lead to duplication though, if, for example, the feed/category was 
"programming" and the entry wanted to be about both "programming" and 
"linux". Perhaps that would be the uglier situation (more common?). So 
maybe inherit always, and entry/category adds to the category list. Hmm.

> Do we allow multiple category construct with the same (scheme, term) 
> but different labels? In following example, the second label is the 
> Chinese translation for "Animation".
>
> <entry>
If <category> is a Text Construct (with a few additional attributes), 
xml:lang would serve well:

<entry>
    <category scheme="http://dmoz.org" 
term="/Arts/Animation/">Animation</category>
    <category scheme="http://dmoz.org" term="/Arts/Animation/" 
type="HTML">&lt;blink&gt;Animation &lt;/blink&gt;</category>
    <category scheme="http://dmoz.org" term="/Arts/Animation/" 
xml:lang="zh">动 画</category>
</entry>

(NOTE: xml:lang omitted from the first two, assuming that's the default 
language for the feed).

Otherwise, we might go with this:

<entry>
    <category scheme="http://dmoz.org" term="/Arts/Animation/">
       <label>Animation</label>
       <label type="HTML">&lt;blink&gt;Animation &lt;/blink&gt;</label>
       <label xml:lang="zh">动 画</label>
    </category>
</entry>

...which is shorter when you want multiple labels, but longer otherwise.

---

From: Zhang Yining <[email-masked]>
Date: Wed, 10 Nov 2004 04:41:45 +0800

>that in such a case the entry would be considered to be in both
How about doing away with feed level category info.

Subscribing to/Syndicating a feed of certain category(ies) means to all 
entries that are of any of those categories; This gives the consumer the 
flexibility in subscribing any combination of categories of one's blog 
entries.

>Good question. Suggestions?
Again, only entry level category information stays.

Cheers,

Yining

---

From: Zhang Yining <[email-masked]>
Date: Wed, 10 Nov 2004 04:59:02 +0800

Antone Roundy wrote:

>> Does the absence of category construct for entry imply the category 
>> of the entry defaults to that of the feed? I guess not. Need to 
>> clarify this bit.
>
>
Indeed, overriding does not work, say I have categories of "Java" and 
"Gadgets", and another "Geek" which is conceptualy at the higher level 
than the first two. It's very reasonable to have a "Geek" feed that 
contains all entries of "Java" and "Gadgets" and even entries of just 
"Tech".

For inheritance, what if I would like to subcribe a feed of two 
categories, "Perl" and "XML", and one entry of category "C#" and "XML", 
which feed category does this entry inherit from? And I guess we can't 
really call that inheritance ;-)

Cheers,

Yining

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 19:02:10 -0800

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

---

From: Walter Underwood <[email-masked]>
Date: Tue, 09 Nov 2004 21:10:59 -0800

--On Tuesday, November 9, 2004 7:02 PM -0800 Tim Bray <[email-masked]> 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

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 21:42:13 -0800

>   a display string for the category ("Maritime > Safety")

I wonder why you need both a name and an ID; if you conflate those two, 
you have more or less PaceCategoryRevised.  -Tim

---

From: Danny Ayers <[email-masked]>
Date: Wed, 10 Nov 2004 11:11:01 +0100

> you have more or less PaceCategoryRevised.  -Tim

Yep, I think on the Web these will usually be one and the same, either
a full URI or something that can be used to create a URI when combined
with the taxonomy ID with a # or a /.

Nice to see Walter's analysis. I'd add that RDF schemas/OWL ontologies
could be described as being digraph classifications (possibly cyclic),
though they aren't so likely to be used directly in blog
categorization in this form. A more likely use of these technologies
here through SKOS [1], to use existing taxonomies in a consistent
Web-friendly form, e.g. as in FOAF Output [2].

(Cyc and WordNet are possible examples of what could be used for a
more direct mapping, but work is under way to refactor WordNet in RDF,
possibly using SKOS as a level of concept indirection).

Walter, re. prior art - which came first, Callimachus' catalogue or
Aristotle's Categories? [3]

Cheers,
Danny.

[1] http://www.w3.org/2004/02/skos/
[2] http://www.wasab.dk/morten/blog/archives/2004/07/05/wordpress-plugin-foaf-output
[3] http://classics.mit.edu/Aristotle/categories.html

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Wed, 10 Nov 2004 08:28:38 -0700

> we want to escape that character inside a category name. Which is 
Thus my suggestion to add an optional attribute to indicate what the 
path separator is.

http://www.imc.org/atom-syntax/mail-archive/msg11338.html

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 07:42:56 -0800

> you have more or less PaceCategoryRevised.  -Tim

The simple category names are not unique because of common subheadings.
"Safety" is the name of both "Maritime > Safety" and "Highways > Safety".
So you need some other node ID to distinguish them.

This is a real example from the National Transportation Library
at the US Dept. of Transportation. We added full a topic path
display option because the simple names were insufficient.

I think that LC Subject Headings (LCSH) uses LC Classification (LCC)
as the category IDs, but I'd have to double check that.

In library jargon, "classification" gives a unique hierarchial location
for each document, because it is used for shelf position, while
"subject headings" allow discovery under multiple categories.
A subject heading might have multiple parents, while classification
cannot.

wunder

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 07:54:57 -0800

> Aristotle's Categories? [3]

Ah. Different things. Callimachus (300-240 BC) was doing access, and
Aristotle (384-322 BC) was doing essence. Access is measurable, and thus
engineering. Essence is philosophy. Or religion.

wunder

---

From: Graham <[email-masked]>
Date: Wed, 10 Nov 2004 15:50:16 +0000

> Thus my suggestion to add an optional attribute to indicate what the 

<category title="Maratime">
	<category title="Safety" />
</category>

?

(I'd like atom:category to have an optional href value, btw)

Graham

---

From: Danny Ayers <[email-masked]>
Date: Wed, 10 Nov 2004 17:44:44 +0100

> So you need some other node ID to distinguish them.

Ok, but it does seem to be leading towards a big jump from a simple
string in dc:subject.

> display option because the simple names were insufficient.

Couldn't the topic path be used as the label instead of the name where needed?

> A subject heading might have multiple parents, while classification

Couldn't such a situation be dealt with using multiple elements where
needed, being explicit, something like:

<category scheme="http://library.com/classification"
term="Maritime/Safety" label ="Maritime &gt; Safety" />

<category scheme="http://library.com/headings" term="Safety" label ="Safety" />

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Wed, 10 Nov 2004 09:17:35 -0800

> So you need some other node ID to distinguish them.

Pardon me for being dense, but if you have a unique identifier and a 
display version, why do you need a name too?  -Tim

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 09:45:38 -0800

--On Wednesday, November 10, 2004 08:28:38 AM -0700 Antone Roundy <[email-masked]> wrote:
> Thus my suggestion to add an optional attribute to indicate what the path separator is.

There are a few reasons why we shouldn't do that.

1. There is no need for the client to parse the path. That is, the client
is not going to click on parts of the path to navigate. It may need to
display it, but not parse it.

2. Selecting any character, even a configurable one, makes that character
unavailable for use inside names.

3. Many systems (faceted, geographic, DAGs) don't have paths, so this
would only apply to some.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 10:01:53 -0800

--On Wednesday, November 10, 2004 09:17:35 AM -0800 Tim Bray <[email-masked]> wrote:
>
> Pardon me for being dense, but if you have a unique identifier and
> a display version, why do you need a name too?  -Tim

I should have included examples, but the message was already pretty long.
Sorry about that.

taxonomy ID: National Transportation Library
category ID: 283
category name: "Safety"
display name: "Maritime > Safety"

Another reason for a separate category ID is that taxonomies change,
so the path cannot be a key. A category for a single politician might
move from "Governors" to "Senators" to "Attorney General", and then to
"Retired". If you want to keep the "John Ashcroft" articles together,
then the category ID must be independent of the path.

And then there is the mutiple path issue. Here is a made-up taxonomy
to demonstrate that.

taxonomy ID: US Political Stuff
category ID: jashcroft1
category name: John Ashcroft
display name: People | Politicians | Retired | John Ashcroft
display name: Political Parties | Republican | People | John Ashcroft
display name: Presidential Administrations | George W. Bush | Cabinet | John Ashcroft

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Antone Roundy <[email-masked]>
Date: Wed, 10 Nov 2004 11:10:29 -0700

> display it, but not parse it.

Not necessarily true--the client may use the category path to 
automatically file feeds and/or entries in some sort of hierarchical 
system.

> unavailable for use inside names.

Any well-designed system that has paths will have a way to escape its 
path character, or will not use it in its names.

> would only apply to some.

That's easy enough to accommodate as follows:

1) If @domain is not specified, then the default domain is used. It's 
rules are:
    a) The category name is a hierarchical path.
    b) There is no default hierarchy.
    c) The default path separator is "/".
    d) An empty path separator may be specified (path-separator="").  
This results in a non-hierarchical system.
2) If @domain is specified, there is no Atom-specified default path 
separator.  If the system is hierarchical, @path-separator SHOULD be 
specified.

Thus flat systems that use "/" in names could be done in either of the 
following ways:

<category path-separator="">This / is / not / hierarchical</category>
<category domain="foo">This / is / not / hierarchical</category>

---

From: Tim Bray <[email-masked]>
Date: Wed, 10 Nov 2004 10:22:30 -0800

> I should have included examples, but the message was already pretty 

Walter, this is making me feel really stupid because I'm just not 
getting the point about the category name.

> display name: "Maritime > Safety"

For the computer, I have the taxonomy/category ID pair.  For humans, I 
have the display name.  Who needs the category name?

> so the path cannot be a key.

Right, nobody's arguing against the notion of the ID.  You say you need 
taxID, catID, catName, and displayName.  I'm saying "why catName"?

> display name: Presidential Administrations | George W. Bush | Cabinet 

The notion of having multiple display names hadn't occurred to me but 
seems sound; in which case it has to be a subelement, not an attribute. 
  But once again, I ask, in the example above, why do you need "category 
name"? -Tim

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 11:00:56 -0800

--On Wednesday, November 10, 2004 11:10:29 AM -0700 Antone Roundy <[email-masked]> wrote:
>>
>> 1. There is no need for the client to parse the path. That is, the
>> client is not going to click on parts of the path to navigate. It may
>> need to display it, but not parse it.
>
> Not necessarily true--the client may use the category path to automatically
> file feeds and/or entries in some sort of hierarchical system.

Then fetch the taxonomy definition outside of Atom, implement it locally,
and file the entry or feed properly. Use the categoryID to locate the right
spot in the taxonomy.

Taxonomy representation is well outside the scope of Atom, and well-covered
by existing specs.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 11:20:23 -0800

--On Wednesday, November 10, 2004 10:22:30 AM -0800 Tim Bray <[email-masked]> wrote:
>
> The notion of having multiple display names hadn't occurred to me but seems
> sound; in which case it has to be a subelement, not an attribute. But once
> again, I ask, in the example above, why do you need "category name"? -Tim

It could be that I'm thinking too much about the underlying taxonomy
model, and not about Atom, but I think they are different. The catName
is about this node only, and the display name is created by navigating
the rest of the taxonomy.

It is pretty common to treat the two separately in display, but maybe
that should be done by fetching the taxonomy and interpreting it locally.

Still, I can see clients choosing to list "Water Quality" instead of
"Natural Resources > Pollution > Water Pollution > Water Quality"
(example from http://search.state.mn.us/).

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Tim Bray <[email-masked]>
Date: Wed, 10 Nov 2004 12:17:14 -0800

> (example from http://search.state.mn.us/).

In the interests of simplicity, could you live with 
PaceCategoryRevised, which provides "scheme", "term", and "label"?

BTW, I think that the atom format is just going to have to have 
something for category, if only because it seems to be a first-class 
citizen on the protocol side.  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Thu, 11 Nov 2004 08:30:04 +1100

> display name: Presidential Administrations | George W. Bush | Cabinet | John

gah!

Here we have a mixing of categories and topics, two quite different things.
The topic is John Ashcroft, which can be found in multiple categories, in
this case multiple categories which are defined to contain only one person
each (a little strange).

e.

---

From: Walter Underwood <[email-masked]>
Date: Wed, 10 Nov 2004 14:11:08 -0800

> this case multiple categories which are defined to contain only one person

I'm not sure I understand your usage of the words "category" and "topic".

In this case "John Ashcroft" is a subject heading for entries about
John Ashcroft -- news articles, bios, speeches, rants, whatever. This is
not a categorization of a person object representing John Ashcroft. Sorry
if that was confusing.

This is like the Library of Congress Subject Heading "Lincoln, Abraham,
1809-1865" (there is more than one Abraham Lincoln).

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 13 Nov 2004 02:04:58 +0100

> hierarchical/slash scheme. I believe this should be usable with most

I like it, but would prefer @label as the <category> element's content.  
Other than that, it seems to cover all categorization needs I have.

So: +1.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 12 Nov 2004 21:17:24 -0500

> Other than that, it seems to cover all categorization needs I have.

I have suggested the same modification. Even with that, 
I am +1 on PaceCategoryRevised.

   -joe

---

From: Eric Scheid <[email-masked]>
Date: Sat, 13 Nov 2004 19:44:50 +1100

> I like it, but would prefer @label as the <category> element's content.

+1

e.

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 13 Nov 2004 10:14:34 -0500

> I am +1 on PaceCategoryRevised.

Sorry, that was a typo, I meant to say that I had 
suggested the *opposite* modification, i.e. that
@term be made the <category> element's content.

    -joe

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 14:32:53 -0500

Walter Underwood writes:
> In library jargon, "classification" gives a unique hierarchial
> location for each document, because it is used for shelf position,
> while "subject headings" allow discovery under multiple categories.
	In this distinction between "classification" and "subject" lies the
reason why all attempts at classification or providing "category" support in
open communication systems have failed over the years. People keep trying to
make "categories" work when we've proved over and over again that they can't
work in anything but closed or homogenous groups. What we should do is give
up on categories and find a way to support subjects instead. (in topic map
terms: Stop focusing on Topics. Focus instead on Subject Indicators.)
See: B.4 in http://topicmaps.org/xtm/index.html#conceptualmodel

Categories require agreement that cannot be achieved:
	There are as many systems of categorization as there are users of
information. In fact, single users often utilize multiple context-dependent
systems of categorization. The best that any classification can do is
describe a document or object within the context of one of those systems.
The problem is, of course, that unless we all agree to a common system, the
classification will be meaningless -- and can be harmful.
	It is a commonplace observation in IR and Library Science that the
proper classification of an item can only be known after it is retrieved and
used. You simply can't "pre-classify" an item in advance. On the other hand,
you *can* identify the subject of the item.

Categories are "undemocratic" and repressive when used in open communication
systems:
	For categories to be useful, all viewers of the categories must
either agree on the system of classification or build mappings from a common
system of classification to their preferred systems. However, classification
systems are inevitably influenced by subjective decisions that influence the
thinking of those who use the systems. For instance, at an extreme..., in
one classification system, an argument in favor of "legal abortion" would be
classified as "pro-choice" while in another it would be "anti-life." The
difference is not mere wording -- it implies a framing of the issue. To
force that framing on an open system effectively closes that system.
	On the other hand, there are many fewer disagreements about what
constitutes an item that might be constituted. i.e. we can agree that the
subject "legalized abortion" exists even though we might disagree on how it
is classified.

Categories break I18N:
	Translating a classification system from one language to another is
not simply a matter of translating words. Different languages have varying
ability to communicate concepts and result in their users structuring
classification systems and even arguments differently depending on which
language they are using. Any attempt to get a consistent cross-language
classification system will result in users of one or another language
finding that the very manner in which they think about issues is devalued.
	There is some, but very little, disagreement between users of
variant languages on what "subjects" are. Subjects are much easier to
translate then classifications. (For instance, it is often said that
"Zeitgeist" really has no English equivalent but those of us who speak
English typically just add Zeitgeist to our voculary. Similarly, the English
term "weekend," which refers to an interval of days rather than an instant,
doesn't appear in other languages. Non-english speakers usually incorporate
the English if they want the concept -- think "Le weekend.")

	Personally, I think we should support a "subjectIndicator" which
would be a URI. This should be the focus of the discussion that appears to
surround "categories." The mapping of subjectIndicators to
classifications/categories should be a function provided by the aggregator.
Each user should be free to use whatever mapping they want. For instance,
various organizations (DMOZ, your church, your professional society,...)
might use Topic Maps to define these mappings in an interoperable way.
	If folk insist on knowing an author's view of classification, we can
add the various attributes proposed in the "PaceCategory*" stuff as optional
elements to the "subject" element. These should, however, be seen as simply
providing hints, not as making definitive statements about classification.
	Trying to solve the classification/category problem is futile. We
should be focusing on subjectIndicators. Given subjectIndicators, we'd be
able to have democratic, I18N compliant, personalized and relevant support
for classification of entries.

		bob wyman

---

From: Danny Ayers <[email-masked]>
Date: Tue, 16 Nov 2004 22:01:21 +0100

On Tue, 16 Nov 2004 14:32:53 -0500, Bob Wyman <[email-masked]> wrote:

Bob, quick question: Take PaceCategoryRevised. Replace the word
"category" with "subject"/"subjectIndicator" throughout. What doesn't
work?

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 16:38:48 -0500

Danny Ayers wrote:
> "category" with "subject"/"subjectIndicator" throughout. 
> What doesn't work?
	Well, I don't think subjects should have schemes. They should just
be URIs. What I would probably do is something like this:

<subject 
	subjectIndicator="http://bobwyman.pubsub.com/" 
	label="Bob Wyman's Blog">
  <category 
	term="Writers/Idiocy/Complete" 
	label="Crazy People" 
	scheme="http://pedantic.org/topics.xtm"/>
</subject>

	Where "category" is an optional child element but "subjectIndicator"
is required. Thus, the minimal form for this subject would be:

<subject subjectIndicator="http://bobwyman.pubsub.com/"/>

	Using this method, it is possible for many different systems to
assign distinct classifications to unique subjectIndicators. Additionally,
distinct systems can map multiple subjectIndicators to a single
classification if there isn't consistency in the use of subjectIndicators.
It also becomes very easy to convert between systems (just lookup the
subjectIndicator to discover the classification) and it is easy to provide
classification in an I18N context.
	Basically, if we switch our focus to subjectIndicators, the world is
wonderful and terribly simple -- except for the minor problem which is that
everyone except librarians and IR specialists think of this stuff in terms
of classification and we'll have to spend lots of time telling people "No,
that's not a 'subject' it's a classification....!"

		bob wyman

---

From: Graham <[email-masked]>
Date: Tue, 16 Nov 2004 22:18:34 +0000

Nobody cares Bob. The primary use of the category element is to pass on 
the the aggregator the categories already in use in blogs - eg go to 
http://www.gizmodo.com/ and look at the little "filed under" subtitles. 
The relative merits of different theories of categorization are 
irrelevant (as, quite possibly, are the scheme and term attributes in 
the current proposals).

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 17:38:55 -0500

Graham wrote:
>Nobody cares Bob.
	Yup. You're probably right. 'tis a pity...
	Would the various authors of PaceCategory* proposals at least
consider providing an attribute for subjectIndicator so that those of us
with quixotic tendencies can spend the next few years vainly trying to get
people to use it?

		bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Tue, 16 Nov 2004 15:58:30 -0700

> 	scheme="http://pedantic.org/topics.xtm"/>
The idea makes sense, but I don't quite understand how to translate it 
to practice.  A few questions:

1) If I use the URI "http://www.geckotribe.com/atom" to talk about the 
Atom format, and you use "http://bobwyman.pubsub.com/atom" for the same 
thing, how is a client to discover that these are the same subject?

2) What's to prevent two people from using the same URI as the 
subjectIndicator for different subjects?  For example: 
"http://www.xerox.com/" -- is that the company Xerox, or copy machines 
in general?

3) How should one go about selecting a URI to represent a particular 
subject, especially if the subject isn't something on the internet?  
Would you expect publishing tools to present a UI that hides the URIs?

I guess I'm having a hard time seeing how, in practice, this would be 
better than the existing proposals.

Antone

---

From: Danny Ayers <[email-masked]>
Date: Wed, 17 Nov 2004 13:03:21 +0100

On Tue, 16 Nov 2004 16:38:48 -0500, Bob Wyman <[email-masked]> wrote:
> be URIs. 

Hmm, couldn't the scheme slot contain the subject indicator URI? (or
scheme+term concatenated?)

>What I would probably do is something like this:

>         scheme="http://pedantic.org/topics.xtm"/>

Sorry, I can't see the intent here - in English?

I've not gone into TMs in any depth myself, though it's clear they
have got these things worked out pretty well. Over in the RDF world
the SKOS vocabulary [1] is the place for heavy-duty
thesaurus/categorization kind of stuff, and coincidentally the core
vocab got a subjectIndicator property about a week ago [2].

I'm still optimistic that references can be made to TM PSIs and SKOS
mappings. The current Pace has a slot for a for a URI one for a string
(in addition to the label), that must be adequate, surely?  Maybe some
renaming of the elements/attributes could make things clearer?

> that's not a 'subject' it's a classification....!"

That is a point - and as Graham says, the primary use will be the
simple use as found in blogs. But it would be a shame if more
industrial-strength classification/categorization weren't possible.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 18 Nov 2004 01:45:35 -0500

Antone Roundy wrote:
> 1) If I use the URI "http://www.geckotribe.com/atom" to talk about
> the Atom format, and you use "http://bobwyman.pubsub.com/atom" for
> the same thing, how is a client to discover that these are the
> same subject?
	Do you really mean the same "subject" or did you mean the same
"topic" or "category"?
	If you meant the same "topic/category, then XTM would encode this
something like the following: (Note: I'm not an XTM guru. Please forgive
errors in syntax...) The intent of the topic definition below is to say that
both subjectIndicators refer to the same topic "The Atom Format." The

<topic id="atom_format">
  <baseName><baseNameString>The Atom Format</baseNameString></baseName>
  <subjectIdentity>
    <subjectIndicatorRef xlink:href="http://www.geckotribe.com/atom"/>
    <subjectIndicatorRef xlink:href="http://bobwyman.pubsub.com/atom"/>
  </subjectIdentity>
</topic>

	Given that you might be supporting people working in multiple
languages, you might find it handy to specify the name of the mapping from
the subjectIndicators to topics in more than one language. Perhaps, both
French and English... If that was your desire, then in XTM, you would
specify language by establishing a "scope" for the baseName:

<topic id="atom_format">
  <baseName><scope><topicRef xlink:href="#en"/></scope>
    <baseNameString>The Atom Format</baseNameString>
  </baseName>
  <baseName><scope><topicRef xlink:href="#fr"/></scope>
    <baseNameString>Le Format Atom</baseNameString>
  </baseName>
  <subjectIdentity>
    <subjectIndicatorRef xlink:href="http://www.geckotribe.com/atom"/>
    <subjectIndicatorRef xlink:href="http://bobwyman.pubsub.com/atom"/>
  </subjectIdentity>
</topic>

	The definition above could, of course have been done in two
declarations -- even in different files. However, the two would still be
linked by the common subjectIndicators.

> "http://www.xerox.com/" -- is that the company Xerox, or copy
> machines in general?
	Nothing other than a desire to make interop work. My assumption is
that rules would say that people should create globally unique URI's for new
subjectIndicators (tagURL's would work fine). Also, we should probably have
a registry for these things. We'd be happy to fund and manage such a
registry if subjectIndicators are accepted in Atom.
	In any case, I think we'll eventually find that people would tend to
use commonly accepted subjectIndicators and then map them to "local" topics
or categories. Getting conformance on subjectIndicators is much less "bad"
then getting conformance on classification schemes since there is less
"subjective" content to a subjectIndicator then there is to a
classification. Accepting common classifications or topics can often force
one particular point-of-view on others -- not good.

		bob wyman