0

SKOS has the notion of concept and concept schemes, which can be roughly used to model enums known from standard programming languages. Concepts can also be defined to be wider or narrower than each other, roughly equivalent to bit flags enums.

Assuming one would like to describe something like cardinal directions, the following is possible:

<CardinalDirections> a skos:ConceptScheme .

<north> skos:inScheme <CardinalDirections> .
<east> skos:inScheme <CardinalDirections> .
<south> skos:inScheme <CardinalDirections> .
<west> skos:inScheme <CardinalDirections> .

Yet enums are usually also part of the type system in various languages, so I could also choose this interpretation:

<CardinalDirection> a rdfs:Class .

<north> a <CardinalDirection> .
<east> a <CardinalDirection> .
<south> a <CardinalDirection> .
<west> a <CardinalDirection> .

So, a) is there any benefit of using one model instead of the other? And b) does it make sense to combine them?

<CardinalDirection> a rdfs:Class , skos:ConceptScheme .

<north> a <CardinalDirection> ; skos:inScheme <CardinalDirection> .
<east> a <CardinalDirection> ; skos:inScheme <CardinalDirection> .
<south> a <CardinalDirection> ; skos:inScheme <CardinalDirection> .
<west> a <CardinalDirection> ; skos:inScheme <CardinalDirection> .
IS4
  • 11,945
  • 2
  • 47
  • 86

1 Answers1

0

In programming an enum is a unique type of class where the instances of the class is predefined and final. That is, new instances cannot be added to an enum.

Strictly speaking I do not think that what you refer to as representing an enum in RDF is in fact an enum. Rather, it is a number of instances of the same class. In particular, there is nothing that prohibits making the following statement:

<apple> a <CardinalDirection> .

To see this more clearly, consider the following example:

<Person> a rdfs:Class .

<peter> a <Person> .
<susan> a <Person> .
<kyle> a <Person> .

Clearly the Person class is not an enum.

In RDF there is no way to prohibit adding additional instances to a class as is needed for defining an enum.

If you want to define an enum, you will need to use OWL. Then you could define an enum in the following way:

:CardinalDirection rdf:type owl:Class ;
               owl:equivalentClass [ rdf:type owl:Class ;
                                     owl:oneOf ( :East
                                                 :North
                                                 :South
                                                 :West
                                               )

where you define, for example :East, as follows:

:East rdf:type owl:NamedIndividual ,
           :CardinalDirection .

When will you define an enum in this way? When you plan to run an OWL reasoner over your schema or data. In that case adding :apple a :CardinalDirection . will result in an inconsistency.

If you do not require running a reasoner, there is no reason to consider using enums.

Henriette Harmse
  • 4,167
  • 1
  • 13
  • 22
  • Perhaps I have oversimplified the problem a bit. If I intended to run a reasoner and required to have the enum fixed, this could be a good constraint (although it might also be specified that all 4 directions are different from each other). I am more focused on getting the "informative" aspects of enums right, since with just using `owl:oneOf`, it could also describe the current state of things for any class. If there are specific items in a folder, you can define the class this way as well, but it's still not an enum. – IS4 Dec 18 '20 at 12:02
  • Let's say I don't have the actual members at hand when defining it, and I would still want to have some freedom so that new members can be freely added (so instead of cardinal directions, it could be just directions or colors in the vernacular sense, languages or other modes supported by some applications etc.) – IS4 Dec 18 '20 at 12:08
  • "... with just using `owl:oneOf`, it could also describe the current state of things for any class...". That is not true due to the equivalence used along with `owl:oneOf`. Adding `:apple a :CardinalDirection .` will in this case cause an inconsistency, but it will not cause an inconsistency when defined in the way you defined `:CardinalDirection`. – Henriette Harmse Dec 18 '20 at 13:10
  • If you want to change the elements of the enum, you will need to redefine the `:CardinalDirection` in the way I have defined it every time there is a change in the elements and re-run the reasoner. – Henriette Harmse Dec 18 '20 at 13:13
  • I meant that if you know there are only 5 elements in a particular class at the moment (and you want to have control over them), you can use `owl:oneOf` without meaning it to be an enum. And, to argue semantics, adding `:apple a :CardinalDirection` doesn't actually cause an inconsistency, it will simply mean the resource must be the same as one of the previously defined cardinal directions. – IS4 Dec 18 '20 at 13:27
  • Yes, `:apple a :CardinalDirection` will cause an inconsistency assuming you stated it is different from other individuals, which seemed to be what you implied by your example. I.e., you unlikely want east and west (or green and red) to be inferred to be the same thing. – Henriette Harmse Dec 18 '20 at 13:42