Field definitions have the following properties which must adhere to certain Field Definition Restrictions.
Property | Description | Since |
|---|
Family | Describes the family to which the field belongs → Metadata Families | |
Key | | |
Dotted Key | Primary key of a field definition Composed by concatenating the following pieces with a dot . The descriptive field Keyword has as dotted key Descriptive.Keywords.Keyword
| Tip |
|---|
The dotted key is the reference format for the MediaHaven REST API 2.0 |
| |
Parent dotted key | | |
Top | | |
Sub Metadata fields / Child | metadata fields (see Complex Fields). Such nested fields fields fields . | Top | Inverse of the property sub. Each file consists of a list of top fields whose key is unique | |
Flattened Key | A sub field cannot be uniquely determined by its own key because the key for sub fields is not unique across all fields. By concatenating the key of the parent field(s) with the key of the sub field, you obtain a unique flattened key. For example the field Keywords with sub field Keyword, yields a flattened key KeywordsKeyword. | Note |
|---|
Deprecated: The flattened key is allowed in the MediaHaven REST API 2.0 but the dotted key is the preferred |
format | Dotted Key | Same principle as for flattened keys but now the concatenation contains a dot . between each part and the first piece is the family. | Tip |
|---|
The dotted key is the reference format for the MediaHaven REST API 2.0 |
| |
Lucene Key | Name of the field in Lucene. For legacy reasons it can differ significantly from the key of the field. From 18.1 the REST API allows for using the field key instead of the Lucene key in queries. For sub fields you must use the flattened key. This allows for bypassing the legacy Lucene keys. From 19.1: the Lucene key always corresponds with the flattened key
| Note |
|---|
Obsoleted: The Lucene key is no longer allowed in the MediaHaven REST API 2.0 |
| |
Required | If true, this field will always be present for every record with a non empty value. | |
Read Only | The value of this field cannot be changed using metadata updates. | Note |
|---|
Read-only field definitions are not possible for Dynamic fields. If you want “Read-Only” dynamic fields, consider either setting it to “Read-Only” in the Profiles or use the “Write Once” feature documented below. |
| |
Write Once | Field can only be filled out once from empty to its final value Subsequent changes to the value are ignored Only allowed on top fields
| 22.1
|
Index | If true, make the field searchable in the index Note: a field can be present in the index without being indexed.
| |
Global | When using the standard search, it searches in a hidden virtual field which contains as value a join of all fields marked as global | |
Advanced Search | If true, make it available in the advanced search. Requires the field to be indexed. | Note |
|---|
Obsoleted: No longer has any effect because the advanced search is now controlled by Profiles of type advanced search. |
| |
Tokenize | Informally speaking, tokenizing means splitting the string value of the field on white space in tokens. Requires the field to be indexed. For example the field Description with value "Alice Bob Cedric" is split into the ordered tokens "Alice", "Bob" and "Cedric". The file can matched in the index: using these tokens separately: +Description:Cedric +Description:Alice in a specific order: +Description:"Bob Cedric" note: +Description:"Alice Cedric" will not match
| |
Sortable | Only field marked as sortable can be requested for sorting in the REST API When the field is multi valued, e.g. Descriptive.Keywords.Keyword = A, B then only the first value A will be used for the sort Multi valued textual fields are stored alphabetically
| Family | Describes the family to which the field belongs → Metadata Families | |
Type | Describe the type of the field definition → Metadata Field Types | |
Regex | Regular expression used to validate the value of the when saving a record. Only applies to Simple Fields. | 23.4
|
