Bilumi Data Model Diagrams

Examples

Direct Ratings, User Portfolio

Products have reviews separated by interests; eg, human rights, carbon footprint, etc. Users rate reviews, which gives each review an average rating.[*] The product's rating in a particular interest is the average of all reviews with that interest. The product's score is obtained by applying a portfolio to the entity's per interest ratings. A portfolio, in our implementation, is a weighting on interests, and thus the overall product score is simply a weighted average of what the portfolio's creator cares about.

A rating is always within a particular interest. An entity's score is a single, overall calculation that results from applying a portfolio to the entity's aggregated ratings.

* The weight of each user's rating is weighted by the user's status. Thus, a review's average rating is a weighted average. The average rating across all reviews in a particular interest is not weighted.

Aggregated Ratings, User Portfolio

Entities have direct ratings as described above, as well as aggregated ratings that take into account entity hierarchy. An entity's aggregated ratings are a weighted average of its own direct rating and the aggregated ratings of its parents. The weighting results from edge weightings between entities. An entity's score is on the aggregated rating rather than direct rating by default, but eventually that may become a user or portfolio preference.

Cross Sectioning Reviews for Further User Customization

Finally, we may want more refined per interest ratings for an entity based on a review's source or contributors.

Models

Full Strawman part 1 (core relations)

There is a large cross-product of potential ratings and rankings

Full Strawman part 2 (generic relations)

The above diagram seeks to support as much model flexibility as our biased imaginations permit. Our goal is to incorporate all perspectives without limiting readability.

Diagram Limitations

Flexibility, Complexity and Diminished Returns

In the above models, tags are properties of discussions and entities. Technically, a relationship is just as easily generic for two items as for ten: the database doesn't care, and the internal API can mix in properties via a loop on say TAGGABLE models. In fact, since this is exactly what we do in Bilumi's backend, I initially put tags as a property of ANY ITEM. I think that detracted from the overall readability of the diagram, though.

A similar argument could be put forth for ratings and evaluations. There's no need for these relationships to be limited to entities or reviews. However, that's where they make the most sense and are the most likely. If there is lots of variety in what is getting rated and evaluated, then those relationships should be moved to Strawman Diagram part 2, which presents more generic relationships.

Abstraction

Strawman Diagram part 2 uses ANY ITEM to refer to some subset of item types. This single ANY ITEM box could be duplicated for each of TAGGABLE_ITEMS, STATEFUL_ITEMS and ACTIONABLE_ITEMS, since these item sets might not exactly overlap. Nonetheless, a fuzzy ANY ITEM concept gets a simple, readable point across, which can be annotated later if need be with item set specifics.

Another abstraction is the use of portfolio to mean some kind of customized filtering and computation. A portfolio may take into account category weights, review sources, trust networks, etc. As our understanding of one anothers's models grows we may flesh out portfolio-dependent models, but for now it seems ok to maintain abstraction.

Non-Incorporation

Both the "Abstraction" example and the "Flexibility, Complexity and Diminished Returns" example above demonstrate cases where individual models are not fully incorporated by the full model to maintain readability. The extra capabilities are either not salient or permit implementation flexibility.

Our goals are still to incorporate as much as possible, be inclusive and learn from everyone's designs.