Subject: Re: SDP "category" or "thread" field

From: [email-masked] (Kevin C. Almeroth)
Date: Wed, 3 May 1995 22:25:21 -0400

An inherent problem with using pre-defined categories is that at some 
point, some two users will disagree on what the set of well-known 
categories should include.  One person will want all the IMS sessions 
together.  One person will want all the ``news'' related sessions together, 
etc.  So pre-defined categories are out.

   So the question needs to be answered:  Does a user-defined category 
field add anything NEW to the announcement?

   A random thought: I envision an sd-like application that parses the 
name and description, then groups all the IMS sessions or all the default 
MBONE sessions, or all the IETF sessions into its own hierarchical 
category.  This of course can be written now.

   So is there any information that we wouldn't want to include in the
name or description, but include in a category field?  Maybe ``category`` 
should be 0 or more ``keywords'' like ``private'', ``shuttle'', 
``concert'', etc.

   I'm starting to think that category might be redundant since all the
useful information should already be in the name and description fields.

-Kevin Almeroth

---

From: Mark Handley <[email-masked]>
Date: Thu, 04 May 95 16:34:08 +0100

>should be 0 or more ``keywords'' like ``private'', ``shuttle'', 

Unfortunately there are some problems with keywords too.  If you
actually want to find out about new sessions, then you have to use
keywords as an exclusion list rather than an inclusion list.  If the
keyword set gets large (and lets face it, with several hundred
languages out there it will do), then this stops being useful unless
some keywords are compulsory (such as the language the session is in)
so that you can use them as a first pass filter, and if you're using
it that way it's awfully close to a hierarchy.

Hierarchical categories suffer less from having to make an
inclusion/exclusion choice because the choice can be context sensitive
(ie depend on the higher categories).

If you have a frequently used keyword list to restrict the choices,
you'd better provide translations to other languages and unfortunately
single word translations are never a good match :-(

>useful information should already be in the name and description fields.

But they can be in any language and (given unicode encoding) any
charset.  

Of course if we do add an extra "subject" fields of some form,
receivers can always ignore it, or categorise on name and information
but at least there is some info as to how the session creator thought
it should be categorised.

Mark