ucoProject/UCO

Add ReactionsListFacet

cyberinvestigationexpress opened this issue · 3 comments

cyberinvestigationexpress commented

Background

Many applications provide the user with reaction options such as like and share. There is a need to represent the reactions to a given observable object. The substance of a reaction could be represented using the existing MessageFacet related to the original observable object.

Requirements

Requirement 1

Represent the number of each type of reaction.

Requirement 2

Link to the details of each reaction (e.g., who reacted and what their reaction was).
Note: the substance of a reaction could be treated as a reply message and, therefore, be represented using the existing MessageFacet.

Risk / Benefit analysis

Benefits

Representation of reaction details surrounding an observable object, which is a pervasive type of information in digital communication and social networking.

Risks

Different types of reaction types could make it difficult to represent the total number of each reaction type.

Competencies demonstrated

Competency 1

In a given application, which message received an "Angry" reaction?

Competency Question 1.1

Who sent the Angry reaction?

Result 1.1

A list of messages that received an Angry reaction

Competency 1

In a given application, which observable objects received an "Angry" reaction?

Competency Question 1.1

How many Angry reactions did the message receive?

Result 1.1

A list of observable objects that received an Angry reaction, and the number of Angry reactions for each observable object.

Competency 2

For a given observable object, who sent an Angry reaction?

Result 2.1

A list of Accounts that sent an Angry reaction to a given observable object

Solution suggestion

  • Define new ReactionListFacet that contains a list of references to Message observable objects
  • Do not explicitly represent the total number of each reaction type, this calculation can be part of the query
  • Represent the details of each reaction in a Message object, including the time, sender, and reaction (Like, Angry, Haha, Heart, Comment, etc.)
  • Add unit test showing potential errors in property usage and how to avoid them

Coordination

  • Tracking in Jira ticket OC-236
  • Administrative review to be completed
  • Requirements to be discussed in Ontology Committee (OC) meeting, 2022-05-05
  • Requirements to be discussed again in Ontology Committee (OC) meeting, date TBD
  • Requirements Review vote has not passed
  • Requirements development phase completed.
  • Solutions Approval to be discussed in OC meeting, date TBD
  • Solutions Approval vote has not occurred
  • Solutions development phase completed.
  • Implementation has not been merged into develop
  • Milestone linked
  • Documentation logged in pending release page
ajnelson-nist commented

I have a few bits of feedback, reflexively:

  • In addition to defining a ReactionsListFacet, we should make clear whether we intend to also include a ReactionsList object.
  • Requirement 2's extra note makes it seem like the proposed model is to have a :Reaction object be a subclass of a observable:Message object.
  • Re: "Do not explicitly represent the total number of each reaction type" - I suggest this model might seem like it falls short if one can represent that these 5 people angry-reacted, but not say that 9,000 people reacted in another manner. The scale of how many reactions occurred tells a significant story - 1 reaction out of 9,000 is much different from one reaction out of 2. Two ontologies' adoptions under proposal-draft have ways to handle this:
    • The Collections Ontology would represent the reactions list object as a bag, and has an attribute on the bag-object that records the size.
    • SOSA/SSN/QUDT would treat the reaction tally as a measurable property.
    • If reaction tally does become part of this proposal, the time of the count will matter.
  • There is at least one more risk in complexity - depending on the application, reactions have different degrees of extensibility. Some social media applications allow arbitrary single unicode characters as reactions, and these display according to operating system rendering (i.e. might display differently on a Mac vs. an Android phone vs. a Windows system). Others allow arbitrary small graphics to be used as reactions. The graphic of reactions can be relevant to certain types of investigations. All that said, we will need to scope what the reaction encoded data is, and also what display heuristic is expected (e.g. emoji display vs. avatar display).
dannyr101 commented

I have a few comments:

  1. We (Cellebrite) do not consider sharing somebody's post as a reaction, reactions are typically meant to express how you feel about something that you see/read. We consider a "Share" activity to be a type of Post in and of itself where the original content was created by someone else.
  2. We need to see how we model Messages like Text (SMS/MMS) or Instant Messages vs. Social Media Activities like Posts, Comments Stories etc. We do not consider these to be the same, while reactions can be related to both, we need to ensure we have separate representations, or a representation that covers the vast scope of their unification.
  3. In many use cases, we do not have, nor do we want to record the individual details of every single reaction, for example when a famous/well known person makes and inflammatory, or popular statement, it often receives millions of reactions. Providing the date/time, and user details for such numbers is not only meaningless, it is wasteful. In such cases we only record the number of each reaction count (see Alex's previous comment).
ajnelson-nist commented

This proposal's initial vote closed as unsuccessful on May 17, but may have been opened in administrative error. A significant revision to the structure of the proposal is pending, to include usage of the SOSA ontology.