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 |