Lucid Builder About Lucid scores

Applies to Matrix key projects

Absent

The Lucid Absent score is used to record that a state of a feature does not occur in an entity. This should be a definitive statement: if you are uncertain whether a state does or does not occur, it is safer to use the Uncertain score.

Absent is, in some ways, the most important score in Lucid. If an entity is scored as Absent for a state and a user of the Lucid Player chooses the state, the entity will be discarded from Entities Remaining into Entities Discarded, and hence will be removed from contention for the identification. A false Absent is a more serious error in a key than a false Present, since it will cause an entity to be falsely removed from Entities Remaining, and hence may preclude a correct identification.

Absent is the default score given to all entities for all states, until another score is given.

For numeric features, Absent is the default score if no numeric record has been entered for the entity. See the topic Scoring numeric features for more details.

Common

Common is the normal score given in Lucid when a state occurs in an entity. For example, if a species of plant always or usually has blue flowers, the state blue of the feature Flower colour would be scored using the Common score.

Common may be used in concert with other scores. For example, if a species of plant usually has blue flowers but occasionally has red flowers, then the state blue would be scored Common and the state red would be scored Rare.

For numeric features, Common and Rare values are coded by entering ranges of numbers in the Numeric Coding dialog box. See the topic Scoring numeric features  for more details.

Rare

Rare is used to record that a state occurs uncommonly or rarely in an entity.

Rare will usually be used in concert with other scores. For example, if a species of plant usually has blue flowers but occasionally has red flowers, then the state blue would be scored Common and the state red would be scored Rare.

Note that Rare should be used only in the case where a state occurs rarely in an entity, not in the case that the entity is rare. If a state always or usually occurs in a rare entity, you should still use the Common score.

In the Lucid Player, Rare is used to rank the list of Entities Remaining. If entity e is scored Rare for state s, then e will be moved down the list of Entities Remaining (List Mode) when the user chooses s (compared with other entities that are scored Common for s). Hence, if Rare is widely used in a key and at the end of an identification several entities remain, entities at the top of the list are more likely to be correct than entities at the end of the list.

For numeric features, Common and Rare values are coded by entering ranges of numbers in the Numeric Coding dialog box. See the topic Scoring numeric features for more details.

Uncertain

Uncertain is used to record that the key author is uncertain or does not know whether a given state occurs or does not occur in a given entity.

Uncertain will sometimes be applied to all states of a feature and sometimes only to one or a few states of a feature. For example, consider a key to plants which includes a feature referring to the colour of the fruit. It may be that one species in the key is known only from a few specimens and fruits have never been observed. In that case, all the states of the Fruit colour feature would be scored Uncertain. Another species may be poorly known and yet it is clear that the fruits are not white or coloured, but they could be black or dark grey. In that case, white and the coloured states could be scored Absent and dark grey and black both scored Uncertain.

In the Lucid Player in normal identification mode, Uncertain is treated the same as Common. That is, if an entity e is scored Uncertain for state e will remain in Entities Remaining when a user chooses s. This is appropriate behaviour for an identification, as e should not be falsely discarded if a key user has more information about it than was available to the key developer.

The behaviour of the Player can also be changed by un-checking the Retain Uncertains menu option, in which case Uncertain is treated the same as Absent. This would be appropriate if a user of the key is querying the Player to return a list of all entities known to have state s (rather than all entities that may have s).

For numeric features, Uncertain is coded as a special value in the Numeric Coding dialog box. See the topic Scoring numeric features for more details.

 Present by Misinterpretation, and  Rarely Present by Misinterpretation

While the Uncertain score in Lucid is used to capture uncertainty by the key developer, the Present by Misinterpretation scores are used to preempt likely uncertainty or mistakes by a key user.

Consider a key to fish with a feature Number of dorsal fins and the states one dorsal fin and two dorsal fins. Some species of fish clearly have a single dorsal fin, while others clearly have two dorsal fins. Angler fish have two dorsal fins, but the first is modified into a fleshy lure that does not look like a normal fin. In this case a user of the key may misinterpret an angler fish as having a single dorsal fin. If angler fish were scored correctly as having two dorsal fins many users would make a mistake at this point. Conversely, scoring angler fish as having a single dorsal fin (to account for the likely mistake) would introduce erroneous coding into the key.

In Lucid the Present by Misinterpretation scores are used to account for likely user mistakes while maintaining the integrity of the data. In the case of angler fish, the state two dorsal fins would be scored Present, and the state one dorsal fin would be scored Present by misinterpretation.

In the Lucid Player in normal identification mode, Present by Misinterpretation is treated the same as Common. That is, if an entity e is scored Present by Misinterpretation for state s, then e will remain in Entities Remaining when a user chooses s. This is appropriate behaviour for an identification, as it pre-empts e being discarded when a user makes a common and predictable mistake.

The behaviour of the Player can also be changed by un-checking the Allow Misinterpretations menu option, in which case Present by Misinterpretation is treated the same as Absent. This would be appropriate if a user of the key is querying the Player to return a list of all entities that truly have one dorsal fin (rather than all entities that may appear to have one dorsal fin).

The Rarely Present by Misinterpretation score is used to encode a case where it is occasionally the case that a state could be misinterpreted as being present. For example, a species of fish may normally clearly have two dorsal fins, but in occasional specimens one dorsal fin may be reduced to a small spine that could be overlooked. In the Lucid Player with Allow Misinterpretations check-marked, a Rarely Present by Misinterpretation score is treated the same as a Rare score; with Allow Misinterpretations unchecked, Rarely Present by Misinterpretation is treated the same as Absent.

Note that the Present by Misinterpretation scores are usually used in concert with other scores, as in the case above. Sometimes, however, Present by Misinterpretation or Rarely Present by Misinterpretation may be used alone, especially when a feature is controlled by a dependency. For example, consider a key to plants with the features Petals (with states present and absent) and Petal colour (with states white and blue). A species of plant in the key may lack petals but have white, petal-like bracts around the flower which could be misinterpreted as petals. This species would be coded as Common for the state Petals: absent, Present by misinterpretation for the state Petals: present and Present by misinterpretation for the state Petal colour: white.

For numeric features, the By Misinterpretation score is set as an annotation for a range of numbers in the Numeric Coding dialog box. See the topic Scoring numeric features for more details.

Not Scoped

The Not Scoped score in Lucid is used to enable coding of features that are useful and applicable only for a subset of the entities in the key. In the Lucid Player, features scored using Not Scoped are initially hidden, and are inserted into the Features Available list only when they become applicable to the identification.

Consider a large key with 1000 Entities. It will be appropriate to score some features for all the entities, using the normal Lucid scores (Absent, Common, Rare etc.). But consider a feature that is useful for identification only in a small subgroup of the entities, and which is inapplicable, ambiguous or insufficiently known for the bulk of entities. In Lucid, the entities in the subgroup can be coded for the feature, but all the other entities (not in the subgroup) will be given the Not Scoped score for that feature. In the Lucid Player, the feature will only become available when the list of Entities Remaining includes only entities that are scored for the feature using normal scores.

To explain the Not Scoped score further, consider a key to fishes with the following Entities and Features: