Model 3.0: The Context Central Model

The goals of this newly proposed model is to improve upon Model 1.0: Instance_Dataset_User_Configuration and Model 2.0: Context_Table_Client_Adapter by:

1. Generify the definitions of the data structure
2. Better integrate data from other teams and sources. e.g. The Blue Alliance
3. Hide implementation details from the definition i.e. File structures
4. Define a versatile, decentralized programming interface

Table of Contents

1. Context
2. Table
3. Client
4. Adapter

Context

The Context of a set of data is the scope and state in which the data is relevant for a specific analysis. For example, to find out how some teams are performing at a specific event, the context would be that event, whereas to find out how they performed in the entire season, the context would be the year. Contexts are defined by a set of metrics. For example, they could be analyzing a district, an alliance, a set of scouts, etc. A Context will always have a Data Source, a Version, and a delegated Adapter, which are the key to integrating different sets of data. Given two Contexts, A and B, A is a Supercontext of B if its set of metrics is a strict subset of B's metrics. For example, the Context of a year is always a Supercontext of events in that year. Contrarily, A is a Subcontext of B if B is a Supercontext of A. For a Context, the action of converting itself to a Supercontext and Subcontext is called Upcasting and Downcasting respectively

A Context must:

1. Provide a set of metrics with their contexual values
2. Provide a comparison function with any other Context
3. Provide the set of Tables with their respective metrics managed by this Context
4. lookup an return a Table based on a set of arbitrary metrics
5. Create a Downcast Context based on table metrics
6. Accept an Adapter to upcast from other Contexts
7. Retain and manage a set of Pipelines connected to this Context
8. Provide an interface for Pipelines to cache their data
9. Manage configuations for the Clients of this Context

Context Loader

Loaders determine for the user whether there are some other Contexts available for use upon request. When they do, they are able to return a pipeline and adapter for those Context. For example, loaders can check if there is an USB inserted into the computer that has some data on it. If there is, it checks if there exists an adapter for that context. Finally, it would create the Pipeline to that Context. They could also check for Internet connections, and whether the web site actually has data

A Loader must:

1. Check for available Contexts upon request

Context Pipeline

Context pipelines provide of making data available for use, using means of transferring data. For example, a pipeline for The Blue Alliance is resposible for managing the API key and make requests to the server to fetch the data. Another one might be used to store the current data into an USB key. A pipeline takes as an input of what to send or to fetch and then performs the operation on request based on the interface of the target Context. The result is then cached in the Stash of the Context and available for an Adapter to use

A Pipeline must:

1. TODO

Context Table

Tables are used to represent specific entities of data that are part of a Context. A Table is structured as a 2 dimensional data frame with column headers but no specific row index, where the order of both is irrelevant. A Context contains a set of Tables, each with a distinct row type and set of columns (i.e. data points). For example, in the Context of a specific FRC event, there may be a Table for each match in the event, a Table for each team's stats in the event, a Table for each person who was scouting, and a Table for each entry of data (e.g. team per scout per match)

A Table must:

1. TODO

Context Adapter

Adapters contribute to the actual values of the data using either existing values in the Tables or from another source of input. They can modify the Tables in various ways and is the real "analysis" component of this model. A Context with a data source that does not use Tables always has a delegated adapter to convert the format so that data can be merged together. Data in one Context is invalid in other contexts unless they are converted with an Adapter to fit the other Context

An Adapter must:

1. TODO

Data Client

Clients are the accessors of the computed data that present it to the user in some way. A client component does not modify the underlying data structure but can build on top of it in some way. Clients interact with the user and are allowed to save their viewing configuration

A Client must:

1. Provide its save configuration upon request
2. Accept its save configuration upon start