Fields
Details about inherited values and how to configure a field to inherit a value from a record higher in a record hierarchy can be found in the Axiell Designer Help.
The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in database tables. Each record is a collection of fields, and it is mostly with fields that you interact as you work with Axiell Collections: searching one or more fields, editing data in a field, and so on.
Throughout this documentation we explain how to perform tasks such as searching, sorting, and editing records, all of which involve working with fields in one way or another. Here we take a step back and focus on fields themselves, starting with the basics:
A good place to appreciate that a record is a collection of fields arranged in logical groups is Record details View: this View displays all available fields in the current record The record currently displayed in Record details View or highlighted (with a solid grey background) in Result set View or Gallery View for instance. following a search, the importation of records, retrieval of records from a saved search, when adding a new record, and so on. In this example we see that a record in the Persons and institutions data source The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. typically has six panels:
Each panel contains related fields grouped under a heading. On the Identification panel we find four groups of fields:
At the lowest level each of these groups consists of one or more fields. In this example, the Authorised form of name group consists of five related fields:
Tip: A record can consist of many hundreds of fields arranged across multiple panels in Record details View. See Find a field to learn how to locate a single field amongst the many.
System name vs field label
As we see above, each field has a name in the User Interface (UI). It is important to understand the difference between a field's name (its label) in the UI and its system name, and perhaps more importantly, its unique two character tag:
When working with records in Record details View (or a Zoom screen A Zoom screen is a pop-up screen similar to Record details View but with fewer options, fields and panels. It will pop-up and display summary details of a Linked record (for a term, person, location, etc.) when an underlined value is clicked in Display mode or the Details button is selected when linking records in Edit mode, for instance. Typically, record details in a Zoom screen can be edited.) you will see that a field has a label, Notes for instance, which broadly describes the information expected in the field. Field labels are not unique and the same label can be used elsewhere in the same record. You will find many Notes, Type and Date fields for instance:
Field labels can be customized by your institution; and in a multilingual environment they can be translated. Clearly, a field's label will say something about the data the field holds, but it is not a unique identifier, and when working in Collections, running a report or performing an Advanced search for instance, it is necessary to uniquely identify a field.
To do that we use a field's system name or tag.
The simplest way to identify a field's system name and tag is to hover the mouse cursor over the field. A tooltip will display the field's system name and tag, name and BA
respectively in this example:
For the most part, you can use the system name or tag to uniquely identify a field. Note however that in a multilingual environment a field's system name can be translated and the tooltip will show the system name in the current interface language, French in this example:
While this should not be an issue when referencing a field in the current interface language (and it is not an issue if your system is monolingual), keep in mind that the field tag is the same across all languages and it is an infallible identifier of a field.
Data entry, data types and data validation
A field's data type determines what kind of data you can enter in a field. A field with a Text data type will accept all characters, a Numeric field will accept numeric decimal numbers, an Integer field will only accept whole numbers, a Date field expects dates, and so on. For the most part it is obvious what data is required for a field (and if you enter the wrong sort of data, Collections will warn you).
As you enter data in fields you will find that Collections provides practical assistance and measures that help ensure the quality of your data, for example:
- Increasing the size of fields dynamically as you enter data so that all your data is readable as you enter it.
- Controlling the type of data that a field will accept and validating data to ensure that it complies with the requirements of the field.
The type of values that you can enter in a field is determined by a field's data type, which include Text, Numeric, Integer, Date, Application A field with an Application data type is associated with an application, such as a PDF reader; it is possible to link such a field to a file of the appropriate type (e.g. a .pdf file) and subsequently open the file by clicking the underlined data (typically a filename) in the field., and so on. Additionally, a field can be configured to be unique (fields like object_number (IN)) so that no two records hold the same value in the field.
Details about a field's properties are available in the Field properties box, which is accessed in Display or Edit mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record. by right-clicking a field and selecting Properties from the context menu:
Note: Details about all options available from this context menu are available here.
Information in the Field properties box includes a field's system name and tag (e.g. creator (VV)), and its data (field) type (e.g. Text):
Note: Full details about the Field properties box can be found here.
All data entered into fields is validated when you exit the field (by pressing TAB or clicking another field for instance). If the data entered in a field is not valid for the field (letters are entered in a Numeric field for instance, or a non-unique value is entered in a field configured to hold unique values only), a message will pop-up indicating how the value is invalid:
- Non-unique value:
You cannot save a record with a duplicate value in a unique field.
- Wrong data type:
If you do not correct the error and save a record with the wrong type of data in a field, the record will be saved but the erroneous value will be cleared from the field.
It is still possible to enter inaccurate data in a field, of course; for instance, a date field expects numbers and entering meaningless numbers or the wrong date will be accepted. Validation does not guarantee that the data entered is accurate, but does guarantee that the data is appropriate for that field, i.e. a date has been entered in a date field.
Why some values have a dotted underline (or they are faded)
When viewing records in Record details View you may come across fields in which the data has a dotted underline (or it is faded in older versions of Collections1). These values are inherited from another record or, in a multilingual environment, they are invariant values:
If data in a field has a dotted underline (or it is faded / lighter grey than other data in older versions of Collections), the value has been inherited in one of two ways:
Where records can be arranged in a hierarchy, a field can be configured to be inherited so that a record lower in the hierarchy inherits a value entered in a record immediately higher in the hierarchy (its parent). This can be efficient as a value only needs to be entered and saved in the parent record to be inherited by all of its children; importantly, while the value displays in a child record it is not stored in that record (in the child record the field is actually empty until the field is edited and the inherited value is overwritten).
In the following example, the Conditions governing access and Conditions governing reproduction fields are configured to be inherited and data has been added to both fields in a parent record:
When we view a record lower in the hierarchy, the values from the parent record are displayed in these two fields but with a dotted underline to indicate that they have been inherited:
In summary, when data in a field has a dotted underline (or it is faded / lighter grey than other data), it is displayed in the field but not saved in the current record. When you edit the field, the edited value is saved in the current record.
More details
More details about inherited fields here.
In a multilingual system it is possible to specify at the system level that a language is an Invariant; it is also possible to set an invariant language manually on individual fields. In either case, values in the Invariant language will display for every other available language until a translation has been added. Specifying invariancy ensures that a value is available when records are viewed in every available language even if the value has not yet been translated, and it serves as an aid for translation.
In this example, English has been set as the Invariant language at the system level, and the title of a book has been added in English:
The value has not been translated into French and when the data language has been switched to French, the English value displays as faded text to indicate that it is an Invariant value:
When the data language is French and the value is translated, the new value will not be faded.
See Working in multilingual systems for details.
Why some fields have a background colour or no border
When editing records in Record details View you will find that some fields have a background colour or they have no border. This tells you something about data entry for the field. For instance, a field with a red background is mandatory, and a field with no border cannot be edited in the current record The record currently displayed in Record details View or highlighted (with a solid grey background) in Result set View or Gallery View for instance.:
Colour |
Field |
Details |
---|---|---|
White |
Editable field |
Most fields have a white background. Data can be entered in the field:
If a field does not include an icon, simply key data into the field. If a field does include an icon, as in the example above, how you enter or manage data depends on the icon. Details here. |
Red |
A red background indicates that a field is mandatory and a value has not yet been entered:
It is not possible to save the record until valid data has been entered in the field: if a mandatory field is missed, a warning message will display indicating which field is mandatory and on what panel it can be found. Once a value has been entered in a mandatory field, the background changes to white. |
|
No background or border (grey background in older versions) |
Replicated field (in the current record) |
Usually a field only appears in one place in a record; however, the same information may be relevant in more than one place and for that reason a field can display more than once in the same record. Typically only one instance of the field is editable. For example, details about an object's current location may appear on both the Identification panel and the Location | Future movements panel in a record in the Object catalogue. Details about an object's current location are entered on the Location | Future movements panel in the current_location.name (2A) field:
The same field appears on the Identification panel but there it has no border (until the cursor is over the field) and it is not editable:
In older versions of Collections2 the replicated field has a grey background:
When a value is entered in the editable version of the field, it will display in the replicated field:
|
No background or border |
In Edit mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record. a Merged-in field has no background colour or border (until the cursor hovers over it) and it is not editable:
The value that displays in a Merged-in field is pulled dynamically from a linked record: when you link two records by selecting a value in a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref)., other fields in the primary record A link is made from one record (the primary) to another (the target). can be auto-filled with values from the record you are linking to. For example, a record in the Object catalogue is linked to the record for
More details See Types of field for full details about Merged-in fields. See How to link records for more details about these fields. See Searching remote indexes for details about searching Merged-in fields. |
When adding a new record, you may find that one or more fields in the new record already include a value: these are default values. Your Application Administrator can specify that a value displays in a field by default whenever a record is created. A default value is the most commonly used value in a field and is intended to save time and effort during data entry. It can be overwritten at any time.
When editing a record you will find that you cannot enter new values in some fields, or edit existing values but must select a value from a drop list. These are called Enumerative fields and their values are added and, in a multilingual system, translated by your Application Administrator in the Collections administration tool, Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc..
Tooltip
Information about many elements in the Axiell Collections user interface is available in a tooltip by hovering the mouse cursor over an element. For example, hover the cursor over a field to display the field's system name and tag: