Forum OpenACS Q&A: A general-ratings package for OACS

I am new to ACS, and have a lot of experience in web-based KM
development. The design and development of a "general-ratings"
module is something I'd like to work on.

I think the idea would be to allow the creation of "rating-
dimensions." Each dimension would have it's
own "scale," "description," and "instructions." The scale would be a
numeric range or a list of "phrase value pairs." The description
would be the "title." The instructions could be additional help text
available to a user. Each rating-dimension could be associated with
one or more objects in the system. A rating would be a relationship
among a user, an object, a rating-dimension, and a point on the
rating-dimension's scale.

This could be an object-level service. Users could rate other users,
themselves, a bboard answer, or an entire bboard instance. It would
depend upon the application.

I'd be interested to know if anyone has any caveats, ideas, or
interest in this sort of thing.

Looking forward to it.

This package (or service-contract, to be more precise) sounds
like it does pretty much everything I'd want to do with a
general-ratings tool. I'd love to see this get done.

Hi Dean!
we have also wrote something similar to what Jonathan gave to you, see it live at Lectario. Its done under openacs 3.2.5, the interest thing is that with this rate system you can add it to different object/modules in the site, also it will collect a general rate for all your contributions so you can see how is your average rate in the community and the others can see it too!

About a KMS, we have been talking about this with Malte Sussdorff, he wrote a very good paper about this but I can't find it. Just a few days ago we exchanged some emails about starting a KMS using openacs 4.5 as the base.

Maybe here is the thread that could start the future KMS, so we can get in contact and start with this!.

General-ratings is a great place to start adding KMS functionality to the OACS. I suggest we all focus on that and widen the scope later.

Yes, I agree. Let's take the approach of slipping in the thin end of the wedge first. As time goes on we can pound it in further and futher ...

I agree.  I was just thinking about that myself.  Bboard would be a great starting place.  I expect to start tucking into this later this week.  I still need to become comfortable with the wide array of existing ad_* and ns_* functions at my disposal.  There is a bit of a curve, as you all know!

Just some comments from our experience:

1.) we might want to have one column for the rating and another for the reading of a page... This way we can combine: how many times read + avg rating + how many times rated...

2.) we might want to build a trigger that variably updates other tables like bboard with avg_rating + n_readings + n_ratings so that you don't bust the db, whenever you want to show avg_rating for every post...

There is a similar implementation within 3.2.5 general_links...

Dean ... The convention in the ACS is to pass a "return_url" variable in the querystring. You can build it like this:

http://foo.com/bar?return_url=[ns_urlencode [ad_conn url]?[ad_conn query]]

then you return like this:

ad_page_contract {
    return_url example
} {
    return_url:notnull
}

... do lots of cool stuff ...

ad_returnredirect $return_url

In your case you probably want to use the form builder (despite its flaws - we hope to improve it in the upcoming months) in a template. Doing it this way means the client page can simply include it Also since you're talking about a form obviously you wouldn't pass a query string but rather would pass it as a hidden form variable. The above-mentioned form builder API allows the definition of hidden variables. If you e-mail me I can point you to some pages that use it ...

See acs-subsite/www/shared/confirm.tcl/adp for a templated confirmation page and session-update.tcl in the same directory.

The first is a template that allows a user to answer "yes/no", suitable for including from another template.

The second example's both easier and more complex. It just changes a session property and returns, but it signs and verifies the return_url value and makes sure that the connection referrer value matches the one passed along as one of the parameters. I used it in a project to set some semi-sensitive properties (backed up by permissions checking as the comment in that script suggest one do!) and wanted to lower the chances that someone might spoof the page.

We built our small rating package using as a base the general-comments package (the general-links its pretty much similar). I based my solution from some code that Lars Pinds gave me too (www.pinds.com).

I'd strongly urge not to reinvent the wheel but take Lars Pinds rating system.

It would need some cleanup especially in regards to documentation as well as support for multiple rating-dimensions, though Lars might correct me and say I'm completely blind (I did not even detect the pinds-ratings DDL).

I'm currently looking through Lars' ratings system as well as some other materials graciously proffered by other members of the community.  I need to sort them all out now.  I expect this will take a day or two.

Malte Sussdorff is right on in thinking that there should be a user-tracking package.  Whether or not the e-commerce package has the beginnings of such a thing, I don't know.  The goal would be to have a table that recounts a user's experience on the site.  This way we could scan a user's visit chronologically and count certain "events."  Such as "Did the user navigate to a list of content and then go away?" and "Did the user navigate to a list of content and then access some content?"

This way we can see what is most useful and to whom.

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.

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).

Check out acs-kernel/sql/[PG/Oracle]/acs-relationships-create.sql

So it looks like a relationship is an entity. Whew. OK. Should I subtype acs-relationship with gr_ratings? If so I guess the relationship would be called rated with user on one side and some object on the other. date_rated and dimension_id wouldn't be part of that relationship. Problem is dimension_id will figure into most queries. Is this a problem?

I wrote a bunch of SQL today.  It all executes, which is nice.  i haven't tested my functions yet, though.

I have two questions today.  The first concerns my relationships.  Essentially there is one relationship among three participants.  A 'rating' is what a 'user' assigns to an 'object' in a given 'dimension.'

To me it looks like one of those three participants winds up as an attribute, which doesn't feel right at all.  As of today, I have the relationship 'gr_rating' set up between 'user' and 'acs_object.'  I manually put the dimension_id in the 'gr_ratings' table after my call to acs_rel__new().  Is this quite good enough?

My other question is more down-to-earth.  I'd like to check that the rating passed in to the system is between the max_rating and min_rating for the given dimension.  Which is best: to use logic in a function or to create a rule in the db?  A check won't work in PostgreSQL - no sub queries in there.

Thanks, Jonathan.  I really appreciate all the support I'm getting here.

Thank you for your kind words, Tali.  I’m really learning a lot in my work on this system.  It addresses so many issues I’ve faced in web development.  The system truly feels like the product of years of experience and many smart people.

I think this ratings package will be a success.  My only challenge is holding back.  I want to get something workable out the door so people can integrate it into their projects.  Then their feedback can guide futher development, not my conjecture!

At the risk of taking a useful thread way off topic...

They're all really helpful, although Vinod is... well Vinod's actually an MD in meatspace so he can't be trusted with anything that has to do with "life preserving and sustaining" advice. He's fun to laugh at, though. At, not with.

How many times do I have to tell you Talli... While you may consider "your problem" to be "life threatening", the medical establishment disagrees, so I'm going to have to insist that you pay for your Viagra like everyone else. 😊 😊 😊 😊

sloan-bboard won't work with PostgreSQL at first, so I suspect it will be awhile before the majority of our folks switch to it.  It shouldn't be difficult to integrate "general ratings" with any particular package, so I don't think Dean would lose much by doing for the regular bboard first.

I also suspect it will take awhile for dotLRN to settle down, and folks might want to wait until it does before porting it.  Or at least they'll want to tackle those parts that *are* stable first.

Dean, FYI, Peter V from Ybos just posted a link to yet another
ratings package that you might want to comb through. You can
find the reference in this thread:

https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0004o0&topic_id=12&topic=OpenACS%204%2e0%20Design

The direct link to the code is here:

http://developer.ybos.net/modules/stored_module-detail?module_id=2133

Note that (AFAICT) this module is for ArsDigita's (old) version of
ACS 4.x, which means it's Oracle-only, doesn't know about the
request processor, and is probably missing a bunch of other
stuff that has been added since AD abandoned ACS Tcl.

I've been searching around for information about rating systems for OpenACS.  I'm experimenting with v 5.0.4 + AOLserver 4.0.1.

It's been a few years since the last post in this thread. Does anyone know if there has been any progress on a general-ratings system?  If not, are people using anything that is different from the packages mentioned in this thread (lars-ratings, ect..)

Thanks,

Brian