Customise Elements' data structure

This article suggests best practise for modifying the Elements data structure.

Try as much as possible to keep to default structure and only make variations if absolutely required. This is because default structure is what is populated by synchroniser and re-used in standard display and reports.

In developing your structure you should consider that in normal operation, the majority of your publications will originate from external sources. These sources will populate the types and underlying fields of our default structure, therefore any modifications you make to the data structure will only be relevant to manual records (created by users in the system) and legacy imports.

See the Managing Types and Underlying Fields article for more information on the default types and how you can add custom types and fields. 

Consider the following consequences before deciding to create custom types and fields.

• Any additional types and underlying fields will not be populated by external data fields - for example, customised conference sub-types (e.g. full conference paper, abstract, conference paper in published proceeding). When a conference proceeding is found in any of the data sources, it will post those records in the default, built-in "conference" type. This means that a significant amount of manual work will be required in order to "recategorise" them into the various but similar types. We would recommend the use of Label Schemes or underlying fields to capture this type of "categorisation" type information

• Existing types and underlying fields cannot be deprecated as these may still be populated by the external sources and used for matching purposes. For example, you are unable to deprecate the default publication-date field as external data sources will populate this, and this is in turn re-used within the system in a variety of places.

• Existing types and underlying fields can be renamed but should not be renamed to something conceptually different. Bearing in mind that external sources will populate the existing data structure, it is important that the names of the types and fields of the default structure remain conceptually the same, otherwise you risk having e.g. "book" data populated into a renamed type "curated works".

• Any non-bibliographic metadata or internal 'administrative' data should not be stored at the record level as these are not included in records sourced from external sources and will thus require that you create a manual record for every publication just to capture that information for those records. An example here is introducing an underlying field to capture peer reviewed status. Presently, this is not data that is brought back from external sources and does not form part of the standard metadata of the bibliographic record. As you are unable to edit data sourced externally, in order to identify a publication as being peer-reviewed you would need to create a duplicate manual record that you can edit to store this information. We recommend the use of labels for storing this data as this is data specific to the publication and not to the underlying records. This is also holds true for any additional internal 'categorisation'-type information you may wish to capture.

• Try to keep the number of types as low as possible (particularly if these types are similar in meaning). This will improve the user experience as a large number of options and a choice of types that are only subtly different, will end up confusing the academic who may not normally be expected to accept the burden of changing publications to the new types.

• Where possible try to make use of existing underlying fields rather than creating entirely new ones - if an underlying field is conceptually the same, or similar from type to type then by re-using existing underlying fields you can ensure that that data is retained if the types are ever changed.

All objects in Elements follow a similar object model of object types and corresponding underlying fields. The structure can be almost entirely customised, with the exception of removing certain default data fields in the Publications and Grants modules which are required for automatic harvesting.

It is recommended that you review your source data and investigate the various data types and underlying fields you may wish to create in Elements. The format of the import file will be dependent on the type structure in Elements, so it is important that this be looked at before preparing the data.

The following table outlines some of the factors and options for you to consider when varying from the default structure.

Related articles:

• Categories, Types and Underlying Fields