Add ordinal support for enums #2608

wdduncan · 2025-04-09T20:48:30Z

wdduncan
Apr 9, 2025
Collaborator

I am working on a project that has data based on survey question. The answers to these questions modeled as Likert scales; e.g., "strongly disagree", "disagree", "neither disagree or agree", "agree", "strongly agree". Likert scales (and similar scales) are categorical ordinal variables. This allows for numerical comparisons; e.g., find all answers > "neither disagree or agree".

So, what would be the best way to represent this in linkml? You cannot use the rank slot enum permissible values. One thought is to use classes. E.g.:

classes:
  Ordinal:

  One:
    is_a: Ordinal
    rank: 1
  
  Two:
    is_a: Ordinal
    rank: 2

  Three:
    is_a: Ordinal
    rank: 3

  Missing:
    is_a: Ordinal
   rank: -999 # this how missing data is handled in the study data

I suppose this is okay, although is doesn't feel "natural". When I translate a schema like this into OWL, it adds an sh:order annotation property to each class. E.g.:

@prefix : <http://example.com/data/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

:Ordinal a owl:Class ;
    rdfs:label "Ordinal" .

:One a owl:Class ;
    rdfs:label "One" ;
    rdfs:subClassOf :Ordinal ;
    sh:order 1 .

Unfortunately, reasoners like hermit don't use annotation properties (e.g., sh:order). It may be better to make use owl:hasValue for the ordinal value. Something like:

:One a [a owl:Restriction; 
              owl:onProperty :ordinal_value;
              owl:hasValue 1] .

I don't know to model something like this in a linkml schema.

Another approach would be to model the enums as individuals and use a data property to handle the ordinal value. E.g.:

:one a :Ordinal .
:one :ordinal_value 1 .

Using individuals has the advantage of not having to create a new instance of an ordinal each time the enum is used.

However, I do not know how such individuals would be included in a linkml schema.

Any thoughts on this?

cmungall · 2025-04-28T22:59:37Z

cmungall
Apr 28, 2025
Maintainer

Hi @wdduncan. In fact, rank can be used in linkml:PermissibleValue

However, it should be noted that this does not have a translation to OWL. I think this is perhaps what you meant?

There are two good reasons why a PV rank is not translated to OWL

the PV may be a literal, and RDF/OWL disallows annotation of literals
the rank might be context dependent. E.g. in Enum1, you may have Yes=1, No=2, and in Enum2 No=1, Yes=2 (where both Yes and No are represented as some kind of OWL element)

The way around both of these is to treat most PV annotations as reifications. This introduces a certain amount of complexity and bloat; it could be made optional, but that itself is introducing complexity. However, I think it's still a good proposal.

Before advancing this further, would this address your need?

1 reply

wdduncan Apr 28, 2025
Collaborator Author

the PV may be a literal, and RDF/OWL disallows annotation of literals

I was not aware the PVs could be translated as literals. In my experiments, the enums have been translated into classes or individuals. But, I easily may not have translated a schema of the sort that would generate literals.

the rank might be context dependent. E.g. in Enum1, you may have Yes=1, No=2, and in Enum2 No=1, Yes=2 (where both Yes and No are represented as some kind of OWL element)

Definitely!

The way around both of these is to treat most PV annotations as reifications.

If PVs might be literals, then I don't think there a better general solution. For cases cases when the enum PV is translated into a class or individual perhaps one of my proposals could work? But, I think that would really complicate things ...

wdduncan · 2025-04-29T16:05:27Z

wdduncan
Apr 29, 2025
Collaborator Author

the PV may be a literal, and RDF/OWL disallows annotation of literals

@cmungall I think I found the source of my confusion. When I was experimenting with enums, I was only only looking at the OWL generated for the schema.
When I convert (i.e., gen-owl) enum-as-class.yaml (attached), the enums get converted to OWL classes. E.g.,

enums:
  EthnicityType:
    permissible_values:
      1:
      2:
      3:

is converted to:

<https://example.com/enum_schema/:EthnicityType#1> a owl:Class ;
    rdfs:label "1" ;
    rdfs:subClassOf <https://example.com/enum_schema/:EthnicityType> .

<https://example.com/enum_schema/:EthnicityType#2> a owl:Class ;
    rdfs:label "2" ;
    rdfs:subClassOf <https://example.com/enum_schema/:EthnicityType> .

<https://example.com/enum_schema/:EthnicityType#3> a owl:Class ;
    rdfs:label "3" ;
    rdfs:subClassOf <https://example.com/enum_schema/:EthnicityType> .

<https://example.com/enum_schema/:EthnicityType> a owl:Class ;
    owl:unionOf ( <https://example.com/enum_schema/:EthnicityType#1> <https://example.com/enum_schema/:EthnicityType#2> <https://example.com/enum_schema/:EthnicityType#3> ) ;
    linkml:permissible_values <https://example.com/enum_schema/:EthnicityType#1>,
        <https://example.com/enum_schema/:EthnicityType#2>,
        <https://example.com/enum_schema/:EthnicityType#3> .

(Side note: Is there supposed a : before EthnicityType in <https://example.com/enum_schema/:EthnicityType#1? I also thought a CURIE was supposed be generated for <https://example.com/enum_schema/>.)

However, when I convert (i.e., linkml-convert) the instance-level file enum-test-data.yaml (attached) the permissible values are translated as literals. E.g.,

records:
  - id: 1
    gender: M
    ethnicity: "1"

is converted to:

[] a ns1:Dataset ;
    ns1:records [ a ns1:Record ;
            ns1:ethnicity "1" ;
            ns1:gender "M" ;
            ns1:id 1 ] .

This was not what I expected. Since the permissible values are classes in the OWL translation of the schema, I expected something like this for the instance-level data:

[] a ns1:Dataset ;
    ns1:records [ a ns1:Record ;
            ns1:ethnicity [a :EthnicityType#1] ;
            ns1:gender [a :GenderType#M] ;
            ns1:id 1 ] .

enum-as-class.yaml.txt
enum-test-data.yaml.txt

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Linked data Modeling Language

Add ordinal support for enums #2608

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Linked data Modeling Language

Add ordinal support for enums #2608

Uh oh!

wdduncan Apr 9, 2025 Collaborator

Replies: 2 comments · 1 reply

Uh oh!

cmungall Apr 28, 2025 Maintainer

Uh oh!

wdduncan Apr 28, 2025 Collaborator Author

Uh oh!

wdduncan Apr 29, 2025 Collaborator Author

wdduncan
Apr 9, 2025
Collaborator

Replies: 2 comments 1 reply

cmungall
Apr 28, 2025
Maintainer

wdduncan Apr 28, 2025
Collaborator Author

wdduncan
Apr 29, 2025
Collaborator Author