Abstract classes and slots#
A model class (or slot) may be tagged with its abstract slot set to the boolean value
true, to define whether it is abstract. This has comparable meaning to that in the computing science Object Oriented Paradigm: another class (or slot) can use the abstract class (or slot) as part of its inheritance hierarchy, but the abstract class itself cannot be directly instantiated.
This forces data providers to always provide a more specific class than the generic “
This also provides a very useful piece of metadata that can be used by tools that present schemas to domain scientists and subject matter experts. Abstract classes can be filtered from displays, with their properties “rolled down”.
Some generators may choose to utilize abstract tags, e.g to mask generation of abstract classes.
Note: Slots can also be declared abstract.
Mixin classes and slots#
The mixin boolean slot to declare a class as a mixin
The mixins multivalued slot which specifies a range of mixin parents.
Mixin parents operate similarly to
is_a parents, but they do not have the constraint of forming a tree.
Mixins can be extremely helpful in a number of ways: 1) to generalize a set of attributes that can apply to classes in different parts of the class hierarchy, 2) reduce duplication of shared attributes between classes that do not inherit from one another and 3) to prevent the sometimes confusing nature of multiple inheritance noted in the diamond problem.
is_a has the characteristics of homeomorphicity:
is_a SHOULD only connect either (1) two mixins (2) two non-mixin elements
See also the Wikipedia page on mixins
Materializing inherited slots#
the linkml generator can be used with the
--materialize-attributes option to materialize all induced slots
as attributes. This is useful if you want to make a version of your
schema for distribution that frees the program that uses the schema
from the need to traverse hierarchies and implement propagation logic.
For example, if this option is used with the above schema, then the
Person class will have attributes from both NamedThing and Person
combined. Furthermore, if Person uses
slot_usage (see next section)
to refine the meaning of a generic slot in the context of Person, then
these will be materialized for Person.