[Zope-PTK] "score" or "sortOrder" for PortalContent?

[Chip Vanek]

Yes, it does make sense to only include one new element
in PortalContent.  This element could guide the sorts for
listings and be overloaded in meaning.

>-----Original Message-----
>From: Kevin Dangoor [mailto:kid@kendermedia.com]
>
>----- Original Message -----
>From: "Chip Vanek" <chip@upcast.com>
>
>> I do think that this should be a standard part of PortalContents.
>> To allow reasonable flexability there should be two elements.  One
>> called "score or sortOrder" to represent derived importance based on
>> pageviews and date.  Another element called "rating" to hold explicit
>> user input on importance.  List views could be generated from one of
>> these "importance scores" or a weighted average.
>
>I was thinking that the "score" or "sortOrder" property/method 
>would likely
>be overridden by different kinds of content. My main intention 
>was just to
>advocate a particular interface that we can count on for 
>PortalContent and
>that should be part of a Portal's Catalog.
>
>I'm not sure that I agree that a "rating" element should be a 
>part of the
>standard PortalContent object, because "score" is a method that can be
>overridden to incorporate user input as well. I've given little bits of
>thoughts here and there to ratings, and I think ratings should 
>be a little
>more complex because you want to be sure that a given Member 
>rates an object
>only once.
>

I am presently still using the ZODB and the transactional overhead
of storing information like ratings is a pain.  It does make sense
to overload the "sortOrder/score" element with rating information.
The ratings issue does quickly get complicated.  You might also
want historical ratings to show the trend of ratings over time.
I did a braindead implementation of ratings for the PTK with totalRatings,
numRatings, and aveRating.  I tried one with a list of ratees to address
the only once issue but, backed out of the whole thing because of
the explosion of the size of the ZODB.

>I've given a little thought to ratings implementation, but not 
>enough at
>this point...
>
>Kevin
>
>