From: Dan F <dfr...@cs...> - 2004-03-24 19:29:48
|
Okay, at Reini's request, I attach a pseudo-patch of functionality to add page rating to Phpwiki ("RateThisPage"). I would be delighted to help or see this integrated. Notes: 1. Known bugs a) When you delete a page, its corresponding ratings are not deleted. b) The smily faces for submitting rating are too small a target for a mouse-click, since they are divided into halves. 2. Known limitations a) The changes are only integrated into the PearDB backend. b) It is not internationalized, though I tried to be i18n friendly. 3. It requires a schema change (add a rating table). 4. The images all go in themes/default/images. 5. The get_rating interface is not quite general enough yet. One should be able to make "rater" or "ratee" arrays as well as scalars. 6. This patch contains none of our code to display ratings. We've created a couple new plug-ins, as well as messed with the PageList object to display ratings. Some of that still needs to be cleaned up. 7. Again, I ripped out pieces of the patches that weren't relevant, so it might not be strictly applicable as a patch. Also, I might have left out something. 8. This is protoype code, still somewhat in flux. That's a lot of caveats. However, I think this pseudo-patch is still useful to show what is involved, and as a first step. Later I'll try to put together another patch with displaying ratings. We have a couple of simple things, but there is a lot of work to be done in that area. Thanks for your attention. I look forward to feedback. Dan -- Dan Frankowski dfr...@cs... 612-626-8396 |
From: Dan F <dfr...@cs...> - 2004-03-24 19:48:16
|
Dan F wrote: > >+/** >+ * Put in Javascript functions to support rating a page. At present, >+ * it only supports rating the page this Javascript is placed on. >+ * Perhaps that should be generalized. >+ * >+ * This needs to be put in the <head> section of the page. >+ * >+ */ >+function RatingWidgetJavascript() { > > I just noticed this comment. It is not true (old). The rating widget supports rating the page specified by pagename, not just the page it is on. This is useful because we (often!) display a PageList with a ratings widget next to each page in the list. Dan |
From: Reini U. <ru...@x-...> - 2004-03-24 20:04:54
|
Dan F schrieb: > Okay, at Reini's request, I attach a pseudo-patch of functionality to > add page rating to Phpwiki ("RateThisPage"). I would be delighted to > help or see this integrated. Hmm. Quite a lot of core changes. I'd rather try to do the actions as plugin, and store the rating as page metadata. To be WikiDB backend independent. I'll come with my suggestions soon. Today is TV night: Arsenal - Chelsea. > Notes: > 1. Known bugs > a) When you delete a page, its corresponding ratings are not deleted. > b) The smily faces for submitting rating are too small a target for a > mouse-click, since they are divided into halves. > 2. Known limitations > a) The changes are only integrated into the PearDB backend. > b) It is not internationalized, though I tried to be i18n friendly. > 3. It requires a schema change (add a rating table). > 4. The images all go in themes/default/images. > 5. The get_rating interface is not quite general enough yet. One should > be able to make "rater" or "ratee" arrays as well as scalars. > 6. This patch contains none of our code to display ratings. We've > created a couple new plug-ins, as well as messed with the PageList > object to display ratings. Some of that still needs to be cleaned up. > 7. Again, I ripped out pieces of the patches that weren't relevant, so > it might not be strictly applicable as a patch. Also, I might have left > out something. > 8. This is protoype code, still somewhat in flux. > > That's a lot of caveats. However, I think this pseudo-patch is still > useful to show what is involved, and as a first step. > > Later I'll try to put together another patch with displaying ratings. We > have a couple of simple things, but there is a lot of work to be done in > that area. > > Thanks for your attention. I look forward to feedback. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F <dfr...@cs...> - 2004-03-24 23:56:21
|
Reini Urban wrote: > Dan F schrieb: > >> Okay, at Reini's request, I attach a pseudo-patch of functionality to >> add page rating to Phpwiki ("RateThisPage"). I would be delighted to >> help or see this integrated. > > > Hmm. Quite a lot of core changes. > I'd rather try to do the actions as plugin, and store the rating > as page metadata. To be WikiDB backend independent. Possible, but I would be concerned for performance if I'm not able to use a real database for storing ratings. The most important fact: a page has more than one rating. There can be (and will be!) many ratings per page (ratee): different raters (users), in different dimensions. Are those stored per page (ratee)? Then what if I wish to access the ratings per rater (user)? We plan several user-centered applications like: a) show my ratings b) show my buddies' ratings c) show how my ratings are like my buddies' d) show where I agree/disagree with my buddy e) show what this group of people agree/disagree on If the ratings are stored in a real DB in a table, we can index the ratings by rater and ratee, and be confident in performance. Currently MovieLens has 80,000 users, 7,000 items, 10,000,000 ratings. This is an average of 1400 ratings/page if each page were rated equally. However, they're not: the most popular things have tens of thousands of ratings (e.g., "Pulp Fiction" has 42,000 ratings). If ratings are stored per page, you would have to save/read huge page metadata every time someone submits a rating. Finally, the movie domain has an unusually small number of items-- I'd expect a lot more in music, for example. Offer metadata as an option if you want, but please don't preclude a real database backend. > I'll come with my suggestions soon. > Today is TV night: Arsenal - Chelsea. Have fun. Dan |
From: Reini U. <ru...@x-...> - 2004-03-25 11:50:53
|
Dan F schrieb: >> And, we'd like to push out the 1.3.8 very soon so the changes in the >> core are not welcome at this point unless necessary. > > That's fine. What to release in 1.3.8 and how to do ratings are > completely separate issues, right? I am talking about doing ratings, not > which release it goes into. In fact, I'd prefer you didn't put it into > 1.3.8, since that would delay it and might result in not having long > enough to think about how to do ratings correctly. For sure the RateThisPage feature will not delay the 1.3.8 release! The recent new features were done to help to understand outstanding issues. I hope to finish testing with HttpAuth and Ldap today. Maybe I get to the CGI problems also. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2004-03-26 10:31:30
Attachments:
RateIt.patch.tgz
|
Attached is my current RateIt plugin with the wikilens theme. (without SQL version yet, just take your version.) One problem: Your lib/rate.php was missing and so I don't know why the javascript request doesn't work in my version. some magic imgsrc hackery. I changed it a bit: RateIt is a action page with a button. When you click on the button you call the current pagename with the RateIt action, to display the statistics of the current page. When you click on the rate smilies, the rating should be stored. When you click on the trashcan (or cancel button), the rating is deleted. <?plugin RateIt ?> is in a span tag, so it's easy to add it to the end of navbar line. navbar.tmpl: <?=$s?><?= Button("BackLinks", _("BackLinks")) ?> <?php } ?> <?php if (!empty($user)) { ?> <?=$s?> <?php $loader = new WikiPluginLoader(); printXML($loader->expandPI("<"."?plugin RateIt ?".">",$request,$dbi->_markup)); ?> Dan F schrieb: > By the way, if you are interested, I encourage you to take a look at the > existing Phpwiki site with the ratings widget: > http://dickens.cs.umn.edu/dfrankow/wikilens. We are just starting out, > but it's fun. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2004-03-26 20:57:35
|
Dan F schrieb: > Reini Urban wrote: >> I wrote it as plugin, but it's not really useful as plugin, only the >> statistics browser is useful as plugin. > > I'm sorry, I don't quite understand. > >> But I've put it into a seperate "wikilens" theme. > > I did a "cvs update -d" in my checkout of CVS mainline, and I don't see > a wikilens theme. No, it's private theme, not to clutter the existing files with special modifications. It's only in my previous rateit.patch.tgz >> Dan F schrieb: > Thanks very much for your efforts. What are your thoughts for next > steps? When you have time, of course. get it working (lib/rate.php), add the missing SQL stuff for wikilens mass usage, add the statistic modes in the plugin, add the PageList custom type "Rate" test the metadata storage method. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2004-03-29 12:12:10
|
Dan F schrieb: > The "Suggest" code is at the following web page: > http://www-users.cs.umn.edu/~karypis/suggest/. It is a C library. Aha. Good for a CGI. I might try to implement similar code in PHP for a simplier recommendation engine. Best would be to do offline clustering to speed up online queries and to create buddies (clustered users) automatically. I think I already have some lisp code to do this :) > Thanks for your thoughts. You are already ahead of me. I have not even > had a chance to fully understand your RateIt patch. I will setup a public test site soon. My changes are: RateIt as button after [BackLinks] [RateIt] ***** x Cancel as image button If you click at [RateIt] it displays the RateIt plugin for the current page, which displays the current statistics for this page. "Number of ratings, Average rating, your rating resp. your recommendation" And various links to more advanced queries, like "top 30 recommended pages for you", "your top 30 rated pages", "top 30 pages" (rated merged with recommended), "your buddies with similar taste", ... All these modes are handled by the RateIt plugin. I also write for most plugins a box method which is used to display a short version in a sidebar box. (RecentChanges, SignIn, WhoIsOnline, BackLinks, Calendar, FindPage, FullTextSearch, ...) For the future sidebar based themes. The RateIt::box() will display the rate buttons and the current recommendation. So you are not tied to the wikilens theme, which is currently responsible to display the navbar RateIt buttons and javascript code. I want to use it for my movie database and better for our free radio music archive, which I'm currently maintaining. The music archive creates our nightly playlists automatically from some predefined parameters and optionally based on our editors ratings, which is naturally a very problematic issue ("taste"), and each editor only knows ~20% of our songs. But at first I want to finish my database linking code, which will create wiki pages on-the-fly from sql queries and a template. (e.g. 6500 songs, 500 movie reviews, ~237000 imdb movies, 3952 movielens movies, ...) This should be dynamic, no static wiki pages. You might need it too to keep your category entries up-to-date. PhpWiki just as alternative front-end. The question is if to allow wiki editing of the various content fields and to update the external database accordingly. And all this needs paging support (e.g. limit=10,30) in AllPages, BackLinks, ... -- Reini Urban - Radio Helsinki http://helsinki.at/ http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F <dfr...@cs...> - 2004-03-29 17:09:20
|
Reini Urban wrote: > Dan F schrieb: > >> The "Suggest" code is at the following web page: >> http://www-users.cs.umn.edu/~karypis/suggest/. It is a C library. > > > Aha. Good for a CGI. > I might try to implement similar code in PHP for a simplier > recommendation engine. That would be great. Eventually I'd imagine there has to be some built-in recommender so it's simple to use, and perhaps also some hooks to go to an external recommender if people build ones that have useful features (e.g., highly scalable, different algorithms). > Best would be to do offline clustering to speed up online queries and > to create buddies (clustered users) automatically. > I think I already have some lisp code to do this :) I agree that the more work you can do offline, the better. One example is the item-item methods that build models. However, the "Suggest" code does no clustering. GroupLens has published research results showing that clustering users is not as effective as finding user-neighborhoods for each user or finding item-neighborhoods for each item. My personal non-GroupLens-approved explanation is that it is fundamentally harder to find a _global_ user cluster that is good to summarize a large group of users than it is to find a _local_ neighborhood that is good for this single given user, or to find a _local_ group of items that goes with this single given item. > >> Thanks for your thoughts. You are already ahead of me. I have not >> even had a chance to fully understand your RateIt patch. > > > I will setup a public test site soon. > > My changes are: > RateIt as button after [BackLinks] > [RateIt] ***** x > Cancel as image button > > If you click at [RateIt] it displays the RateIt plugin for the current > page, which displays the current statistics for this page. > "Number of ratings, Average rating, your rating resp. your > recommendation" > And various links to more advanced queries, like > "top 30 recommended pages for you", "your top 30 rated pages", > "top 30 pages" (rated merged with recommended), > "your buddies with similar taste", ... > All these modes are handled by the RateIt plugin. Wow. You are quick. I'd love to see the site. I will spend more time looking through the patch to understand. > I also write for most plugins a box method which is used to display a > short version in a sidebar box. (RecentChanges, SignIn, WhoIsOnline, > BackLinks, Calendar, FindPage, FullTextSearch, ...) For the future > sidebar based themes. > The RateIt::box() will display the rate buttons and the current > recommendation. So you are not tied to the wikilens theme, which is > currently responsible to display the navbar RateIt buttons and > javascript code. That sounds cool! I don't know about the "box" stuff .. I'll have to learn. > I want to use it for my movie database and better for our free radio > music archive, which I'm currently maintaining. The music archive > creates our nightly playlists automatically from some predefined > parameters and optionally based on our editors ratings, which is > naturally a very problematic issue ("taste"), and each editor only > knows ~20% of our songs. Those sound like great applications. This is exactly what I am hoping will happen: enabling a place for a community to contribute content to a site where they can rate and recommend things to each other, automatically or possibly also manually. > But at first I want to finish my database linking code, which will > create wiki pages on-the-fly from sql queries and a template. > (e.g. 6500 songs, 500 movie reviews, ~237000 imdb movies, 3952 > movielens movies, ...) > This should be dynamic, no static wiki pages. You might need it too to > keep your category entries up-to-date. PhpWiki just as alternative > front-end. > The question is if to allow wiki editing of the various content fields > and to update the external database accordingly. Ah. This issue has come up here as well. I call this the "structured data" issue. Yes, it does seem attractive to have data modeled effectively in SQL, and then use the Wiki as a front end, either just for display, for editing, or for both. However, I would suggest strongly that we want to allow Wiki editing of the content fields. We want the community to be able to contribute new things and correct old ones. Also, we want that editing to be versioned, to protect against thugs. What's more, we'd want the community to be able to edit which fields are in a thing (!). So, for example, perhaps a page has a single type (or maybe a plugin on it that displays the fields from a particular type given the page name). Thus, a page can be of type "movie" or have a plugin that displays the "movie" fields for this page. Then any user coming along can edit the fields in a form-based interface, OR add or change fields. For example, I want every movie to have a link to IMDB, you want them to have a link to RottenTomatoes.com, someone else wants them to have a link to mrcranky.com. Each of these is a field that should be added and editable for every movie, and the community fills in the values as they have time. There are several flavors of this. Some flavors: 1. Plug-in that displays fields from a table. 2. Plug-in that displays and allows editing of fields from a table (not versionable). 3. Plug-in that displays, allows editing, is versionable. I believe this would require special schema, and I have some proposals. 4. Plug-in that displays, allows editing, is versionable, and allows versionable editing of the fields (!). I believe this would require special schema, and I have some proposals. I am a fan of 4, but any of these would be better than none, and 4 is definitely more work. Another choice to make: 1. Generate these pages purely dynamically (if you don't want to create the 10,000 pages by hand) 2. Allow dynamic but editable (in other words the page is generated dynamically if it doesn't exist, but if I edit it, it becomes a real page with a plug-in that shows the values, so I can add comments and so forth) 3. Purely manual but with tools to create the pages from a DB. I head towards 2 or 3, because editing is the Wiki way. I'd like people to be able to add content that I didn't expect as the Wiki maintainer. If the Wiki is simply a display mechanism, why not just create a web app, and have URLs in the Wiki to the web app? > And all this needs paging support (e.g. limit=10,30) in AllPages, > BackLinks, ... I agree! Dan |
From: Reini U. <ru...@x-...> - 2004-03-29 17:56:29
|
I've put that discussion into http://phpwiki.sourceforge.net/phpwiki/SqlWikiDbHookPlugin and cleaned up PhpWiki:DevelopmentBranch a bit. Dan F schrieb: >> But at first I want to finish my database linking code, which will >> create wiki pages on-the-fly from sql queries and a template. >> (e.g. 6500 songs, 500 movie reviews, ~237000 imdb movies, 3952 >> movielens movies, ...) >> This should be dynamic, no static wiki pages. You might need it too to >> keep your category entries up-to-date. PhpWiki just as alternative >> front-end. >> The question is if to allow wiki editing of the various content fields >> and to update the external database accordingly. > > Ah. This issue has come up here as well. I call this the "structured > data" issue. Yes, it does seem attractive to have data modeled > effectively in SQL, and then use the Wiki as a front end, either just > for display, for editing, or for both. However, I would suggest strongly > that we want to allow Wiki editing of the content fields. We want the > community to be able to contribute new things and correct old ones. > Also, we want that editing to be versioned, to protect against thugs. > What's more, we'd want the community to be able to edit which fields are > in a thing (!). > > So, for example, perhaps a page has a single type (or maybe a plugin on > it that displays the fields from a particular type given the page name). > Thus, a page can be of type "movie" or have a plugin that displays the > "movie" fields for this page. Then any user coming along can edit the > fields in a form-based interface, OR add or change fields. For example, > I want every movie to have a link to IMDB, you want them to have a link > to RottenTomatoes.com, someone else wants them to have a link to > mrcranky.com. Each of these is a field that should be added and editable > for every movie, and the community fills in the values as they have time. > > There are several flavors of this. Some flavors: > > 1. Plug-in that displays fields from a table. > 2. Plug-in that displays and allows editing of fields from a table (not > versionable). > 3. Plug-in that displays, allows editing, is versionable. I believe this > would require special schema, and I have some proposals. > 4. Plug-in that displays, allows editing, is versionable, and allows > versionable editing of the fields (!). I believe this would require > special schema, and I have some proposals. > > I am a fan of 4, but any of these would be better than none, and 4 is > definitely more work. > > Another choice to make: > > 1. Generate these pages purely dynamically (if you don't want to create > the 10,000 pages by hand) > 2. Allow dynamic but editable (in other words the page is generated > dynamically if it doesn't exist, but if I edit it, it becomes a real > page with a plug-in that shows the values, so I can add comments and so > forth) > 3. Purely manual but with tools to create the pages from a DB. > > I head towards 2 or 3, because editing is the Wiki way. I'd like people > to be able to add content that I didn't expect as the Wiki maintainer. > If the Wiki is simply a display mechanism, why not just create a web > app, and have URLs in the Wiki to the web app? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2004-03-29 22:45:40
|
Dan F schrieb: >> I will setup a public test site soon. The discussion of this is at http://phpwiki.sourceforge.net/phpwiki/RateItPlugin Code to download linked from there: http://xarch.tu-graz.ac.at/rurban/phpwiki-1.3.8/RateIt.tgz Notes: * this version does not mess up the core. just a new plugin and the new wikilens theme. With the sidebar box methods even this theme is not required anymore. just the RateIt box then. * without the recommendation engine. external CGI version comes soon. * PageList rating column not yet. This must pollute the regular PageList library, because users should be able to define <?plugin AllPages info=rating ?> Problems: What is the default dimension value and what is dimension for? Currently I ignore an empty dimension in the query, i.e. all dimension are used. Dan's version seems to require a dimension value in addRating. Default = 0? At some cases you seem to default to dimension = "rat", but the sql field is only integer(4) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F <dfr...@cs...> - 2004-03-30 17:24:08
|
Reini Urban wrote: > Dan F schrieb: > >>> I will setup a public test site soon. >> > > The discussion of this is at > http://phpwiki.sourceforge.net/phpwiki/RateItPlugin > > Code to download linked from there: > http://xarch.tu-graz.ac.at/rurban/phpwiki-1.3.8/RateIt.tgz > > Notes: > * this version does not mess up the core. just a new plugin and the > new wikilens theme. > With the sidebar box methods even this theme is not required anymore. > just the RateIt box then. > * without the recommendation engine. external CGI version comes soon. > * PageList rating column not yet. > This must pollute the regular PageList library, because users should > be able to define <?plugin AllPages info=rating ?> We did indeed change PageList a bunch, and I started changing clients of PageList, e.g., AllPages, BackLinks plugin, etc. I attach a few patch files (based on 1.3.7) just to show what we did. The prior patch (about storing ratings) I felt pretty good about. On the other hand, these patches are things we are still fundamentally examining and reworking. Moreover, they may refer to files I've not included that are still being worked on. However, perhaps it will be helpful to see the type of stuff we are trying. The "buddy" information is currently being parsed out of the user home page. So for me to declare Reini a buddy, I put "Buddies: ReiniUrban" somewhere on the "DanFr" page and log in as "DanFr." This is one reason we really need 1.3.8, so we can have page security for a user's home page. Also, the buddies stuff in general (and user-group stuff) needs a lot of work, so as I am repeating ad nauseum :-) this is not final by any means. > Problems: > What is the default dimension value and what is dimension for? > > Currently I ignore an empty dimension in the query, i.e. all dimension > are used. Dan's version seems to require a dimension value in > addRating. Default = 0? > At some cases you seem to default to dimension = "rat", but the sql > field is only integer(4) "Dimension" is intended to possibly capture different meanings for ratings people might assign to an item. Examples: 1. An explicit 0-5 rating. You click a ratings widget, and it records that number. This is what we are currently working with, and intend to for weeks, probably months. This is dimension 0. 2. Implicit: how many times do I visit this page? (Could be dimension 1, say.) Then one could recommend by saying, "People who visit these pages also visit these pages." 3. Implicit: Amount of time spent on page. (Maybe dimension 2? Maybe you get to choose the dimension somehow per site?) 4. Implicit: This page links to that page. This one is already available in the DB, so probably we'd just use the existing data instead of encoding it as ratings as well. 5. Two explicit rating widgets scales, one for "quality", another for "novelty". (Dimensions 5 and 10, or whatever?) - etc. At least #2 has been mentioned often enough that I wanted to leave the door open for people to experiment with different apps. As for defaulting dimension to "rat", if true, that is a bug. I can't find it. Where did you see that? The default of "rat" does happen in navbar.tmpl, but it refers to the "imgPrefix", not to dimension. imgPrefix allows us to place the javascript ratings widget for page X both at the top in the navbar, and in the page (with different imgPrefix-es). For example, on the "UserRatings" page (or "AllPages" page, or "BackLinks" page, etc.), which has a ratings widget (of course) at the top of it, and could also be in the list displayed on the page. Also, we have talked about the possibility of having a ratings widget next to each link in a page for certain apps (though it does seem visually noisy). I hope this answers your questions. Thanks for your attention. Dan |
From: Dan F <dfr...@cs...> - 2004-03-30 18:00:32
Attachments:
WikiUser.patch
|
Dan F wrote: > Reini Urban wrote: >> * PageList rating column not yet. >> This must pollute the regular PageList library, because users should >> be able to define <?plugin AllPages info=rating ?> > > > > We did indeed change PageList a bunch, and I started changing clients > of PageList, e.g., AllPages, BackLinks plugin, etc. I attach a few > patch files (based on 1.3.7) just to show what we did. The prior patch > (about storing ratings) I felt pretty good about. On the other hand, > these patches are things we are still fundamentally examining and > reworking. Moreover, they may refer to files I've not included that > are still being worked on. However, perhaps it will be helpful to see > the type of stuff we are trying. > > The "buddy" information is currently being parsed out of the user home > page. So for me to declare Reini a buddy, I put "Buddies: ReiniUrban" > somewhere on the "DanFr" page and log in as "DanFr." This is one > reason we really need 1.3.8, so we can have page security for a user's > home page. Also, the buddies stuff in general (and user-group stuff) > needs a lot of work, so as I am repeating ad nauseum :-) this is not > final by any means. > I realized you'd also need the patch to WikiUser.php to see what's going on. We were thinking about caching user ratings. Moreover, there will probably be intersection and union of ratings, etc. You'll say, "Whoa, don't change core WikiUser, make it a plugin!" Again, I agree and I'm fine with that idea, but this is just the code we have now, and I thought it might be useful for you to see where we are. Dan |
From: Reini U. <ru...@x-...> - 2004-03-30 19:01:33
|
Dan F schrieb: >> We did indeed change PageList a bunch, and I started changing clients >> of PageList, e.g., AllPages, BackLinks plugin, etc. I attach a few >> patch files (based on 1.3.7) just to show what we did. The prior patch >> (about storing ratings) I felt pretty good about. On the other hand, >> these patches are things we are still fundamentally examining and >> reworking. Moreover, they may refer to files I've not included that >> are still being worked on. However, perhaps it will be helpful to see >> the type of stuff we are trying. I think my solution (currently in CVS) is better. :) Just one new PageList method. What about the Cancel as button? A big [X] or a trashcan (as in my version)? Or text as in your version? >> The "buddy" information is currently being parsed out of the user home >> page. So for me to declare Reini a buddy, I put "Buddies: ReiniUrban" >> somewhere on the "DanFr" page and log in as "DanFr." This is one >> reason we really need 1.3.8, so we can have page security for a user's >> home page. Also, the buddies stuff in general (and user-group stuff) >> needs a lot of work, so as I am repeating ad nauseum :-) this is not >> final by any means. Aah, manual buddies! I originally thought of (probably offline) user-clustering (with cluto) which will leed to automatic buddies. Ok, fine. cluto could make at least suggestions for buddies. But they have to be stored somewhere. I thought of storing them as additonal SQL dimension (dimension 1: user -> user relation), which would enable us to run the recommendation engine on buddie relationships. "Show current buddies", (only rated) "Suggest new Top 5 buddies", (only unrated users) "Suggest my Top 5 buddies" (rated merged with suggested TopN) This would be a simple unweighted graph relation, perfect for suggest. But I still don't know how with which engine to handle weighted relations (ratingvalues 0.5-5.0) > I realized you'd also need the patch to WikiUser.php to see what's going > on. We were thinking about caching user ratings. Moreover, there will > probably be intersection and union of ratings, etc. You'll say, "Whoa, > don't change core WikiUser, make it a plugin!" Again, I agree and I'm > fine with that idea, but this is just the code we have now, and I > thought it might be useful for you to see where we are. Hmm. Store plugin-specific extended preferences? This way they are automatically transported in the session and saved in the homepage or pref database. But on RATING_STORAGE==SQL the user-specific ratings can be easily extracted on session initialisation (login) from the rating database instead of the pref db, even from within the plugin. (no core changes needed) Same with RATING_STORAGE==WIKIPAGE, but then its stored in the same place, the users homepage metadata. So I would think they should NOT be stored as prefs, just in the session. => Just another private session variable. And no WikiUser methods. Each plugin can easily detect auth[login]/auth[logout] and init its session variable from its private STORAGE method then. No major hackery needed. The only current problem I see is with the current imgsrc change on click, which doesn't affect the original's page cache, though it should. I might be forced to change this actionImg[imgsrc] scheme to call the plugin directly as with the RateIt button and set the cache validators manually. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F <dfr...@cs...> - 2004-03-30 23:33:23
|
Reini Urban wrote: > Dan F schrieb: > >>> We did indeed change PageList a bunch, and I started changing >>> clients of PageList, e.g., AllPages, BackLinks plugin, etc. I attach >>> a few patch files (based on 1.3.7) just to show what we did. The >>> prior patch (about storing ratings) I felt pretty good about. On the >>> other hand, these patches are things we are still fundamentally >>> examining and reworking. Moreover, they may refer to files I've not >>> included that are still being worked on. However, perhaps it will be >>> helpful to see the type of stuff we are trying. >> > > I think my solution (currently in CVS) is better. :) > Just one new PageList method. No need for a contest. :-) I am happy with your changes in principle. And thanks for your support in putting it in! However, bugs or differences with our PageList that I found in the version checked into the Phpwiki mainline: 1. Biggest thing: your change doesn't allow multiple users' ratings to be displayed. At WikiLens, try putting "Buddies: DanFr, MikeCa" on your user home page, then visit UserRatings. It'll display your ratings, mine, and MikeCa's. This generalizes to many users. This was the comment in PageList.patch about "one of the few possible ways to implement variable numbers of same-type columns without altering the rest of the code". 2. There are at least two types of things one might want on PageList: + rating value (the number, or possibly a non-clickable smiley display. We use a number.) + rating widget (clickable smilies with cancel) You added the widget only. We want the number as well, probably. Thus, we had 'ratingvalue' and 'ratingwidget'. 3. The widget in PageList is not working for me. I changed the AllPages plugin to have info=rating, and it is broken. Not sure why yet. 4. PageList with a 'rating' column is broken if you are signed out. In our case, PageList protects itself, and the 'ratingwidget' column simply is not added unless you are logged in. 5. The nowrap on the widget is gone (see the _format() function), meaning the ratings widget might wrap (which looks bad). This has to be on the table cell, so must be in PageList. 6. I added the possibility to put the pagename anywhere explicitly in the 'info' arg. If the info arg doesn't have pagename, then it is added on the end for backward compatibility. This allows more control over the UI. Other RateIt bugs (not related to PageList): 7. The 'cancel' button didn't work for me. I had to set the dimension=0 by default in RateIt, then it worked. 8a. I do not understand the "RateIt" button. When you click on the ratings it submits, so why have a button? 8b. Actually, when I click the "RateIt" button, it dissappears along with the widget! Now it is gone from all pages. Where did it go? If I sign out and back in, it comes back. > What about the Cancel as button? A big [X] or a trashcan (as in my > version)? Or text as in your version? Eventually I think it should be an icon, like a trashcan or X. However, I couldn't find the right icon. The picture you found doesn't look to me like a trashcan when it's red. (It looks okay in grey.) On the plus side, it has a tooltip (and shows up in browser bar). If I had to choose between this particular trash can and "Cancel", I'd probably choose the word, but I don't have strong feelings. > >>> The "buddy" information is currently being parsed out of the user >>> home page. So for me to declare Reini a buddy, I put "Buddies: >>> ReiniUrban" somewhere on the "DanFr" page and log in as "DanFr." >>> This is one reason we really need 1.3.8, so we can have page >>> security for a user's home page. Also, the buddies stuff in general >>> (and user-group stuff) needs a lot of work, so as I am repeating ad >>> nauseum :-) this is not final by any means. >> > > Aah, manual buddies! I originally thought of (probably offline) > user-clustering (with cluto) which will leed to automatic buddies. Ok, > fine. > cluto could make at least suggestions for buddies. It is important to be able to choose one's buddies. :-) I agree, though, that suggesting buddies is also a fun idea (which we've also had), though not highest on my list. > But they have to be stored somewhere. True. We've just been storing them in the user home page, but storing them as user prefs might be better. Maybe not tho, see below. One nice thing about the user home page is it's possible to have a linkable list of buddies (see DanFr page on WikiLens). Also, we are thinking that defining buddies is very similar to defining groups. Thus, we'd like a "GroupLens" group by putting "Group Participants: User1, User2, ..." on the GroupLens page, then be able to compare ratings or get recs for GroupLens. This should be about the same as putting "Buddies: User1, User2, ..." on the DanFr page and comparing ratings or getting recs for DanFr's buddies (i.e., DanFr's group). This might argue for keeping buddies in the Wiki page as they are now. > I thought of storing them as additonal SQL dimension > (dimension 1: user -> user relation), which would enable us to run > the recommendation engine on buddie relationships. > "Show current buddies", (only rated) > "Suggest new Top 5 buddies", (only unrated users) > "Suggest my Top 5 buddies" (rated merged with suggested TopN) > This would be a simple unweighted graph relation, perfect for suggest. True. Fun, eh? Though that would be recommending buddies based on friends-of-friends, which may not be useful (who knows? dating?). It might be more fun to suggest buddies by interests you share (e.g., ratings). This ("finding neighborhoods") is a different algorithm from getting recs. That's okay, tho. Plenty of fun. > But I still don't know how with which engine to handle weighted > relations (ratingvalues 0.5-5.0) As we discussed, suggest currently has no weighted relations, though I have emailed George to ask if he knows of and/or is willing to release a version that does. Also, there's Cofi and MultiLens. The decision of which rec engine to use is tricky, worthy of discussion. In my view, none of them are perfect, pros and cons to each. One thing: open source is better, then we can improve them. > >> I realized you'd also need the patch to WikiUser.php to see what's >> going on. We were thinking about caching user ratings. Moreover, >> there will probably be intersection and union of ratings, etc. You'll >> say, "Whoa, don't change core WikiUser, make it a plugin!" Again, I >> agree and I'm fine with that idea, but this is just the code we have >> now, and I thought it might be useful for you to see where we are. > > > Hmm. Store plugin-specific extended preferences? This way they are > automatically transported in the session and saved in the homepage or > pref database. > But on RATING_STORAGE==SQL the user-specific ratings can be easily > extracted on session initialisation (login) from the rating database > instead of the pref db, even from within the plugin. (no core changes > needed) Cool. I don't know how to do this, though. Remember, I'm new to Phpwiki! :-) (Also new to PHP actually.) Honestly, I don't understand PHP caching yet. We just thought if rating and recs is truly fundamental, that wherever you had a user you might want their ratings. > Same with RATING_STORAGE==WIKIPAGE, but then its stored in the same > place, the users homepage metadata. > So I would think they should NOT be stored as prefs, just in the session. > => Just another private session variable. And no WikiUser methods. Basically, code that wants any user's ratings has to ask the RateIt plugin? Maybe a little awkward, but I'm fine with it. > > Each plugin can easily detect auth[login]/auth[logout] and init its > session variable from its private STORAGE method then. No major > hackery needed. I don't understand. > The only current problem I see is with the current imgsrc change on > click, which doesn't affect the original's page cache, though it should. > I might be forced to change this actionImg[imgsrc] scheme to call the > plugin directly as with the RateIt button and set the cache validators > manually. I saw the whole 'cache validators' thing, but I just couldn't understand it, so I ended up touch-ing the DB, and setting my cache policy to STRICT. If you can make the cache validators work, that's great. Thanks for your attention. This is fun. Dan |
From: Reini U. <ru...@x-...> - 2004-03-31 02:08:34
|
Dan F schrieb: > Reini Urban wrote: >> Dan F schrieb: >>>> We did indeed change PageList a bunch, and I started changing >>>> clients of PageList, e.g., AllPages, BackLinks plugin, etc. I attach >>>> a few patch files (based on 1.3.7) just to show what we did. The >>>> prior patch (about storing ratings) I felt pretty good about. On the >>>> other hand, these patches are things we are still fundamentally >>>> examining and reworking. Moreover, they may refer to files I've not >>>> included that are still being worked on. However, perhaps it will be >>>> helpful to see the type of stuff we are trying. >>> >>> >> >> I think my solution (currently in CVS) is better. :) >> Just one new PageList method. Okay, yours is better. But I will catch up... But now that I'm sure that no harmful core changes are needed, I will have to wait a bit to fix the remaining showstoppers for 1.3.8. If they will disappear by testing... Sometimes they disappear automagically by doing just nothing. I'm waiting for that :) > No need for a contest. :-) I am happy with your changes in principle. > And thanks for your support in putting it in! > > However, bugs or differences with our PageList that I found in the > version checked into the Phpwiki mainline: > > 1. Biggest thing: your change doesn't allow multiple users' ratings to > be displayed. At WikiLens, try putting "Buddies: DanFr, MikeCa" on your > user home page, then visit UserRatings. It'll display your ratings, > mine, and MikeCa's. This generalizes to many users. This was the comment > in PageList.patch about "one of the few possible ways to implement > variable numbers of same-type columns without altering the rest of the > code". > 2. There are at least two types of things one might want on PageList: > + rating value (the number, or possibly a non-clickable smiley display. > We use a number.) > + rating widget (clickable smilies with cancel) > You added the widget only. We want the number as well, probably. Thus, > we had 'ratingvalue' and 'ratingwidget'. Well, we'll have to think of the user API to that. The only arg I have is the optional "rating", you divided that into "ratingvalue" and "ratingwidget", which I thought was overhead. A value cannot be changed so this is fine for read-only lists: fixed ratings, no recommendations. or other users recommendations which the current users cannot change. The widget can do everything, read-only and read-write. It can seperate between rating and recommendations by using seperate colored smilies or stars (like red and blue stars). > 3. The widget in PageList is not working for me. I changed the AllPages > plugin to have info=rating, and it is broken. Not sure why yet. > 4. PageList with a 'rating' column is broken if you are signed out. In > our case, PageList protects itself, and the 'ratingwidget' column simply > is not added unless you are logged in. > 5. The nowrap on the widget is gone (see the _format() function), > meaning the ratings widget might wrap (which looks bad). This has to be > on the table cell, so must be in PageList. > 6. I added the possibility to put the pagename anywhere explicitly in > the 'info' arg. If the info arg doesn't have pagename, then it is added > on the end for backward compatibility. This allows more control over the > UI. I think we already have this. The others are valid catches, I tried to do keep it very simple for the beginning. > Other RateIt bugs (not related to PageList): > > 7. The 'cancel' button didn't work for me. I had to set the dimension=0 > by default in RateIt, then it worked. > 8a. I do not understand the "RateIt" button. When you click on the > ratings it submits, so why have a button? To display the rating statistics for the current page. And to have short link to that on every page. avg rating, number of users, top N recommendations of various relations, buddies, ... > 8b. Actually, when I click the "RateIt" button, it dissappears along > with the widget! Now it is gone from all pages. Where did it go? If I > sign out and back in, it comes back. Seems to be cache issue. only CACHE=STRICT works ok now. >> What about the Cancel as button? A big [X] or a trashcan (as in my >> version)? Or text as in your version? > > Eventually I think it should be an icon, like a trashcan or X. However, > I couldn't find the right icon. The picture you found doesn't look to me > like a trashcan when it's red. (It looks okay in grey.) On the plus > side, it has a tooltip (and shows up in browser bar). If I had to choose > between this particular trash can and "Cancel", I'd probably choose the > word, but I don't have strong feelings. > One nice thing about the user home page is it's possible to have a linkable list > of buddies (see DanFr page on WikiLens). > Also, we are thinking that defining buddies is very similar to defining > groups. Thus, we'd like a "GroupLens" group by putting "Group > Participants: User1, User2, ..." on the GroupLens page, then be able to > compare ratings or get recs for GroupLens. This should be about the same > as putting "Buddies: User1, User2, ..." on the DanFr page and comparing > ratings or getting recs for DanFr's buddies (i.e., DanFr's group). This > might argue for keeping buddies in the Wiki page as they are now. > >> I thought of storing them as additonal SQL dimension >> (dimension 1: user -> user relation), which would enable us to run >> the recommendation engine on buddie relationships. >> "Show current buddies", (only rated) >> "Suggest new Top 5 buddies", (only unrated users) >> "Suggest my Top 5 buddies" (rated merged with suggested TopN) >> This would be a simple unweighted graph relation, perfect for suggest. > > True. Fun, eh? Though that would be recommending buddies based on > friends-of-friends, which may not be useful (who knows? dating?). It > might be more fun to suggest buddies by interests you share (e.g., > ratings). This ("finding neighborhoods") is a different algorithm from > getting recs. That's okay, tho. Plenty of fun. > >> But I still don't know how with which engine to handle weighted >> relations (ratingvalues 0.5-5.0) > > > > As we discussed, suggest currently has no weighted relations, though I > have emailed George to ask if he knows of and/or is willing to release a > version that does. Also, there's Cofi and MultiLens. The decision of > which rec engine to use is tricky, worthy of discussion. In my view, > none of them are perfect, pros and cons to each. One thing: open source > is better, then we can improve them. > >> >>> I realized you'd also need the patch to WikiUser.php to see what's >>> going on. We were thinking about caching user ratings. Moreover, >>> there will probably be intersection and union of ratings, etc. You'll >>> say, "Whoa, don't change core WikiUser, make it a plugin!" Again, I >>> agree and I'm fine with that idea, but this is just the code we have >>> now, and I thought it might be useful for you to see where we are. Better make it an extra library, but don't touch WikiUser, please. That's currently a very sensible topic. >> Hmm. Store plugin-specific extended preferences? This way they are >> automatically transported in the session and saved in the homepage or >> pref database. >> But on RATING_STORAGE==SQL the user-specific ratings can be easily >> extracted on session initialisation (login) from the rating database >> instead of the pref db, even from within the plugin. (no core changes >> needed) > > Cool. I don't know how to do this, though. Remember, I'm new to Phpwiki! > :-) (Also new to PHP actually.) Very easy language, isn't it? I think I learned it in 4 days. I'll do that later. > Honestly, I don't understand PHP caching yet. We just thought if rating > and recs is truly fundamental, that wherever you had a user you might > want their ratings. That's the most complicated PhpWiki topic, besides the BlockParser. I wonder where jeff got this from. But I think I get it slowly. >> Same with RATING_STORAGE==WIKIPAGE, but then its stored in the same >> place, the users homepage metadata. >> So I would think they should NOT be stored as prefs, just in the session. >> => Just another private session variable. And no WikiUser methods. > > Basically, code that wants any user's ratings has to ask the RateIt > plugin? Maybe a little awkward, but I'm fine with it. Well, we'll see. As long as every page needs to load the plugin, even at <head> time to be able to print the needed javascript, every code section can access the plugin methods easily enough. So we need no changes to other library parts and we need no extra library to maintain. >> Each plugin can easily detect auth[login]/auth[logout] and init its >> session variable from its private STORAGE method then. No major >> hackery needed. > I don't understand. You only have to call the user-specific RateIt userinit code once, when the user signs in. Then it's in a session variable. You have to call getRating() and if empty getRecommendation() per page, because that's page and user specific. But not the buddie list et al. >> The only current problem I see is with the current imgsrc change on >> click, which doesn't affect the original's page cache, though it should. >> I might be forced to change this actionImg[imgsrc] scheme to call the >> plugin directly as with the RateIt button and set the cache validators >> manually. > > I saw the whole 'cache validators' thing, but I just couldn't understand > it, so I ended up touch-ing the DB, and setting my cache policy to > STRICT. If you can make the cache validators work, that's great. Hmm. A $dbi->touch should do the work also. Cache problem explained: /wiki/TestPage select rating 4 => request to /wiki/TestPage, with page internal request (by imgsrc) to /wiki/TestPage?action=RateIt&mode=add&rating=4&+randomstuff (random stuff to fool the client cache, to always update the click) Problem: The client cache to /wiki/TestPage is not notified about the change. The header should create a fresh etag for /wiki/TestPage or a Cache: must-revalidate But we have empty args. The RateIt plugin is called by the theme template, but we have no arg to notify the plugin what happened. So RateIt doesn't know in the parent request, that the parallel imgsrc request updated the page. We could set a cookie or a session variable whenever that happens. Just for this kind of request. But the parent will be too late to pick that up. So we will need some kind of redirect. Bad bad. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2004-03-30 02:59:52
|
Dan F schrieb: >> Dan F schrieb: >>> The "Suggest" code is at the following web page: >>> http://www-users.cs.umn.edu/~karypis/suggest/. It is a C library. >> >> Aha. Good for a CGI. >> I might try to implement similar code in PHP for a simplier >> recommendation engine. >> >> My changes are: >> RateIt as button after [BackLinks] >> [RateIt] ***** x >> Cancel as image button >> >> If you click at [RateIt] it displays the RateIt plugin for the current >> page, which displays the current statistics for this page. >> "Number of ratings, Average rating, your rating resp. your >> recommendation" >> And various links to more advanced queries, like >> "top 30 recommended pages for you", "your top 30 rated pages", >> "top 30 pages" (rated merged with recommended), >> "your buddies with similar taste", ... >> All these modes are handled by the RateIt plugin. > > Wow. You are quick. I'd love to see the site. I will spend more time > looking through the patch to understand. I've committed the plugin and wikilens theme to CVS now. Missing is the finished external suggest.c code and the various output modes based on that. I have a almost finished version at http://xarch.tu-graz.ac.at/rurban/phpwiki-1.3.8/RateIt.tgz But I don't know how to distribute this mysql based suggest.c and the binaries, linked with the library. Together with PhpWiki, together with SUGGEST or completely seperate? Plus my problems with the weighted graph. Wonder if SUGGEST supports float ratings at all. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F <dfr...@cs...> - 2004-03-30 23:41:00
|
Reini Urban wrote: > Dan F schrieb: > >>> Dan F schrieb: >>> >>>> The "Suggest" code is at the following web page: >>>> http://www-users.cs.umn.edu/~karypis/suggest/. It is a C library. >>> >>> >>> Aha. Good for a CGI. >>> I might try to implement similar code in PHP for a simplier >>> recommendation engine. >> > >> > >>> My changes are: >>> RateIt as button after [BackLinks] >>> [RateIt] ***** x >>> Cancel as image button >>> >>> If you click at [RateIt] it displays the RateIt plugin for the >>> current page, which displays the current statistics for this page. >>> "Number of ratings, Average rating, your rating resp. your >>> recommendation" >>> And various links to more advanced queries, like >>> "top 30 recommended pages for you", "your top 30 rated pages", >>> "top 30 pages" (rated merged with recommended), >>> "your buddies with similar taste", ... >>> All these modes are handled by the RateIt plugin. >> >> >> Wow. You are quick. I'd love to see the site. I will spend more time >> looking through the patch to understand. > > > I've committed the plugin and wikilens theme to CVS now. Cool! > Missing is the finished external suggest.c code and the various output > modes based on that. I have a almost finished version at > http://xarch.tu-graz.ac.at/rurban/phpwiki-1.3.8/RateIt.tgz > But I don't know how to distribute this mysql based suggest.c and the > binaries, linked with the library. > > Together with PhpWiki, together with SUGGEST or completely seperate? Good question. Since it is in C, one would really need binaries for different platforms. There is also MultiLens or CoFE, both in Java. As I said before, which recommender to choose merits discussion. > Plus my problems with the weighted graph. Wonder if SUGGEST supports > float ratings at all. As I mentioned previously, currently SUGGEST doesn't have a float rating value, but I asked Prof. Karypis about that. I will pass on anything he says. Dan |