Each attribute in a complete collection of knowledge about the real world has an associated value. The possible values an attribute may assume are determined by the type of the attribute. In the case of Normal Attributes, their permissible values can be set in the Ontology Editor.
An important feature of Normal Attribute values is that they may be stored with their intrinsic hierarchical structure - allowing for much more expressive mapObject descriptions, and much more powerful querying. <View an example of hierarchically structured values>
Alternatively, an attribute can be of type free text or free numeric. In the case of free text, the attribute can take on any value, and it will not be used during query matching.
In the case of being of type free numeric, the value can be any number, and may include ">" or "<" operators.
Unknown Values:
How any information system deals with unknown values can significantly affect the power and flexibility of the system.
LegendBurster's semantic net representation of information does not use a specific value for "unknown". Rather, unknown values are simply left unstated. During querying procedures, the user is able to control whether the absence of an attribute/value pair implies simply that it is not known (a "softer" option, which would incur low scores), or that its opposite is true - and option that would lead to either relatively high rewards, or relatively high penalties (in the case of a conflict in attribute-value truth-status). (An example of the latter would be the system concluding that gold is absent from the rock, if there was no statement to say that it was present.)
LegendBurster's query resolution methodology is explained in Appendix 3: Query Scoring Methods
Attribute values have a second role in knowledge representation, in that they also define a "sub-class" of the entity/attribute class from which they derive. This becomes important when an attribute is regarded as an entity, and a need arises to consider what its attributes are. In such a case, some of its attributes will derive from the class that it belongs to, and some from the sub-class it defines. This aspect to values is explained in detail in the "Working with Attributes" section, which may be reviewed by clicking <here>.
Value domains are the collections of values which may be assumed by a Normal Attribute. Sometimes these may be context-dependent, which may lead to the separation of sub-domains.
Value Sub-Domains arise because there are many attributes, that, while they mean or refer to different things, draw their values from the same source.
For example, the attribute "letters" will have as it's values, all the letters in the alphabet. But it is not necessary to create a separate Top Level Domain for "consonants" when all it's possible values are already contained within the values of "letters". Rather, if "letters" has been defined as an attribute Value Domain, the attribute "consonants" may be defined as a sub-domain of "letters". <see example>
The values that "consonants" includes from the "letters" domain are specified by editing the "consonants" sub-domain after it has been created from the "letters" domain. All of these procedures are described in the section on editing values.
Value Domains may be imported from other LegendBurster projects using the "Import Value Domain" button on the main Ontology Editor screen, which is described here.
This is an important aid to standardising ontologies across projects, and can save considerable amounts of time, particularly when attribute value domains are large hierarchical collections of values, which may be well-documented with comments or definitions. View an example here.
This example was generated by the TreeList Editor program, available from Georeference Online Ltd at www.georeferenceonline.com. TreeList Editor can read exported LegendBurster Value Domain tables (ie: attribute value tables), and is a very useful tool for creating, editing, viewing, comparing and outputting hierarchical data.
There are two special values that can be selected for a feature: <other values>, <any value>.
The feature [attribute, <other values>, frequency] specifies whether other values are allowed for the attribute. If the frequency is "never", this means that no other values are allowed for the attribute and extra penalties will be incurred if the instance contains features whose values do not match those of the model - even if the query is not being evaluated under "silence implies absence" conditions. Alternatively, if the frequency is not "never", then other values for this attribute are possible, and no extra penalties will be incurred.
The feature [attribute, <any value>, frequency] specifies that any value is allowed for the attribute. However, no rewards are given to an instance’s feature that matches it.
Value Attributes
Value Attributes are attributes related to an entity, not because of the class it belongs to, but because of its value in the class (effectively, because of its sub-class).
When LegendBurster is called on to provide the possible attributes for any entity (during instance description, or query definition), it takes into account both the class of the entity, and its value (sub-class).
Example: We may define a class of entities in our domain of interest to be "geological structures", with sub-types "faults" and "folds". Since all structures have the attribute "age", faults, as well as folds, would have an attribute "age". However, faults have many attributes that folds do not have, and vice versa. In LegendBurster, we would call these "value attributes", because they exist for a geological structure depending on whether its value (sub-class) is "fault" or "fold".
To see the illustrated explanation of this example which appears in the section on "Working with Attributes", <click here>.
To see where Value Attributes are displayed in the Ontology Editor <click here> (see Item 5).