Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User / item side information #259

Open
rburke2233 opened this issue Jun 27, 2018 · 3 comments
Open

User / item side information #259

rburke2233 opened this issue Jun 27, 2018 · 3 comments

Comments

@rburke2233
Copy link
Contributor

We are working on a number of projects related to fairness-aware recommendation. In our implementations, the system needs to know the status of a user (or an item) -- whether part of a protected group or not. This is a particular case of an algorithm needing side information about users (or items) beyond user ratings: in this case, a "group membership" feature. In general, you would want to have the capability of loading a sparse user-feature (or item-feature) matrix.

I have looked at the Appender classes, but these do not quite meet our needs -- they seem to be intended to store user-user or item-item associations, not user-feature or item-feature associations.

Two questions:

  • Is there work already underway to integrate user-feature and/or item-feature associations into LibRec? The DocumentDataAppender class is suggestive, but there is no associated implementation.
  • If not, would the DataAppender interface be the place to start? Its signature seems somewhat limited. Is there another place in the framework where it would be appropriate to integrate a general capability for loading such features?
@SunYatong
Copy link
Collaborator

You can implement a data appender to read your data refer to the existing ones.

@rburke2233
Copy link
Contributor Author

Do you recommend that we follow the pattern of SocialRecommender and its subclasses? We could create an abstract class titled FairRecommender and then subclasses for the specific implementations. Should we create a subdirectory of recommender called "fair" or would some other structure be preferable?

@SunYatong
Copy link
Collaborator

Yes, that's exactly what I mean and your structure is good to work.

  • For example, you can implement a class called FairDataAppender under librec/data/convertor/appender directory to read and store users' fairness data. Then get these data in FairRecommender's setup function ((FairDataAppender) getDataModel.getDataAppender).getUserFairnessData().

  • And the new appender need to be configured in driver.class.props just like adding new recommenders.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants