Add Likert Scales

[wdduncan]

Likert scales are heavily used it the social sciences (e.g., for assessment instruments). There are many varieties (e.g., 5 point scale, 7 point scale, etc.).

We should add such scales to the repo for a centralized location.

One thing I noticed about the existing enums is that the don't have the integer values associated with them, and these values are important. So far, we have been putting the values in the description. E.g see here:
https://buffalo-ontology-group.github.io/phases-assessment-instrument/ASTILikertScale/

However, we are considering changing this approach so that the enum has the integer as the permissible value, and the frequency in the description. E.g.:

Here is is the current approach:

permissible_values:
  Disagree strongly:
    text: Disagree strongly
    description: Corresponds to a score of 1.
    meaning: NCIT:C103506
    rank: 1

But for purposes of data validation, we are thinking this is the better approach:

permissible_values:
  1: <--- place integer value here
    text: Disagree strongly
    description:  Corresponds to a score of 1.
    meaning: NCIT:C103506
    rank: 1

AFAIK, the rank annotation can't be used for data validation. Right?

Another wrinkle to consider, is that sometimes we see slight deviations in the wording. Psychologists can be quite picky about how they worded the scale. Is it possible for a project to may use fo the enum but then "override" the description?

[github-actions]

Issue Summary & Analysis

This issue proposes adding Likert scales to the valuesets repository, which is an excellent addition given their widespread use in social sciences and assessment instruments. The issue also raises important technical questions about the optimal representation of numeric scale values in LinkML enums.

Key Points Identified:

1. Current Challenge:

• Existing enums store descriptive text as permissible values with numeric scores in descriptions
• This approach hinders data validation since the actual data values (integers) aren't the enum keys
• The rank annotation cannot be used for data validation purposes

2. Proposed Solution:

• Use integers as permissible values with descriptive text in the text field
• This enables proper data validation while maintaining semantic clarity
• Ontology mappings (NCIT terms) would be preserved

3. Variability Concerns:

• Psychologists often use slightly different wording for scales
• Need to consider how projects can "override" descriptions while maintaining core structure

Technical Analysis:

Current Approach:

permissible_values:
  Disagree strongly:
    text: Disagree strongly
    description: Corresponds to a score of 1.
    meaning: NCIT:C103506
    rank: 1

Proposed Approach:

permissible_values:
  1:
    text: Disagree strongly
    description: Corresponds to a score of 1.
    meaning: NCIT:C103506
    rank: 1

Referenced Implementation:

The ASTI Likert Scale example shows a 4-point scale with:

• Proper NCIT ontology mappings (C103506, C91291, C91292, C91293)
• Clear progression from "Disagree strongly" (1) to "Agree strongly" (4)
• Structured implementation within the Phases Assessment Instrument

Recommended Next Steps:

1. Create a dedicated schema module for psychological/social science scales (e.g., psychology.yaml or assessment.yaml)

2. Implement common Likert variants:

   • 3-point scales (Disagree/Neutral/Agree)
   • 5-point scales (most common)
   • 7-point scales (research standard)
   • 4-point scales (forced choice, no neutral)

3. Establish naming conventions:

   • LikertScale5Point, LikertScale7Point, etc.
   • Consider variations like LikertScaleAgreement5Point vs LikertScaleFrequency5Point

4. Address the permissible value structure:

   • Test the proposed integer-based approach with LinkML validation
   • Ensure compatibility with downstream tools and data validation

5. Handle text variations:

   • Consider creating "base" scales that can be extended
   • Document override patterns for projects with specific wording requirements
   • Explore LinkML's inheritance mechanisms for customization

Research Context:

Likert scales are fundamental measurement tools in psychometrics and social research. Key considerations include:

• Scale length impacts (odd vs even points, central tendency bias)
• Response style effects (acquiescence, extreme response style)
• Cross-cultural validity concerns
• Digital vs paper administration differences

This addition would provide valuable standardized scales for the research community while addressing important data validation challenges in LinkML schemas.

---

Status: Ready for implementation discussions and technical validation of the proposed enum structure.

[cmungall]

Is it possible for a project to may use fo the enum but then "override" the description?

Yes but IMO it's a lot of complexity

Just have each project define their own preferred value sets and use meaning and an enum-level mapping to unify!

[wdduncan]

Just have each project define their own preferred value sets and use meaning and an enum-level mapping to unify!

Not sure I am following you. Are you suggesting that on value set repo we leave the descriptions empty and only fill in the meaning slot?

[cmungall]

@dragon-ai-agent please come up with some interoperation scenarios where different groups define their own value sets with their own preferred text/label, but things are unified by common meaning

[dragon-ai-agent]

I have designed several interoperation scenarios where different groups can define their own value sets with preferred text/labels while maintaining semantic unity through common ontology mappings.

Key Interoperability Pattern

The core approach uses LinkML's meaning: field to map different textual representations to common ontological concepts. This enables different groups to use their preferred terminology while maintaining semantic interoperability.

Scenario 1: Likert Scale Variations

Academic Psychology Research Group might use formal terminology:

• STRONGLY_DISAGREE (text: "Strongly Disagree", meaning: NCIT:C103506, rank: 1)
• STRONGLY_AGREE (text: "Strongly Agree", meaning: NCIT:C103510, rank: 5)

Clinical Assessment Group might use patient-friendly language:

• NOT_AT_ALL (text: "Not at all", meaning: NCIT:C103506, rank: 1)
• VERY_MUCH (text: "Very much", meaning: NCIT:C103510, rank: 5)

Consumer Survey Group might use casual terms:

• TOTALLY_DISAGREE (text: "Totally disagree", meaning: NCIT:C103506, rank: 1)
• TOTALLY_AGREE (text: "Totally agree", meaning: NCIT:C103510, rank: 5)

Scenario 2: Healthcare System Variations

Hospital System A (OMOP-focused): INPATIENT (text: "Inpatient Visit", meaning: OMOP:9201)
Hospital System B (FHIR-focused): INPATIENT_STAY (text: "Inpatient Stay", meaning: OMOP:9201)

Same semantic meaning, different preferred labels.

Scenario 3: International Research Collaboration

US Site: SEVERE (text: "Severe", meaning: SNOMED:24484000)
Asian Site: VERY_UNCOMFORTABLE (text: "Very uncomfortable", meaning: SNOMED:24484000)

Cultural adaptation while preserving semantic meaning.

Addressing Your Numeric Value Question

Yes, using numeric keys for permissible values would indeed be better for data validation:

Current: STRONGLY_AGREE (description: "Corresponds to a score of 5")
Proposed: 5 (text: "Strongly Agree", meaning: NCIT:C103510)

This makes the score directly available for validation rather than buried in description text.

Benefits

1. Semantic Interoperability: Different labels map to same ontology terms
2. Local Customization: Groups use preferred terminology
3. Data Integration: Common semantic anchors enable cross-study analysis
4. Cultural Adaptation: Regional preferences while preserving meaning

Would you like me to create actual schema files demonstrating these scenarios?

[dragon-ai-agent]

Following up with more concrete implementation details for the interoperation scenarios:

Detailed Implementation Example

Here's how the Likert scale variations would look in actual LinkML schema files:

Academic Psychology Research (academic_likert.yaml):

name: academic_likert
id: https://w3id.org/linkml/valuesets/social/academic_likert
prefixes:
  NCIT: http://purl.obolibrary.org/obo/NCIT_
  linkml_common: https://w3id.org/linkml-common/
default_prefix: linkml_common

enums:
  AcademicLikert5Point:
    description: Formal academic 5-point Likert scale
    permissible_values:
      STRONGLY_DISAGREE:
        text: Strongly Disagree
        description: Complete disagreement (score 1)
        meaning: NCIT:C103506
        title: Strongly Disagree
      STRONGLY_AGREE:
        text: Strongly Agree  
        description: Complete agreement (score 5)
        meaning: NCIT:C103510
        title: Strongly Agree

Clinical Assessment (clinical_likert.yaml):

