Representing Complex Entity - Attribute - Value Associations

<Quick Jump to Referring Attributes>   <Quick Jump to Reification Attributes>

Entities, attributes, and attribute values are the components of semantic nets, as illustrated in the previous section.  The relationships between these three components are shown again here to illustrate how they may be recursively applied to incorporate greater and greater amounts of detail about the "highest level" entity being described.

           

 

"Referring" Attributes

Sometimes we find that we need to refer to an already existing entity, effectively as an attribute of another entity  -  for example when we want to say that a mine has a "fold", and the fold occurs in a granite which hosts the mine, we may represent the information in this way:

In such a situation, the value domain of the attribute "occurs in", which is a reference to another entity (the granite), is the collection of entities already existing in the semantic net, whose class is appropriate for the context (in this case, class = hostrock).

To implement this functionality, LegendBurster does the following:

  1. Allows the user to create "Referring Attributes" with the Ontology Editor, whose allowable target entity classes have to be specified during the attribute creation procedure.  Its inverse attribute also has to be named at this time.

  2. Presents to a user entering a referring attribute into a description all qualifying entities which already exist on the semantic net (object or query), ahead of taking as input one or more of the qualifying entities as targets.

  3. Writes the target entity(s) node numbers into the referring attribute's value field, and an appropriately informative label into its label field (usually the value of the target entity), and then does the same for the target entity(s) with regard to the inverse attribute.

In this way the required link is effectively established.  Arrows are suffixed to attribute/value pairs when they are displayed to the user on screen or in print to flag the presence of in-coming (<-) or out-going  (->) links, as shown in the example on the left.  (The sense of whether these are incoming or outgoing is determined by the semantics of each link.)

 

 

 

 

"Reified" Attributes

When an expression of fact requires reference to an association of attributes, a commonly used knowledge engineering technique, called "reification", converts the multi-attribute relationship into a "thing" with its own identity, and makes the attributes which are part of the relationship into attributes of the newly-created "thing".

Examples of such a situation in a geological context would be a contact between two rocks, or an alteration assemblage (involving minerals and other attributes: example).

On the "Create Attribute" screen, LegendBurster's Ontology Editor allows the designation of an attribute as a "Reified Attribute", in which case it will behave, and be treated, in the following manner:

  1. At the time a reified attribute is created, an entity with the same name as the reified attribute will be created

  2. After creation of a reified attribute, the user will need to input values for the attribute domain. The number of values input would depend on the maximum number which might be needed in any descriptions or queries, given consideration of (3) below.  Values should ideally have a first part which remains constant, and might be the same as the attribute name, and a second part which is ideally an increasing number or letter (examples: "assemblage 1", or "contact A").

  3. Each time a reified attribute value is used when describing a map object or a query, that value is removed from the list of values available for any future attribute/value pairs of the same domain that may be entered.  This ensures that every reified attribute is given a unique name.  Although this name will not be used by the system during any comparisons with other map objects or queries, its unique identity is crucial to resolving which parts of a description match which parts in any other description or query.

  4. During the comparison of queries to map objects, all reified attributes (entities) of the same class are compared with all the equivalents in the compared object  -  and paired up based on quality of match.  in other works, after the best matching pair is found, they are "paired", their matching scores are calculated, and they are removed from consideration.  Then the next-best matching pair is sought, and so on.  When an unequal number of reified attributes is processed, the attributes which would have produced the poorest matching scores are left unpaired.

 

"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".

Value attributes are described in greater detail, with screen-shots from the Ontology Editor in the "Working with Attributes" section.

See where Value Attributes appear in the Ontology Editor (see Item 5).