A use case from Boston Museum of Science:
a) The dotlrn-ecommerce system has a bunch of reasons to use categories, including:
--- some packages like expenses and scholarships
--- the ability to use extensible categories to categorize the courses offered
When we originally built the system, the site-wide categories pages worked fine as collectively, these category trees all involved dotlrn-ecommerce
b) We are expanding the Museum of Science is expanding their system to manage all their public forums, with the additional capability of categorizing threads. Each forum has a category tree.
As different people maintain "a" and "b", seeing all category trees in one place poses some confusion.
I'm not sure "subsite-aware" is precisely ideal (if you really mean you have to segregate by different subsite package)....The user databases, general site map, etc. are the same so these are not different subsites.
Ideas that would work for them would be to have category administration pages that would show all the categories trees for a given package and/or all the category trees for a given package and anything lower than that in the site map. (then, as specific case of this would be category trees for a specific subsite package and/or below).
>Since category_trees are acs_objects, it seems a good use of context_id to store the subsite_id for every category_tree created (if needed by a client package like xowiki).
So more specifically, my suggestion would be to have the context_id to store the PACKAGE_ID for every category_tree created - so then you'd have the flexibility to show category trees by ANY package, including subsite.