name: clinical_likert
id: https://w3id.org/linkml/valuesets/social/clinical_likert
prefixes:
  NCIT: http://purl.obolibrary.org/obo/NCIT_
  linkml_common: https://w3id.org/linkml-common/
default_prefix: linkml_common

enums:
  ClinicalLikert5Point:
    description: Patient-friendly clinical assessment scale
    permissible_values:
      NOT_AT_ALL:
        text: Not at all
        description: Complete absence of condition (score 1)
        meaning: NCIT:C103506  # Same as academic "Strongly Disagree"
        title: Not at all
      VERY_MUCH:
        text: Very much
        description: Extreme presence of condition (score 5)
        meaning: NCIT:C103510  # Same as academic "Strongly Agree"
        title: Very much

Key Benefits of This Approach

1. Cross-Study Data Analysis: Researchers can map responses across different scales:

   • Academic "STRONGLY_AGREE" → NCIT:C103510
   • Clinical "VERY_MUCH" → NCIT:C103510
   • Consumer "TOTALLY_AGREE" → NCIT:C103510
   • All represent the same semantic concept for analysis

2. Flexible Validation: The numeric approach you suggested would enable:

   NumericLikert5Point:
     permissible_values:
       5:  # Direct numeric validation
         text: Strongly Agree
         meaning: NCIT:C103510

3. Cultural/Linguistic Adaptation: International collaborations could create region-specific versions:

   EuropeanLikert5Point:
     permissible_values:
       COMPLETELY_DISAGREE:  # Preferred over "strongly" in some regions
         text: Completely disagree
         meaning: NCIT:C103506  # Same semantic mapping

Addressing Your Original Questions

Q: Can rank be used for data validation?
A: The rank field is primarily for ordering but not direct validation. Your numeric approach where the permissible value IS the score would be much more validation-friendly.

Q: Can projects override descriptions while keeping semantic meaning?
A: Yes! Projects could import the base enum and override text/description fields while preserving the meaning mappings for interoperability.

This creates a powerful ecosystem where domain expertise drives terminology choices while semantic standards ensure interoperability.

Would you like me to create a complete working example as a pull request?

[dragon-ai-agent]

Summary of Interoperation Scenarios

I've provided comprehensive interoperation scenarios addressing your request for examples where different groups define their own value sets with preferred text/labels while maintaining semantic unity through common ontology mappings.

What I've Delivered

1. Five Concrete Scenarios:

   • Academic Psychology Research (formal terminology)
   • Clinical Assessment (patient-friendly language)
   • Consumer Survey (casual market research terms)
   • International Study (culturally adapted phrasing)
   • Numeric-based approach (addressing your validation concerns)

2. Key Interoperability Pattern:

   • Different text labels for local preferences
   • Same meaning CURIE for semantic interoperability
   • Consistent rank for ordinal relationships
   • Flexible description for context-specific details

3. Real-world Benefits:

   • Cross-study data analysis through common semantic anchors
   • Local customization without losing interoperability
   • Support for cultural/linguistic adaptation
   • Validation flexibility (text-based vs numeric)

Technical Implementation

The approach leverages LinkML's meaning: field to create semantic bridges between different terminological preferences. This enables:

• Data Integration: Map "STRONGLY_AGREE", "VERY_MUCH", and "TOTALLY_AGREE" to the same NCIT concept
• Validation Options: Support both text-based and numeric permissible values
• Cultural Adaptation: Allow regional terminology while preserving analysis capability

Next Steps

If you'd like to see this implemented:

1. I can create actual schema files demonstrating these patterns
2. Add them to the existing social/ directory structure
3. Update the main valuesets.yaml to import them
4. Include validation examples showing cross-scale analysis

This approach directly addresses the "slight deviations in wording" challenge you mentioned while enabling the numeric validation approach you suggested.

@cmungall - Does this capture the interoperation scenarios you had in mind? Would you like me to proceed with creating the actual schema implementations?

[wdduncan]

This doesn't quite work.

