**Ontology**
- **Range** — A constraint on the type values of the type may take on. In the current implementation, there are two numeric types:
1. Int
2. Float
- The values are currently limited by `min` and `max` however we have not defined if these form an open, closed, or half-open interval. So a more rigorous mathematical definition needs to occur.
- **Dimensions**
- _Subjective_ — a dimension bounded by a range that contains user input assesments (subjective assessments through the transitive property?)
- _Objective_ — a dimension bounded by a range that contains computed assessments (objective/computed assessments through the transitive property) based off subjective assessments.
- **Assessments** — a value along a bounded dimension that relates to a particular resource created either by a user (subjective/user input assessment) or by a method (objective/computed assessment).
- **Methods** — a way of computing an objective assessment from subjective assessments.
- Currently we only implement sum and mean.
- In the future, methods may form a computation graph across assessments and dimensions. In this case, the ontology will likely change, since the inputs can be objective assessments. It would make more sense to align on the mathmatical terms of domain and range or domain and codomain of a function. Then dimensions will all be the same. Also, for people used to spreadsheets, data science, and big data, it makes more sense to call 'dimensions' 'columns'.
- **Assessment widget tray** — This holds all the assessment widgets in a particular order. The configuration is created for each resource def entry hash.
- **Assessment widget** — This allows:
- creating an assessment for a resource for a particular user along a particular subjective dimension
- *Does it allow a user to changing their assessment for a given resource? E.g., either removing or changing an errant assessment.*
- reflecting the user's most recently created assessment along the assigned subjective dimension for a particular resource back to the user
- displaying the latest computed assessment from an objective/output dimension for a particular resource.
- **Context** — As currently implemented, contexts are limited structures that are limited to one resource def entry hash and allow filtering and ordering resources according to the values of the associated assessments.
- An arbitrary number of GreaterThan, LessThan, or Equal Thresholds can be associated with a Context.
- Ordering can be be Biggest or Smallest
- **Potential Issues**
- The ordering has much to be desired, since it is only numeric (though we only support numeric values ATM)
- While people can create a GreaterThan and an Equal Threshold, people may prefer to have a GreaterThanOrEqual and LessThanOrEqual Threshold.
- In the Distributed Social Sensemaking document, contexts are much more complicated if one proceeds past the cursory definition on page 10. They allow access control by role or other permission structure (credentials & social linking). In this case, they should actually be considered membranes in the Holochain sense. If they are not implemented as membranes, then we have to implement a secure RBAC system to control who has which kind of access to which kind of assessment or resource across the Neighbourhood. We likely need to have this in place already for Sensemaker Zome calls, since currently anyone who has access to the Sensemaker Zome can create Contexts and potentially read all Assessments. So there is much to think about in terms of security.
- In a larger design sense, **it is desirable to set up one Assessment Widget Tray configuration per context.** For example, if I'm setting up a way of flagging content, there will be at least two contexts: a public context and a moderator context.
- The public context will have an assessment widget in the tray that allows creating a 'Red Flag' assessment. The public context will also have a Threshold that only shows posts with less than two 'Red Flag' assessments.
- The moderator context will show posts that have 2 or greater 'Red Flag' assesments. This context will have a separate tray configuration that would allow restoring the post or adding a 'strike mark' assesment to a user that posted the content (this adds another layer of complexity since the user currently can't be assessed against in our code).

**Requirements**

1. CAs will be able to set up dimensions (both subjective and objective) with their own ranges. These dimensions exist through the whole Neighbourhood.
2. CAs will be able to associate methods with a set of input/subjective dimensions and an output/objective dimension. They will also be able to set a boolean which controls if the method is automatically computed. This means we should be able to schedule the method to run on the backend automatically if one of its input dimensions gets new assessments and the method is set to automatically compute.
- 'subjective' dimension is the current terminology, but we can create compute graphs where dimensions would just be considered outputs of methods can which form inputs to methods (this is a simple change).
- We're actually running methods not on all of the subjective assessments, but rather the most recent assessment from each user for the specific resource.
- There may be multiple output dimensions that rely on the same input assessments, which would remain stale if the computation method is tied to the the assessment widget.
3. CAs will be able to associate resource types (resource def entry hashes) with a 'assessment widget tray configuration' containing a specific set of assessment widgets.
- Each resource def entry hash will need a configuration with an ordered list of assessment widget configurations.
- Each assessment widget configuration will need
- the assessment making part
- a subjective dimension used to create an assessment for the given user and resource entry hash
- a widget used to make the assessments and display the user's current assessment
- the assessment viewing part
- an objective dimension used to retrieve the latest objective assessment for the given resource entry hash within the neighbourhood
- a widget used to display the latest computed assessment
- Widgets may be either read only (showing only the most recent computed assessment along the dimension), or write only (allowing a user to assess, but not see the computed value).
4. Each time a resource is shown, given a resource def entry hash and a resource entry hash,
- it is possible to fetch the assessment widget tray configuration for the given resource def entry hash in order to assemble the correct assessment widgets for the assessment control in the correct order
- given the assessment widget tray configuration and the child assessment widget configurations, it is possible to fetch the
- most recent subjective assessment for the current user for the given resource entry hash
- most recent objective/computed assessment for given resource entry hash

Need:
- A standard for defining the range a particular control can be used with. This will be used to allow selecting a widget that works with the given dimension's range.
- This can be a Range object on the interface exposed by the blocks.
- This can be a range object in the applet config.
- This can be a range object in a custom-elements-manifest.
- API for setting and retreiving configuration
- For a given resource def eh, we should have an ordered set of configs for items in the Assessment Widget Tray

      type AssessmentWidgetConfig = {
          dimensionEh: EntryHash,
          widgetEh?: EntryHash // This is specifically for when components are separated out into their own DHT entry (or sequence of DHT entries to allow extra large codebases to be stored).
      } | {
          dimensionEh: EntryHash,
          applicationId?: EntryHash, // This is whatever the id for the application is. I didn't check to see if this is accurate
          componentName?: string // This is the name of the component as exposed by the applet interface
      }
      type AssessmentWidgetBlockConfig = {
          // This is the widget that allows making an assessment and displaying the user's chosen selection if the user can select one of many options
          inputAssessmentWidget: AssessmentWidgetConfig,
          outputAssessmentWidget: {
              dimensionEh: EntryHash,
              widgetEh: EntryHash
              // There is currently no agreement about having multiple components, one for assessment and one for pure output of computed assessments.
              // However, if there were separate components, the config for that component would go here and this would be the same as above
              // There is also a discussion to be had about other modalities of sensemaking like tags and things we haven't considered yet.
          }
      }
      // I'm torn between making this an ordered hash or just an array. I think for simplicity, this will be an array.
      type AssessmentWidgetTrayConfig = AssessmentWidgetBlockConfig[]
      type ResourceDefAssessmentWidgetTrayConfig = {
          [ResourceDefEH]: AssessmentWidgetTrayConfig
      }

- API for easily retreiving the assessment
- API for running methods by assessment dimension
- Design: When we have multiple selection options with different values and the computed value is avg do we want to show the average on the in the assessment widget tray or do we want to the sum of selections other people have made (aka a histogram)?