Property Visualizers

Copyright (c) 2022, this book is offered to the world under Creative Commons license CC BY-NC-SA 4.0

The MAP L0 Ontology provides for the definition of both primitive and composite property types. Property values differ from holons in the following ways:

  • property values they have no independent existence. Properties define the qualities of a holon. They have no existence independent of their holon.

  • they have no unique identifier

  • properties cannot participate in relationships with other holons.

DAHN provides default visualizers for each property type. The following shows simple visualizers for a string property type:

The figure illustrates the appearance for a Short String Visualizer and a Long MD (for Markdown) String Visualizer. Two modes are shown for each visualizer: read-mode and edit-mode. Meta-data about the string property (e.g., min/max length, localized label, validation rules, format, etc.) are assumed to be stored in the L0 Property Type descriptor. The DAHN Selector Function could, for example, use the length and format of the string property to decide on whether to use the Short String Visualizer or Long MD String Visualizer for a given property. Additional factors could influence the selection and configuration of visualizers. For example, the actual observed length of instances of a given property could be used to calculate the visual size of the field and/or adjust font sizes used.

As another example of a property visualizer, the visualizer for a date property type may display the localized label (e.g. publication date) and display the date value in a localized date format. In edit mode, the date visualizer could allow the human agent to either enter the date from the keyboard or select the desired date from a calendar pop-up.

For simple property types, the selection of a property visualizer is fairly straightforward. The choice gets a bit more interesting when dealing with enumerated property types -- i.e., property types where there is a finite list of valid values. Notice the format property in our previous example:

The example shows a Single-Select, Drop List visualizer for the format property. However, other choices are possible:

The DAHN selector function can be thought of as evaluating a set of rules. For example, consider the following ruleset :

// Selector Rules for ResourceFormat Enumerated Property Type
// Rule #1
if (count_of_possible_values <=7) 
then if (number_of_allowed_selections > 1)
        then use CheckBoxVisualizer
        else use RadioButtonVisualizer

// Rule #2
if ((count_of_possible_values > 7)
    AND(count_of_possible_values <= 20)
then if (number_of_allowed_selections > 1)
        then use DropListMultiSelectVisualizer
        else use DropListSingleSelectVisualizer

// Rule #3
if (count_of_possible_values > 20)
        AND (number_of_allowed_selections > 1)
        then use TypeAheadSearchVisualizer

To use this ruleset, the selector function retrieves the length of the list of possible values (count_of_possible_values) and whether or not the agent is allowed to select multiple values (number_of_allowed_selections > 1) or only a single value from the meta-information about the ResourceFormat property type maintained in the L0 MetaSpace happ.

In our example, the list of values for the format property type consists of 12 values, so Rule #2 applies. Assuming (per the L0 descriptor) only a single value is allowed for the format property type, the Single-Select form of the Drop List is appropriate.

In addition to meta-information maintained in the Meta-Space happ, the DAHN selector function may also rely on information maintained within the DAHN happ itself. This is explained in the #dahn-is-adaptivesection.

Initial DAHN Property Types

<list of property types... JSON too limited, Open API/Swagger, mime types, semantic web types, Bali, primitive and composite properties>

Copyright (c) 2022, this book is offered to the world under Creative Commons license CC BY-NC-SA 4.0

Last updated