Forum OpenACS Q&A: A few more Qs

OK, I'm getting into this now.  Lars' material is very helpful, as is the code Don sent me offline.  I haven't read Malte's paper yet, but it looks excellent.

I'm in productivity mode, spending a couple hours a day moving forward.  I have some design questions, though.

First, I have the notion of a Ratings Dimension, an example of which would be as follows:
name = Interest Level
min_value = 0
max_value = 5
description = Allows a user to register his or her interest in this item.
instructions = 0 for Low Interest 5 for High Interest

I think I want Ratings Dimensions mapped to contexts.  To illustrate I'd like the above example to be applicable to any object on the site, but another dimension, "Technical Merits", would apply only to objects of type "photo."  Another dimension, "Willingness to help", may apply to Forum respondents and FAQ maintainers.

This being said, should Ratings Dimension itself be a subtype of acs-object?  I'm trying to figure out how to assign it its id, and this kind of comes with subtyping object.  I don't know if there is any other subtype of acs-object that would be a better supertype for Ratings Dimension.  If I don't make it an acs-object, then how would I get unique ids?

There's also the Rating itself.  This describes the rating (in some dimension) a user assigned an object.  I'll also put date_rated in there.  Should this relation have it's own unique id?  I'm leaning towards it.  If it does, should it be a subtype of acs-object?  Would some other acs-object subtype serve as a better supertype?  If not, where is there a good example of unique id sequence generation in use outside of the acs-object model?

Here's another one, more spec-y than techie: should a Dimension owner (or admin) be allowed to change the max and min value?  This would screw up all the data retrieved thus far.  We could go over the old data and scale it up or down, but they're integers now and there'd be data bruising with the round up/down.  Maybe I'll make them NUMBERS for now so we can tackle this in the future.  It's a version 2 thing, I think.

Last, I've noticed that many packages that handle text blocks of any size allow the user to specify whether or not it is plain text or HTML.  Would this be of value in the "instructions" and "description" fields of my Rating Dimension?  These values would show up as the interface dictates.  For instance, a user looking at the ratings of a photo she uploaded could click to see the description of this rating dimension to better understand the thinking that went into the user's rating process.  I'm leaning toward html_p fields for "instructions" and "description" right now.