Property Visualizers
Copyright (c) 2022, this book is offered to the world under Creative Commons license CC BY-NC-SA 4.0
Last updated
Was this helpful?
Copyright (c) 2022, this book is offered to the world under Creative Commons license CC BY-NC-SA 4.0
Last updated
Was this helpful?
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 :
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.
<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
The above figure also illustrates personalization controls (). Clicking on the control will show visualization options available for that property (e.g., the availability of alternate visualizers for this property type). Dragging the control for a property allows the display order of that property within its containing node visualizer to be changed as discussed above.
