tator
tator copied to clipboard
Evaluate attribute groups
The Problem
Project that have types with many attributes have visibility issues in many UIs or visual representations.
What can we do?
In the AttributeType
definition a group concept could be added. The list could also be converted to a dictionary where each key represents an attribute group, but that is a massive change and API breaking.
In a smaller mod which would be backwards compatible a few new fields could be added:
- GroupName: If not null, this attribute is associated with other attributes with the same group name in the given type.
- GroupOrder: If not null, this attribute specifies an order of precedence to a group's attributes. While a REST response would return all attributes the order of precedence could be used to provide some level of summary experiences to visualizations.
Potentially taking it further a non-group attribute field could be added as follows:
- Kind: If not null describes the kind of data the attribute represents. Could be an enum of
EXACT
,QUALATATIVE
.
Examples:
A hypothetical LocalizationType
has 5 attributes, Region(string), Ocean(string),Position(geoposition) and Category and Type, both strings. Under the proposed new model the type definition could be expanded to include additional information beyond the current description, name, and dtype in the array in the LocalizationType definition. Specifically the additional information in the example is as follows:
Location group:
- Region: dtype:string, groupName: Location, groupOrder:0, kind:QUALATATIVE
- Ocean: dtype:string, groupName: Location, groupOrder:1, kind:QUALATATIVE
- Position: dtype:geopos, groupName: Location, groupOrder:2, kind:EXACT
Identification group.
- Category: dtype:string, groupName: Identification, groupOrder:0, kind: EXACT
- Type: dtype:string, groupName: Identification, groupOrder:1, kind: EXACT
An example datum is a "Fishing Vessel"(Category) identified as a "Sailboat"(Type) at 25 degrees north latitude, 71 degrees west longitude in an area known as the Bermuda Triangle in the Atlantic Ocean.
Based on this new information a visualization could show precedence to the user's wants, wills and desires.
- If some level of summary is desired only "groupOrder" 0 elements could be displayed.
- Because all data is returned tool tips or some kind of depth dimension in the UI could expose additional detailed information. Like in this case it might say, "Fishing Vessel in the Bermuda Triangle" but the user could 'explode' out either of those descriptions for more information. Contextual information like Atlantic ocean could be available as well in a similar manner if something like the Bermuda triangle was a novel concept or needed additional context to make sense.
- If a user has a want for only EXACT data, the first EXACT element of that group could be displayed.
- Additional logic of looking for the first non-null element of a group could be utilized.
- Utilizing the group name over the attribute name could be utilized in summary applications. This means referring to "Location" logically in the chosen context even if that represents position OR ocean OR region in the logical sense.