Associating the Metadata Definitions

Associations between metadata can be created in several ways, depending on the purpose of use of the vaults. The target vault can be used in archiving, replication, backups, and publication. For this reason, you should consider – before creating a vault that might be used as a target vault – which implementation is the easiest and best for creation of the desired vault.

If the association and synchronization is performed between two or more existing vaults, check the association of the metadata definitions and define the scheduled export and import between vaults.

By default, M-Files associates metadata by the following methods (in order of relevance):

1. The built-in metadata definitions are always automatically associated, regardless of the manner of creation of the vault metadata structures or methods of performing the association. These metadata definitions might be Name or title, Created by, Last modified by, Keywords, and so on. In publishing operations, you may want to hide some of these. For example, you may not want to show the document creator in the publishing vault. You can edit the built-in metadata to suit the publishing operation with the registry settings and permissions.
2. All the items have a GUID (globally unique identifier). If there is a GUID match across vaults, the metadata definitions are always mapped automatically.
3. If the aliases match between the vaults, the association of the metadata definitions is always performed. The alias must be manually defined in each vault for the metadata definition in question. For more information, refer to Aliases for Associating Metadata Between Vaults.
4. If both metadata definition's ID and the name match, the association of the metadata is performed automatically. This default setting can be changed from the registry settings. Note that when the association is performed with name, the names in line with the default languages for vaults are used. Also note that if the metadata structures have been separately created in different vaults, the IDs are not the same and the association must be done with aliases.
5. You can also use the name of imported metadata definition as its alias if there are no other aliases available. In this case, you need to define the alias only in the target vault using the name of the metadata definition from the source vault. For more information, refer Use the name of an imported element as its alias if no other alias is available under Importing Content.
6. If, in addition to those mentioned above, you want to have associations using the name only, you can include this definition in the registry settings. Then the name of the metadata definition, such as Telephone number, must be the same across vaults. When default settings are used, the name alone is not sufficient for association of the metadata. Note that when the association is performed by means of name, the names in line with the default languages for the vaults are used.

Because only the built-in metadata definitions and those matching the GUID or ID and name are associated automatically, for other metadata definitions the association must be performed by using aliases.

Aliases can be used for identifying semantically equivalent metadata. For example, when importing objects from another vault, their Date and Description properties can be mapped to the target vault's equivalent properties on the basis of aliases even if the properties' internal IDs and/or names are different. That is, the aliases refer to semantically equivalent metadata in different vaults. In other words, alias is a common identifier for the same metadata definition between several vaults.

The alias is defined as a common ID with the same name in both source and target vault.

When defining the alias, you can use various external data type and archive standards, such as SÄHKE2, MoReq2, and Dublin Core.

Check that there are sufficient definitions for all desired metadata definitions so that the association can be performed. Check the following: object types, value lists, property definitions, classes and class groups, workflows and workflow states, user groups, and named access control lists. In the properties of these metadata definitions, you can find the Advanced tab, where you can define the alias(es) for the metadata definitions.

For example, the source vault has the property definition Telephone number, whose vault-specific ID is 1001. The semantically equivalent property definition is also in the target vault, but the vault-specific ID is 1005 – the name can be the same (Telephone number) or different (for example Phone and Phone number) in the default language. If you want to associate these, you must define a common alias for this property definition in both vaults. The alias can be anything you want, such as Telephone number or dc.PhoneNumber, with the exception that it cannot contain both dots and spaces.

The alias is not shown to the users in the M-Files clients. The users see the name of the vault-specific property definition, just as before.

Depending on the purpose of use of the target vault, the users of the target vault may be the same as, or entirely different from, those of the source vault. If you want to grant certain users permissions for both vaults, synchronize the metadata for the Users value list, or do both, you should create user accounts with the same name for these users for both vaults. User accounts are not automatically synchronized between vaults.

The interaction between several vaults enables creation of relationships between objects across vaults. The objects are not exported from one vault to another; instead, the relationship is created by reference to an object in another vault; that is, a link is created to the original object. The object types of the objects must be associatable, but synchronization of the objects (replication of content) is not required, because the objects are not transferred from one vault to another. For more information, see Relationships Between Objects in Separate Vaults.