In the introspection document, would the following meet your needs?
<collection ...>
...
<categories fixed="no">
<atom:category scheme="sixapart:category"
term="/Animals/Mammals/Felines/Cats"
label="Cats" />
<atom:category scheme="sixapart:category"
term="/Animals/Mammals/Canines/Dogs"
label="Dogs" />
</categories>
</collection>
Obviously, if the categorization namespace was huge and complex,
including it inline like this would get rather cumbersome... therefore,
if you had some other more efficient way of describing your
categorization namespace, you could use an href instead.
<collection ...>
<categories fixed="no"
type="application/rdf+xml"
href="http://.../categories";>
</collection>
The fact that the categories element has fixed="no" indicates that
clients can include additional categories that your system could
translate into tags and/or categories created on the fly.
- James
Byrne Reese wrote:
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.
