This being said, should Ratings Dimension itself be a subtype of acs-object?
Yes, it should.
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?
Check out acs-kernel/sql/[PG/Oracle]/acs-relationships-create.sql
This allows for the definition of a relationship between two object types. You can define the number of objects allowed on either side of the relation.
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.
I think ignoring the problem for round one is OK. We need to allow admins to delete a dimensions and associated ratings, which will mostly be useful if you make a typo when defining it and notice before too many ratings accumulate.
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?
Yes, please do. Use the tag-closing proc used in places like glossary and bboard to guard against errors in entered HTML.
In fact at some point I want to add a "text-html" widget type to the form builder that will present a uniform widget style for text/HTML blocks (you'll notice slight differences in the definition of the drop-down select lists used in individual packages today).
