Explore segmentation based on Sensemaker outputs

[digitalWestie]

Sensemaker outputs could be used to further segment the data for deeper exploration. For example, we get high, mid, and low level topics. In larger datasets, it may be worth segmenting comments on a particular topic (e.g. topic with most comments), and exploring further to surface sub-themes at a higher resolution.

E.g. select "Accessibility and Infrastructure Challenges" as identified to see what accessibility topics there are:-

{
    "id": "comment_1340",
    "text": "Cycling for getting to work, cuts out traffic and good for distressing on the way home. However it can be scary on the roads.\r\nFor leisure I would like to use the train but they are not frequent enough or on late enough to be useful so I mostly end up cycling.\r\nInter city- bike and train, would like to see better bike parking at central/ queen street.\r\nBike racks on front of busses are a great idea too.",
    "votes": {
      "agreeCount": 1,
      "disagreeCount": 0,
      "passCount": 0
    },
    "topics": "Other:Cycling Benefits and Drawbacks;Other:Public Transport Issues;Other:Accessibility and Infrastructure Challenges"
  }

In this case, we might surface bike storage, safety & perception etc.

[digitalWestie]

At the moment, we have a Conversation abstraction that represents the context + collection of comments we want to use as input.

Conversation takes a target class, and optionally, an ID. From there the logic defines how to build comments.

We could do this by target the job that has the associated output e.g.

target_class: "Sensemaker::Job", target_id: 34 or create a new class to represent the output
target_class: "Sensemaker::AnalysisOutput", target_id: 34

Using target_class and id alone won't provide detail, we'd need to add in an extra param for conversation to then filter comments ... e.g. a filter param?

[digitalWestie]

Query String Filtering

To solve the above issue, we must add a query or filter param. Could take the form of a single string that can be parsed, much like in APIs e.g. GET /items?price[gte]=10&price[lte]=100 .. usually these have operators inside brackets like [lte], [gte], [exists], [regex], [before], [after]..

We could follow that pattern, and therefore we have flexibility to filter by field + operator:

# Filter comments by topic
Sensemaker:::Conversation.new(
  target_class: "Sensemaker::Job",
  target_id: 34,
  query_string: "topics[contains]=Safe and Nurturing Environment"
)

[digitalWestie]

Query String Capabilities

Aside from segmentation by topic, the query_string would also give us the ability to segment in the following ways:

Vote counts

• agrees[gte]=10 - minimum agree votes
• disagrees[gte]=5 - minimum disagree votes
• passes[eq]=0 - exact pass count

Author

• author-id[eq]=20 - specific author
• author-id[in]=1,2,3 - multiple authors

As made available from advanced runner comments-with-scores.json output:

Alignment categories

• isHighAlignment[eq]=true - Common ground comments
• isLowAlignment[eq]=true - Differences of opinion
• isHighUncertainty[eq]=true - Uncertain comments

Alignment scores (numeric)

• highAlignmentScore[gte]=0.8 - High common ground score
• lowAlignmentScore[gte]=0.7 - High disagreement score
• highUncertaintyScore[gte]=0.5 - Uncertainty threshold

Vote rates (percentages 0-1)

• agreeRate[gte]=0.7 - 70%+ agree rate
• disagreeRate[gte]=0.6 - 60%+ disagree rate
• passRate[gte]=0.3 - 30%+ pass rate

Filter status

• isFilteredOut[eq]=false - Only comments with 20+ votes (as per README)

Example Segmentation Use Cases

# High agreement comments on a specific topic
"topics[contains]=Family Support&agreeRate[gte]=0.8"

# Controversial comments (high disagreement)
"disagreeRate[gte]=0.5&total_votes[gte]=20"

# Uncertain comments in a topic"
topics[contains]=Transportation&isHighUncertainty[eq]=true"

# Well-voted comments with mixed opinions
"total_votes[gte]=50&agreeRate[gte]=0.3&disagreeRate[gte]=0.3"

# Common ground comments"
isHighAlignment[eq]=true&highAlignmentScore[gte]=0.9"