As for requirements, this is what Six Apart is need of:

A way to represent the following:
A) relatively fixed heirarchies - i.e. categories
B) free form ontologies - i.e. tags

In our world:
* Tags and categories consist of two properties: a name and id.
* Categories are heirarchical. Categories can have only one parent, but
many children.
* It would be nice if we could communicate a human readable
representation of the
  - category name
  - category id
  - AND its place in the heirarchy
* Tags have these properties: a name, a normalized name an id

For example, we were going to implement categories this way:

<category>
  <scheme>sixapart:category</scheme>
  <name>/Animals/Mammals/Felines/Cats</scheme>  
  <label>Cats</label>
</category>

And tags this way:

<category>
  <scheme>sixapart:tag</scheme>
  <name>new_york</scheme>  
  <label>New York</label>
</category>

NOTE: In the above model, we are not representing category or tag IDs.
And indeed, may not be completely necessary (now that I am looking at it
again :)

Introspection:
* Six Apart would really like a way to enable users to discover what
categories and tags are available on a weblog/journal via Atom.

Creation:
* That there be some facility in Atom to define new categories and tags
on the fly without the need to [necessarily] provide a complete
representation of the <category>. For example, Six Apart would generate
the normalized version of a tag, the client shouldn't have to (user
enters tag: "New York", Six Apart normalizes/canonicalizes it into
"new_york")



> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
> Sent: Tuesday, January 24, 2006 9:38 PM
> To: Atom-Protocol Protocol
> Subject: Category Listing
> 
> 
> 
> Ok, so let's take a step back on this one. What are the 
> minimum requirements we need to meet for categories?
> 
> a) Match the existing level of functionality exposed by 
> existing blog implementations?
> 
> b) Provide a means of managing categorization namespaces?
> 
> c) .... what else? anything else?
> 
> What use cases are y'all thinking we need to cover for this?
> 
> - James
> 
> 
> Tim Bray wrote:
> 
> > PaceCategoryListing - REJECTED: There was mild support, but an 
> > entirely-correct argument that the Pace is incomplete.  There is no 
> > normative-prose explanation of what "inline" and "out of 
> line" means.
> > However, our sense is that the WG would support  the 
> addition of some 
> > sort of category-listing (it seems required by many known 
> publishing 
> > systems); another try is probably worthwhile.
> > 
> 
> 

Reply via email to