Naming Objects: Plain vs Dynamic

CORE Admin

The accessibility and flexibility of nodegoat allows for a collaborative and ongoing data entry and data curation process. The experience learns that data consistency becomes a challenge as soon as data entry processes become collaborative or are executed over longer periods of time. Especially when the data structure is complex and data sources are ambiguous, consistency is an increasingly prominent factor. To ensure uniform identification of each object within the dataset, the name of an object should both be consistent and inclusive.

Within nodegoat the name of each object can be a plain text field, generated dynamically, or a combination of the two. When generated dynamically, the object name can be build from its definitions for consistency and include the definitions from other named objects for inclusiveness. A rather exhaustive naming scheme for a painting could look like this:

painting = title + material + artist (person = last name + first name + year of birth + location of birth (city = name + country code) + year of death + location of death (city = name + country code)) + year)

This produces:

'Man in oriental costume (oil on panel) - Rijn van, Rembrandt (1606 Leiden (NL) - 1669 Amsterdam (NL)) - 1632'

By generating object names dynamically, changes in named objects (such as artist and city in the example of the painting) are also reflected accordingly in the name of the objects.

Due to the unrestricted relational nature of the naming algorithm there is a potential problem for recursion. Recursion can be introduced directly (e.g. the name of a person includes the name of the person's parents) or further down the naming scheme. By limiting recursion to a single step it is possible to leverage this feat and include family ties within a person's name without running into an infinite loop.

In a future blog post we will discuss the possibility to complement the dynamic generation of object names with conditional formatting.


Add Comment