feat: ranking API

[peter-gy]

Description

The full pipeline & API for ranking should be created. It should be handled by a separate library, depending on the draco and draco-web modules.

Requirements

• Create models to represent VIS tasks and their ranking logic depending on a given encoding
• Create default VIS tasks and their ranking logic (at least a stub)
• Expose a single ranking function, accepting the following input:
  • data as any[]
  • encoding preferences of the user (which columns should be included)
  • maximum number of models
  • --> should output an augmented SolutionSet with $n$ costs per recommendation

Additional Context

The VIS tasks and their associated ranking logic must be declarative and easily modifiable. This is absolutely necessary to be able to enhance the tool from a domain POV without making significant changes to the codebase.

Ranking Approach

The proposed ranking algorithm has two main pillars:

• Data-oriented: obtained from draco by reading the cost of a model for an ASP
• Task-oriented: "hard-coded" based on relevant literature, by declaring how useful a given encoding is for a specified task

Non-exhaustive list of used literature:

• Task-Based Effectiveness of Basic Visualizations
• Visual Data Analysis with Task-based Recommendations

The recommendations are generated as vega-lite, hence, the used marks need to be matched using its schema.

Currently, the following marks are specified in the schema:

"Mark": {
  "description": "All types of primitive marks.",
  "enum": [
    "arc",
    "area",
    "bar",
    "image",
    "line",
    "point",
    "rect",
    "rule",
    "text",
    "tick",
    "trail",
    "circle",
    "square",
    "geoshape"
  ],
  "type": "string"
},

In a very high-level overview, the steps to take are:

1. Let draco process the raw data with its wisdom collected as .lp files as a part of Use different levels of constraints uwdata/draco#51 and Hard constraints uwdata/draco#52, and save the SolutionSet output.
2. Iterate through the SolutionSet, and assign a VIS-task-based weight to each solution per VIS task. After this, given that we have $n$ VIS tasks at hand, we can generate $n$ composite costs per recommendation by summing the data-based cost with the VIS-task-based cost.
3. Clients of the library can further process these details and use them for representation