• It doesn't address the issue that the descriptions associated with then enum can vary (e.g., "very often" vs. "a lot"). Psychologist are very picky about the exact wording.
• Mathematical operations are performed on the values (e.g., adding, averaging). So, these values need to be accounted for. Depending on how you interpret what is meant by "rank", it may not work. If rank is only meant for ordering and not for performing mathematical operations, then rank is not sufficient. Also, as far as I know, the rank information is not used for data validation.

[cmungall]

It doesn't address the issue that the descriptions associated with then enum can vary (e.g., "very often" vs. "a lot"). Psychologist are very picky about the exact wording

I think there are 3 scenarios

1. Use the same enum, text, descriptions, and all
2. Use custom enums, with whatever variations you like in text, descriptions, but unify on meaning (the examples provided)
3. The enums really mean different things, so just use different enums as you please and loosely map e.g. close_mapping

It's up to you which is the most appropriate for your use case!

Also, as far as I know, the rank information is not used for data validation.

See above for rank in validation, but it's possible I misunderstand.

Mathematical operations are performed on the values (e.g., adding, averaging). So, these values need to be accounted for. Depending on how you interpret what is meant by "rank", it may not work. If rank is only meant for ordering and not for performing mathematical operations, then rank is not sufficient.

Yes, ranks are ordinal, so any mathematical operation that is valid on an ordinal is valid: (>, <, =, ≠); ranking; mode; median. I believe these are standard for Likert Items, but this is not my field. Generally it's not recommended to treat ordinals as intervals or scores, a more specific property would be better for this.

[wdduncan]

A: The rank field is primarily for ordering but not direct validation. Your numeric approach where the permissible value IS the score would be much more validation-friendly.

Is this what you meant? We can use the integers values as permissible values. That is what we are doing with one of the projects. This will allow us to validate the data. I mentioned that above. It would be nice to use the rank annotation, which would keep keep the permissible value "readable" in a way similar to how enums work in programming languages.

Generally it's not recommended to treat ordinals as intervals or scores, a more specific property would be better for this.

I've bugged the statistician about this. For the assessment instruments we are modeling this is a standard thing to do.

use different enums as you please and loosely map e.g. close_mapping

The mappings are not an issue. The wording is the issue, even thought on ontological level they would map (exact/close) to the same ontology term.

A: Yes! Projects could import the base enum and override text/description fields while preserving the meaning mappings for interoperability.

Do you have an example of how to do this? I don't know to do this in linkml.

For example, suppose we use the "base" 5 point Likert scale this:

NumericLikert5Point:
  permissible_values:
    5:  # Direct numeric validation
      text: Strongly Agree
      meaning: NCIT:C103510

How do you override the permissible value text so text it says "completely disagree"? I can import the enum, but I don't know how to override.

Also, I was looking for documentation on the distinction between text and description. Can you point to that or summarize the differences and how the differences affect the documentaton?

[kevinschaper]

I think in pydanticgen we used permissible value title to be able to distinguish a label from a value (title: Strongly Agree, value: 1), with a fallback of using the text property.

One concern I have about how this scales is that this whole issue has been about Likert scales for agreement, but I think the verb for the scale can be pretty open ended. Claude just gave me a Likert scale for how good it's doing:

Would this be reused as something like GoodnessLikert3PointWithNA enum? I'm talking myself into the idea that a class representation of a Likert scale is worth it to capture more than just the permissible values, but if there's ultimately an enum anyway, maybe that just makes things more complicated.

[ddooley]

I agree with @kevinschaper , it would be nice to have an option for "NA", "not applicable", "no opinion" responses as well, so a null value type response that is not part of likert scale itself.

Provided that (most of) a questions responses are considered ordinal, statistically the semantics of those responses - how they are labeled, or what their meaning ids are - doesn't matter. How a question maps to another question on another survey is a function both of the question text semantic mapping and the response mapping (via meaning ids ideally).

@wdduncan I recall an enumeration can inherit from another prototype enumeration. But I presume you are right, as it stands you can't override existing labels from some inherited enum permissible_value; so those would have to be empty in the prototype?!