There is little difficulty in understanding what the word "attribute" means in normal conversation: it is usually understood to be some sort of characteristic. In a knowledge engineering environment, however, it becomes important to distinguish between the name of an attribute, and its value. (In natural conversation, these are often thought of as together constituting an attribute.)
For LegendBurster, therefore, an attribute is a named characteristic of an instance or a class, whose value is known in some situations, and may not be known in others. [Sometimes simply knowing whether something has a particular attribute or not, independently of what its value may be, is important information which may be difficult to establish.] The value of an attribute we call an "attribute value". For example, if "the colour of rock X is red", the instance is X, the class of this instance is "rock", its attribute is "colour", and this attribute has value "red".
In its current version, LegendBurster recognises five different types of attributes:
Normal attributes are those which qualify an entity with a value which is chosen from an explicit domain or sub-domain of allowable attribute values. In practice, in LegendBurster, the normal attributes' values are chosen from drop-down lists. However, if hierarchical relationships exist between the values, the hierarchy can always be viewed, and the values chosen from the hierarchy viewer.
For example, "colour" would be a normal attribute if its value had to be chosen from the following list (domain or sub-domain) of colours: (red, green, blue).
Free Text attributes are attributes whose values may be freely entered to the system by the user (ie: un-controlled by the ontology), and which can hence not be used for queries or comparison purposes. They are not chosen from pre-determined lists of values, and they are particularly useful for attributes such as names (eg: New York). They are very efficiently transferred to semantic net descriptions from shapefile attribute tables using the "Direct Add" method.
A free numeric attribute is a kind of free attribute limited to numeric values (eg: 0.0023) or thresholds (eg: >345.6). LegendBurster is able to incorporate free numeric values into its querying and similarity-ranking procedures.
Conventions for entering numbers and thresholds are explained in the section entitled "Conventions for Free Numeric Values".
Referring Attributes are attributes that refer to, or point to, other entities or classes which already exist in a description.
An example is the attribute "surrounds". It requires at least two entities - the entity that is surrounded, and the entity that does the surrounding. Since a relationship implies a link in both directions, when adding a Referring Attribute, the user also needs to specify the name of the inverse relationship. Then, both the Referring Attribute, and it's inverse are added to the system's list of attributes.
To read more details on how Referring Attributes are implemented in LegendBurster semantic nets, click here.
To read more details on how Reified Attributes are implemented in LegendBurster semantic nets, click here.
Value attributes are the same as any other attributes, except that they are associated with an entity by virtue of its value ("sub-class"), rather than its 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". This example is illustrated in the Ontology Editor screens shown below:
Screen1: In this view of an ontology, filters for entities, attributes and value domains have been set to display all entries. Since the "Age" value domain is selected, its values are shown. No value attributes are shown because the selected age value "Aalenian" does not exist in the entity list, and therefore has no value attributes.
Screen 2: In this view, the filters have been set to display only attributes of the selected entity, and the value domain of the selected attribute. Since the "FreeNumeric" value domain does not have a limited list of values, no values are shown in the values column.
Screen 3: In this view, the display filter settings are the same as for Screen 2, but the "fault" entity has been selected, as has its attribute "faultType", together with its value domain also called "faultType". Since "faultType" is not a free domain, its possible values appear in the value column. The value "lateral" does not have any value attributes.
Screen 4: Again with the same filter settings, this screen shows the selection of the "mapObject" entity, its attribute "GeologicalStructure", the latter's value domain "GeologicalStructure", and that domain's value "fault". As expected, the "fault" entities' attributes appear in the value attributes column.
The Knowledge Engineer faces a number of decisions when selecting the attributes with which to qualify entities - in particular regarding the specificity of the attributes chosen.
Highly specific attributes usually included adjectives or adverbs in a phrase required to specify the attribute (eg: "contains enhanced element"), while more general attributes (eg: "contains element") are shorter, and require qualification of the characteristic built into the more specific attribute at a deeper level of the semantic net hierarchy. The two cases are illustrated below:
Note that the value domains for HasEnhancedElement and HasElement are the same.
The situation is different in the following example, where the attribute "HasMineralisationForm" references a collection of form descriptors hierarchically arranged by scale, while the attributes "HasMacroMineralisationForm"and "HasMesoMineralisationForm", which are distinguished by scale, have to reference different value domains (both of which could, however, have come from the same top level value domain - in which case we would say they are from sub-domains):
Note that the representation in Figure B expresses the "contained by" relationship of the oolite mineralisation to the banding, which requires two extra relationship nodes to be present in the representation of Figure A, as would also be required in the representation of Figure C.
In the cases of Figures B and C, the HasMineralisationForm attribute would be drawing its values from a value hierarchy such as the following (all feeding into the same value domain),
while the "HasMacroMineralisationForm"and "HasMesoMineralisationForm" attributes would each draw from their own value domains (both of which could be implemented as sub-domains of the same top level value domain, which could be the same top level value domain providing values to HasMineralisationForm).