U bent hier

Moreq 2010

Model Requirements for the Management of Electronic Records / Modular Requirements for Records Systems

Termen uit Moreq 2010 (Modular Requirements for Records Systems)

MoReq2010 - Modular Requirements for Records Systems; Volume 1 - Core Services & Plug-in Modules, DLM Forum Foundation, Brussel, 2011.
Version 1.0

MoReq2010® aims to provide a comprehensive, but simple and easily understood set of requirements for a records system that is intended to be adaptable and applicable to divergent information and business activities, industry sectors and types of organisation. It avoids a "one size fits all" approach to implementing a records management solution by establishing instead a definition of a common set of core services that are shared by many different types of records system, but which are also modular and flexible, allowing them to be incorporated into highly specialised and dedicated applications that might not previously have been acknowledged as records systems.

The purpose of this document is to describe the minimum functionality required of a MoReq2010® compliant records system, to define common processes, such as export and disposal, and to establish and standardise on an underlying information model that includes entity types, data structures, metadata element definitions and function definitions. Where they are fully implemented, these will reliably support and underpin records system interoperability, including the successful transfer and migration of records in mid lifecycle, between differently implemented but compliant solutions from the same and different suppliers.
The functionality described by the MoReq2010® specification is purposefully intended to be built on and extended through a series of modules covering both generic and specific topics that will be developed in the coming months and years, overseen by the DLM Forum’s MoReq Governance Board, to meet the needs and demands of different markets, industries, countries and regions. (blz. 12-13)

Click one of the letters above to advance the page to terms beginning with that letter.



The degree of functionality a user is permitted to have with an information system described as a "level of access".


To interact with an information system so as to perform functions and to browse and inspect its entities.

Access control

The concept of managing users’ access to entities and to functions in an information system.

Access control entry

An individual entry within an access control list that grants one or more roles to a single user or a group.

Access control list

A list of access control entries associated with an entity that defines which users may perform functions on the entity by assigning roles to users and groups

Active entity

An entity that has been created in an MCRS and has never been deleted or destroyed.


An organised process designed to achieve an outcome.

  • Both human and computer activities are common within information

The function of including an entity within a set of entities, usually by moving it from elsewhere.

  • For example, adding a record to an aggregation.
Administrative role

A role that applies uniformly, through inheritance, to all the descendants of an entity, or if applied to a service to all the entities in the service.

  • By comparison, the inheritance of non- administrative roles is selective.

A technical administrator of an MCRS is a person charged with managing the infrastructure and technical environment that support its operation.

  • The technical administrator will have access and influence over external aspects of the MCRS such as its physical data storage areas and the error log, but is not necessarily a user of the MCRS.

The activity of bringing together entities with shared characteristics.

  • Specifically within MoReq2010® to create or move records into aggregations.

Aggregations of records are accumulations of related record entities that, when combined, may exist at a level above that of a single record.

  • Aggregations of records may reflect relationships such as shared characteristics or attributes, or the existence of sequential relationships between related records.

The act of raising an alert and sending it to users authorised to receive it.


A disposal alert is raised automatically by an MCRS, and sent to users authorised to receive it, whenever a record has become due for disposal, and has exceeded its subsequent confirmation period without receiving the necessary confirmation of disposal.

  • MoReq2010® allows each MCRS to implement its own alert technologies and solutions.

In a hierarchical structure, starting with a given entity, every other entity that can be reached by tracing only a unidirectional path from child entities to their parents.


A process of obscuring or concealing sensitive information so that the source cannot be determined.


Applications are any computer software.

  • They may include but are not restricted to products or information systems.

The layout and structure of an information system, particularly highlighting the design intent of each part, their different construction, and the relationships between them.


Giving a value to a metadata element, particularly by using it to associate one entity with another.


Form a relationship between two entities, for example, associating a record with an aggregation, usually by modifying the metadata of one or both to hold a reference to the other.


The concept that a particular unit of information should be managed holistically.

  • For example, a record is considered to be atomic even though it is made up of different entities, such as components.
  • The record is either wholly active or destroyed in its entirety, it cannot be partially destroyed.
  • Atomicity in MoReq2010® also extends to the way an MCRS performs functions.
  • They must be wholly performed, never partially performed.
  • This is important for maintaining internal consistency and stability, and when the MCRS is restored from backup
Audit trail

In a traditional business system, a centralised log of all, or significant, system activity.

  • An MCRS keeps a trail of its activities as a sequence of events, which may be viewed across the system as a whole, but are more commonly accessed as an event history for an individual entity.

Operation to check the identity of a user usually by asking the user for a previously agreed password.

Authorised user

An authenticated user with the authority to perform a function.


Having the ability to perform a particular function, especially with respect to a particular entity.

  • Authority is given to users by granting them roles in different parts of the system or in respect to different entities using an access control list.

An operation or function performed by the system in accordance with its own internal processing rules.

  • There is no user or manual intervention.
Automatic destruction

The content of a component of a record may be destroyed automatically when the record reaches its disposal action due date.

  • Whether or not the content is destroyed automatically or destroyed following disposal confirmation is determined by the nature of the content and the design of the MCRS.
  • All components have a flag indicating whether or not their content is to be destroyed automatically.

Go to top



To take a redundant copy of the data of an information system so that it may be restored following a system failure or disaster.


A redundant copy of the data of an information system held in secure storage so that it may be later used to restore the system, if required.


A value with only two possible states: true or false.

Boolean operator

An operator used to logically combine Boolean values so as to calculate a single result.

  • There are only three basic Boolean operators AND, OR and NOT from which all other Boolean operations can be derived.

Discover entities by exploring their relationships with other entities.

  • For example, starting from a record discovering its parent aggregation using the parent/child relationship, or by using other relationships discovering its components, class, disposal schedule, associated disposal holds, and so on.
  • (disambiguation) Browsing in an MCRS should not be confused with using a web browser.
Business activity

Activity carried out by a business so as to constitute or fulfil an overarching business function, this can include any of the areas of activity that an organisation might engage in, or be required to undertake by external regulatory or other controls.

  • "An analysis of business activity and processes will provide an understanding of the relationship between the organisation’s business and its records." (ISO 15489-2:2001, 3.2.3)
Business function

An area of business activity pursued by an organisation, usually related to the purpose or mission of the organisation and the execution of its business strategy and policies.

  • ISO 15489 describes business functions as supporting the pursuit of an organisation’s goals and strategies.
  • (ISO 15489-2:2001, (disambiguation) A business function used in classification should not be confused with performing a function.
Business system

Any information system used as part of conducting business.

  • For example, a financial management system.
Business transaction

A discrete stage or "constituent step" (ISO 15489-2:2001, in a business activity for which an evidential record is kept.

The record might include information related to:
- The business transaction that was undertaken;
- When it occurred; and
- Who participated.

Go to top



An activity leading up to the creation of a record in an MCRS.

  • Other terms may also be used for this, such as declaring a record.
  • Often this is dependent on the user’s perception as to whether the content of the record must be moved into a new storage facility (capture), or it can be made a record in place (declare).

The concept that a change to an entity will have an impact on its descendants.

  • For example, if the descendants of an root aggregation, both child aggregations and records, inherit their classification from their parent aggregation, then changing the root aggregation’s class will have a cascading effect from parent to child, resulting in all the descendants of the root aggregation being reclassified.

The act of formally acknowledging that a records system fully meets the requirements of MoReq2010® in respect to the core services and nominated modules.

  • Only the DLM Forum® may certify a records system, subject to testing by an accredited MoReq2010® test centre.

An entity that is part of a set of entities that belong and are subordinate to another parent entity.

  • A parent entity may have multiple children, but each child entity has only one parent.
  • The link between parent and child entities is known as a parent/child relationship.
Child aggregation

Any aggregation that is not a root aggregation.


A unit of classification that may be associated with an aggregation or a record.

  • In MoReq2010® classes always have a default disposal schedule which is inherited by any record they classify, in accordance with the principle from ISO 15489, that "Classification of business activities acts as a powerful tool to assist the conduct of business and in many of the processes involved in the management of records including .. .. Determining appropriate retention periods and disposal actions for records." (ISO 15489-1:2001, 9.5.1)

The act of associating a class from a classification scheme to an aggregation or record.

Classification scheme

Representation of the business functions, business activities and business transactions of the organisation as a set of discrete classes that can be associated with records and aggregations of records.

  • "Classification systems may be derived from analysis of business processes to ensure that the records and their metadata descriptions accurately represent the business processes that created them." (ISO 15489-2:2001,
Classification service

A logically separate service within an MCRS operationally responsible for maintaining class entities within a classification scheme.


When used in conjunction with a flag or Boolean value, meaning to assign it the value "false".


The function of closing an aggregation so that it can no longer accept additional children that may be moved or created in it.

  • A user cannot close an aggregation unless all of its child aggregations are also previously or simultaneously closed.

For aggregations, the state of having been closed.

  • A child aggregation or record may be moved out of a closed aggregation but no additional child aggregations or records may be moved or created in it.

A module for which additional requirements and consideration is necessary if it is implemented alongside another module.


A metadata element that can only hold one of a limited set of predefined values.


Where the metadata elements or properties of entities are arranged into tables, each row of the table usually contains the metadata of a single entity, while each column contains the values for each entity of a single metadata element.


An additional notation, usually provided by a user but sometimes constructed automatically, that provides explanatory and later historical detail to the purpose, motivation or outcome of taking a significant action.

Complex search

A search that is made by chaining together several search queries into a compound search query.

  • Complex searches are necessary because entities are related to one another with sometimes complex relationships.

Compliance is a non-functional aspect of a records system that assesses its suitability within a particular industry, or legislative jurisdiction, by assessing its support for and adoption of various standards and regulations.

  • Standards and regulations may apply to technologies, obligations, policies, rights, communication instruments, information formats and the processing rules implemented by a records system.

A part of a record that represents a discrete item of content.

  • For completeness a record including all its components and their content must be managed atomically.
Component content

The actual item of record, whether it be a physical object or a digital sequence.

  • All the other entities in an MCRS are purely representational, holding metadata related to, or extracted from, the content.
Confirmation period

The period between the disposal action due date and the disposal confirmation due date, in which a user must ensure that the disposal of a record has been carried out and confirm it with the MCRS.

  • The disposal of a record is frozen pending either its confirmation or cancellation
Contextual metadata

Metadata that is not mandated by MoReq2010® but is created within an MCRS in a local context to support the local business needs and operations of an organisation.

Contextual metadata element definition

The definition of a contextual metadata element.

  • Contextual metadata element definitions must be exported whenever contextual metadata is exported to ensure that an MCRS that imports the export data can interpret the metadata element and represent it correctly.
Core service

One of the nine services that is fundamental and necessary to an MCRS solution.


A product that can be installed and run in a variety of different environments with minimum of reconfiguration.

  • Common off-the-shelf
  • COTS products may be differentiated from other custom applications that are purpose built for a specific environment or situation.
  • MoReq2010® applies equally to both COTS products and individual site installations.

The function of adding a new entity to an MCRS.

Go to top



Any information stored in an electronic format or communicated electronically.

Data structure

Compound metadata consisting of more than one interrelated metadata element bound together into a structure to preserve their relationship to one another.

  • Data structures are part of entities in the same way as simple metadata elements. All data structures are provided as part of the MoReq2010® information model including the unique system identifier for each data structure.
  • For example, the system identifier for the data structure "Access Control List" is "60124baa-2625-4795-bf14- 7e67f2224ccf".

A dataset usually divided in to tables of entities of the same entity types.

  • The tables are often related together by storing identifiers in one column that refer to entities in another table.

A machine readable computer file containing data in any digital format.

  • The term "datafile" has been coined specifically for use in MoReq2010® to avoid any ambiguities with other terms used in records management
  • (disambiguation) The word "file" used in this context does not refer to an aggregation.

An XML datatype used to define the characteristics of metadata elements.

  • XML datatypes are used throughout MoReq2010® as this standardisation allows different MCRS solutions to share metadata element definitions.

A metadata element based on a day, month and year.

  • A date does not include time or time zone information and is therefore only accurate to within 24 hours.

A metadata value based on a date and a time of day that can be modified by users and is therefore not as precise as an automatically generated timestamp.

  • A date/time value does not include a time zone.

The practice of not storing or transmitting the same data more than once.

  • De-duplication is of most importance to the MoReq2010® export process.
  • When a number of entities are exported they may share data in common, for example the class of a record.
  • If several records with the same class are exported together, then the class information will only be exported once.

A related term to capture that describes the user action that may precede the creation of a record in an MCRS.


An entity or value that is used whenever a replacement is not explicitly specified.

  • For example, a record has a default class (inherited from its parent aggregation) unless it is overridden by applying a different classification directly to the record itself.
Default classification

The class of a child aggregation or record that it automatically inherits from its parent, unless it is overridden.

Default disposal schedule

The disposal schedule of a record that it automatically inherits from its class, unless it is overridden.

Default language identifier

The language identifier that is used for a textual metadata element unless a different language is specified when the metadata element is given a value.


Erase data, especially an entity, from an MCRS so that no trace remains.

  • MoReq2010® only permits entities to be deleted if they have not been used.
  • Once an entity has been used then it cannot be deleted and must be destroyed, leaving a residual entity.
  • There is an important distinction made between deleting an entity and destroying an entity.

In a hierarchical structure, starting with a given entity, every other entity that can be reached by tracing all possible unidirectional paths from parent entities to their children.


Optional extended information describing an entity.


A managed process where active entities are made into a residual entities through the controlled deletion of:
- Some of their metadata
- Some of the events from their event histories, and
- For records, their content.

  • There is an important distinction made between destroying an entity and deleting an entity.
Detailed report

A report based on a search query that lists entities and their metadata, usually as a table.


An external business system common to modern organisational environments that maintains lists of users and groups and related metadata.

  • Directories are intended deployed as a central resource allowing other business systems, including records systems, to interface to them and reuse this information.
  • Common protocols include X.500 and LDAP.
  • Directories do not typically keep good historical information about users and their group memberships and an MCRS has additional responsibilities to ensure that it is preserved where an external directory is used.

Individual, clearly discernable as being logically or physically separated from other entities or units of information.

Disposal action

An action that is taken to dispose of a record in response to the record’s disposal schedule.

  • Where a record is not retained permanently there are only three possible disposal actions:
    • Review,
    • Transfer, and
    • Destroy.
Disposal action due date

The date, marking the end of the retention period, when a disposal action should be carried out on a record in accordance with its disposal schedule.

Disposal cancellation

Where a disposal action of transfer or destroy requires confirmation, it may be cancelled rather than being confirmed.

  • Cancelling a disposal action involves assigning a new disposal schedule to the record.
Disposal completion

A disposal action of review must be completed.

  • Reviewing a record involves assigning it a new disposal schedule, as part of a review decision.
Disposal confirmation

The disposal actions of transferring and destroying records must be confirmed by a user, except where records have components that are subject to automatic destruction.

  • The user is confirming that the transfer was successful or that the content of the records has actually been destroyed.
Disposal confirmation due date

The date, marking the end of the confirmation period, by which a disposal action requiring confirmation should have been carried out and confirmed by a user.

  • If the disposal action is not confirmed by this date then the MCRS will raise an alert.
Disposal hold

A legal or other administrative order preventing the destruction of records.

  • Despite their name, disposal holds do not prevent the review or transfer of records, however they do prevent them being destroyed by changing their disposal action to retain on hold.
  • Disposal holds may be applied to whole classes and whole aggregations, as well as to individual records.
Disposal holding service

A logically separate service within an MCRS operationally responsible for managing disposal holds.

Disposal process

The process by which a record is updated and managed, by checking for changes to its disposal schedule and retention trigger, calculating its retention period, and applying disposal actions when they are due.

Disposal schedule

A schedule detailing the lifecycle of a record and detailing:
- The retention trigger (used to determine the retention start date);
- The retention period;
- The disposal action; and
- The confirmation period.

Disposal scheduling service

A logically separate service within an MCRS operationally responsible for managing disposal schedules.


An entity that is an exact copy of another entity.

  • MoReq2010® allows records, and their events and components to be duplicated, so as to allow for example a duplicate of the same record to be placed into two different aggregations.
  • Each duplicate will then follow its own separate lifecycle.

The function of duplicating a record.

Go to top



Having a purely digital representation that is stored and transmitted electronically.


Entities represent individual and discrete units of information within an information system.

  • In an MCRS each entity must be of a particular entity type and has some or all of the following:
    • System metadata;
    • Contextual metadata;
    • Access control list;
    • Event history;
    • The system metadata,
  • and sometimes
    • the contextual metadata,
    • link the entity to other entities,
    • forming relationships.
Entity relationship diagram

A technique for modelling relationships between units of data when describing an information system.

  • (disambiguation) The "entities" and "relationships" in an entity relationship diagram are not necessarily the same as entities and relationships as defined by MoReq2010®.
Entity sub-type

A specialised derivation of an entity type that may exhibit different behaviours, and have additional metadata elements and functions.

  • For example, a contextual metadata element definition is a sub- type of a metadata element definition.
  • MoReq2010® is fully extensible, allowing for additional entity types and entity sub-types to be introduced, as required.
Entity type

A definition of an entity.

  • The following entity types appear in the MoReq2010® core services:
    - Aggregations,
    - Classes,
    - Components,
    - Disposal Holds,
    - Disposal Schedules,
    - Entity Types,
    - Events,
    - Function Definitions,
    - Groups,
    - Metadata Element Definitions,
    - Records,
    - Roles,
    - Templates, and
    - Users.
  • All entity types and sub-types are provided as part of the MoReq2010® information model including the unique system identifier for each.
  • For example, the system identifier for the entity type "Record" is "3ac228ef-c008-4524-9e41-5c4564eaa7f0".

A fault in a computer program or application which prevents the successful completion of a function.

Error log

A log of errors that that have occurred within the MCRS.

  • The error log is maintained externally to the MCRS and contains details and extended error information for every error.
  • The error log is held externally for diagnostic reasons, to allow it to be accessed even when the MCRS has crashed or fails to start.

An entity that is generated by performing a function. The event preserves metadata about:
- The function that was performed,
- When it was performed,
- Who performed it,
- The participating entities,
- What metadata was changed, and may include
- An event comment.

Event comment

A comment that is included in an event to provide more detail about the event.

Event history

All of the events in which a particular entity has participated.

  • An MCRS maintains an event history for all entities in accordance with the principle expressed in ISO 15489 that: "Records systems should contain complete and accurate representations of all transactions that occur in relation to a particular record.
  • These include the processes associated with individual records." (ISO 15489-1:2001, 8.3.2)

Having weight as evidence, especially in a legal sense.

  • Part of the reason for using an MCRS is to enhance the evidential value of an organisation’s records because of the manner in which they can be shown to have been managed.

The export data produced as a result of exporting entities in the MoReq2010® export data format.


A function performed by a user where one or more entities, and their related entities, are output as XML data, either exported in full or as placeholders.

Export comment

A comment provided by the user who performs an export, which is subsequently included in the export data and in the event comment generated by the export.

Export data

A datafile output from an MCRS containing an export and in the MoReq2010® export data format.

Export data format

A specific XML data format designed to accompany MoReq2010® which provides a valid schema for the export of all entities.

Export identifier

An MCRS must generate a unique identifier, called the export identifier, for each export.

  • This is included in the export data and in the events generated by the export, to show which entities were exported in full or as placeholders.
Export placeholder

When an entity is exported as an export placeholder, then its system metadata, access control list and significant entities are all exported with it, but not its contextual metadata, included entities or event history.

Export process

The process by which entities are exported from an MCRS.

  • The export process involves:
    - Assembling the entities to export,
    - Determining whether they are to be exported in full or as placeholders,
    - De-duplication, and
    - Performing the export operation.
Export service

A logically separate service within an MCRS operationally responsible for undertaking the export process and managing exports.

Exported in full

When an entity is exported in full, then its system metadata, contextual metadata, access control list, included entities, significant entities and event history are all exported with it.

Extended error information

Detailed diagnostic information about why a particular error occurred.

Extension module

An extension to the requirements of MoReq2010® developed by the MoReq Governance Board and issued by the DLM Forum®.

  • An extension module may contain:
    - Key concepts,
    - Functional requirements,
    - Non-functional requirements,
    - New glossary terms, and
    - Extensions to the information model.
  • Each extension module also has its own test cases andcan be tested and certified independently of the core services, provided the MCRS has already been certified as MoReq2010® compliant.
  • Extension modules are used to flexibly add additional capabilities to the core services in relation to particular technologies, industries and compliance standards.

Operating autonomously outside the control of the MCRS with separate data storage that is not managed by the MCRS.

Go to top


First day of the week

The day on which a week is considered to begin, used when searching and reporting.

  • For example, the search query, "Find records with a disposal action due date next week" could have different results depending on when "next week" nominally begins and ends.
  • Traditionally the first day of the week is Sunday, but many organisations use Monday since it usually represents the first day of a working week.
First used

The lifecycle concept used throughout the specification that an entity can be created, modified and deleted up until the moment when it is first associated with another entity.

  • After first use, some metadata will become permanent and the entity must be destroyed, rather than being deleted, leaving a residual entity.
  • The concept of first use is not applicable to certain specified entities, such as records, components, and events, as well as the entity types, system metadata element definitions and function definitions defined by MoReq2010®.
First used timestamp

A timestamp applied to an entity when it is first used.

Fixed role

A built-in role that is part of the design of an MCRS and cannot be modified, deleted or destroyed.

  • Some products are supplied with certain roles pre-defined by the supplier.

A metadata element based on a Boolean value that can only be "true" or "false".

  • Changing the value to "true" is described as setting the flag while changing the value to "false" is described as clearing the flag.

A technique for modelling processes in an information system.

Full text searching

A technique of searching on text using whole words, rather than pattern matching.

  • Full text searching is particularly relevant to textual information, and is enhanced by knowledge of the particular language in which the text is composed.
  • This, for example, enables the search engine to ignore prefixes and suffixes (known as "word stemming"), to search for synonyms, and to place a relative importance on different words in a phrase.
  • Full text searching is "fuzzy" and most search engines place a weighting on different results that orders them by best fit to the search criteria.
  • This weighting is called a relevancy score.

A pre-defined operation involving one or more participating entities that a user performs.

  • Each function has an expected pecified by MoReq2010®.
  • Functions are closely nts which specify the function should not be confused with a business function used in classification.
Function definition

A definition of a function that is represented as an entity.

  • Function definitions are used for both access control and in events that are generated by performing functions.
  • For access control, function definitions are included in roles which are then granted to users and groups.
  • To perform a function a user must have been granted a role that includes its function definition.
  • When events are generated the function definition of the function that was performed is included in the event.
  • All function definitions are provided as part of the MoReq2010® information model including the unique system identifier for each function.
  • For example, the system identifier for the function "Group – Remove User" is "c3713f12-feb6-459e-a21a-7e63aaeeea6c".
Functional requirement

A requirement stating what an MCRS must do.

  • Functional requirements may be tested to determine whether a particular MCRS is compliant with MoReq2010®.

Go to top



Automatic creation of entities, such as events, and other information by an MCRS.

Good practice

Accepted ways of working that experience shows produce above average outcomes, especially in relation to a discipline such as records management.


Award a role to a user or group.

  • Granting a role will update the access control list belonging to an entity or service and add or modify an access control entry.

An entity that usually represents a team or business unit within the organisation, and has various user entities as members.

Go to top



Comprising entities that are different according to some fundamental characteristic.

  • MoReq2010® uses this term to refer to aggregations that contain records where the records are classified using different classes.

Structured using parent/child relationships so that each entity may be either a parent entity, or a child entity or both.

  • Hierarchies are connected, so that every entity must be included by having at least one parent/child relationship with another entity, and non-cyclical so that no entity may be the ancestor (or descendant) of itself.

Comprising entities that are the same or similar according to some fundamental characteristic.

  • MoReq2010® uses this term to refer to aggregations that contain records where the records have all have the same class which is inherited from their parent aggregation.

Go to top



Interpreting and encoding the requirements of MoReq2010® into an application.

  • To implement the specification, suppliers must build the requirements into an implementation.

An application that implements the requirements of MoReq2010®.


Reconstitution of facsimiles of the entities that have been exported from one MCRS in another different MCRS by input of XML data in the MoReq2010® export data format.


Unable to be inspected because the user does not have access to the entity.

Included entity

Some entities include other entities.

  • When they are exported in full their included entities must also be exported in full.
  • For example, an aggregation includes its child aggregations and records, and a record includes its components.
  • If an aggregation is exported in full then all of its descendants will be exported in full as well, and the components of any records that are descendants of the aggregation will also be exported.

Facts known to a person or organisation.

  • Where information provides evidence of an organisation’s business activities or transactions it should be captured as a record. An organisation’s records may therefore be described as a sub-set of the information available to that organisation.
  • Information may be managed by an information system and records may be managed by a specialised type of information system known as a records system.
  • A records system implements particular functionality that makes it suitable for records management.
Information model

A structured functional and metadata model that underlies all of MoReq2010® and maps every entity, metadata element and function to one another.

  • Strict observance of the information model is critical in ensuring that the export data from different MCRS solutions is fully compatible.
Information system

An integrated set of components for collecting, storing, processing, and communicating information.

  • The main components of information systems are computer hardware and software, databases, telecommunications systems, human resources, and procedures.

The adoption by one entity of the characteristics or properties of another entity by association with it.

  • Inheritance usually takes place through the parent/child relationship, but not in all cases.
  • For example, a record inherits its default disposal schedule from its class.
  • The principle of inheritance is used in MoReq2010® in the following main areas:
    - Access control,
    - Classification,
    - Disposal schedules,
    - Disposal holds, and
    - Export.

Examine an entity and its metadata.

  • Access to the inspect function is fundamental for discovery.
  • If a user is not able to inspect an entity then it is considered inaccessible and there must not be any indication of the entity provided to the user by the MCRS while browsing, searching or in any other way.

Initialise an instance of an MCRS by setting up and configuring the necessary hardware and software.


Interfacing to and interoperating with another business system.

  • Tight integration implies close cooperation.

The part of an information system that offers up its functionality to users and/or other systems.

  • By interacting with the interface of an MCRS, a user is able to perform functions.

The ability for one system to be able to operate using the data and information provided by another system.

  • Specifically in MoReq2010® interoperability between records systems is defined as the ability of a source system to export its entities and of a destination system to import and represent them as complete and fully functional entities alongside its own.

Go to top



A human language.

  • Languages are specified in MoReq2010® using language identifiers.
Language identifier

MoReq2010® language identifiers must be compliant with RFC5646 and the IANA Language Subtag Registry.

Last reviewed timestamp

System set date and time of the last review.

  • The last reviewed timestamp is useful when considering the last review comment to see how long ago the assessment was made.

The depth of a hierarchical structure as measured by counting the number of entities from the common ancestor of all entities in the hierarchy, tracing from parent to child to its furthest descendant, where the furthest descendant has the most intervening parent/child relationships.


Every entity in an MCRS has a pre-determined lifecycle which begins with the creation of the entity and has various phases depending on its entity type.

  • An entity is initially active until it is destroyed, when it becomes a residual entity

Term used to describe the removal of a disposal hold from a class, aggregation or record.

  • When a disposal hold is destroyed then it is immediately lifted.

Customising an individual instance of an MCRS to meet local requirements.

  • This can be done in many different ways.
  • Using different languages, creating specific roles, constructing an organisational classification scheme, defining contextual metadata elements, using different titles and descriptions for entity types and function definitions are all aspects of localisation.

Conceptually different.

  • For an example, a service may be logically differentiated within an MCRS from other services, while in reality they all remain part of the same codebase, or two different components may have the same content but use pointers to make it appear as if they have different content, thereby satisfying the principle of discreteness.

When used in the context of interoperability, or export and import, refers to the idea that important contextual information is not lost during transfer.


When used in the context of interoperability, or export and import, indicates that some contextual information, such as metadata, events, access control lists or relationships with other entities is lost during transfer.

Go to top


Major version

A major version represents a change to the information model, such as the addition of new functions or system metadata elements, that makes an MCRS that only implements one major version, incompatible with an MCRS that only implements another.

Manage in place

The management of records with components whose content is located in another external information system.


The legal or other instrument that provides the procedural authority for a disposal schedule or a disposal hold


An operation or function performed by a user, especially when contrasted with one performed automatically by the MCRS in accordance with its own processing rules.

  • It is important to note that a user may be another business system. As a result a "manual" function or operation may not necessarily be performed by a human.
Max levels of aggregation

The number of levels of aggregation allowed below a given root aggregation.

  • If max levels of aggregation is assigned a value of zero then no child aggregations can be added below the root.

A records system which is fully compliant with the core services of MoReq2010® and may also be fully compliant with one or more modules.

  • MoReq2010® compliant records system
  • A MoReq2010® compliant records system is usually referred to as an MCRS.
  • To provide surety that an MCRS is fully compliant with MoReq2010®, it should be tested and certified by the DLM Forum®.
MCRS certification identifier

A universally unique identifier issued by the DLM Forum® upon the award of a MoReq2010® certificate of compliance.

  • The MCRS certification identifier is used to report the compliance status of an MCRS.

Information about an entity made up of several metadata elements.

Metadata change entry.

A data structure included in an event whenever one or more metadata elements were modified by the event.

  • Each metadata change entry contains the value of a metadata element both before and after it was modified.
Metadata element

An item of metadata described by a metadata element definition that has zero or more values given to it by users and by the MCRS.

Metadata element definition

A definition of a metadata element that indicates, among other properties, its:
- Title - the name of the metadata element;
- Datatype - what type of metadata it may contain;
- Cardinality - how many values it may have; as well as - Whether these values may be changed by a user.

Metadata service

A logically separate service within an MCRS operationally responsible for managing metadata element definitions and metadata templates.


A variant of transfer where the intention is to move all or a substantive number of often active entities from one records system to a new MCRS allowing them to be managed by a new owner, in a new environment, or by a new technology or solution.

  • Usually the purpose of migration is to decommission the previous records system.
  • Sometimes the source is not a MoReq2010® compliant records system and the migration is a singular exercise intended to rearrange the older records into the export data format used by MoReq2010®.
  • Once they have been migrated into an MCRS, the entities can be transferred on again in the future, losslessly.
Minor version

A minor version represents a change to the service or module that introduces a clarification, correction or additional non-functional requirement without changing the underlying information model.

Model metadata service

The MoReq2010® preferred implementation of the role service.

Model service

A service defined by the MoReq2010® specification, that may be replaced in operation by a functionally similar service, with a different set of processing rules, that has been defined for a particular MCRS solution.

  • To use a replacement service for a model service, an MCRS must have been tested to ensure a close match in overall functionality, and it must be able to export its own proprietary data structures to the MoReq2010® export data format.

Indication of whether or not a user may modify a particular metadata element.

  • A metadata element that cannot be modified is said to be "read only".

Assign a new value to a metadata element, or change or delete a previous value.

Module identifier

A universally unique identifier provided by the DLM Forum® that is used in compliance reporting by an MCRS to indicate that it implements a particular major version of a module of MoReq2010®.


Used in the context of an aggregation to indicate the removal of a child entity or record from one aggregation and its addition to another aggregation.

  • An aggregation can be moved to become a root aggregation or moved from a root aggregation to become a child aggregation.
  • Records must always belong to an aggregation.

In respect of a records system, one that is shared by a number of different organisations such that each organisation has its own part of the records system and does not have access to the records and other entities belonging to other organisations.

Go to top


Native metadata model

The metadata model of an MCRS that does not use the model metadata service.

  • A native metadata model will usually not be compatible with the metadata model of an MCRS from a different supplier.
Native permissions model

The role model of an MCRS that does not use the model role service.

  • A native permissions model will usually not be compatible with the role model, or native permissions model, of an MCRS from a different supplier.

In relation to entities, the entity or entities that have been chosen or selected by the user.

Non-administrative role

A role that is only inherited when it is included by the access control list of a child entity.

  • Non-administrative roles may be specifically excluded from being inherited.
  • Administrative roles may never be blocked.
Non-compliant system

A records system that is not MoReq2010® compliant, specifically one that has not been certified by the DLM Forum®.


A qualitative aspect or assessment, as distinct from taking a purely functional perspective.

Non-functional requirement

An important requirement of a system that is not expressed as a particular function that the system must perform.

  • Non-functional requirements assess not what a system does but how well it does it.
  • This includes a qualitative assessment of the following principles:
    - Performance,
    - Scalability,
    - Manageability,
    - Portability,
    - Security,
    - Privacy,
    - Usability,
    - Accessibility,
    - Availability,
    - Reliability,
    - Recoverability,
    - Maintainability,
    - Supported,
    - Warranted, and
    - Compliance

Go to top



For aggregations, a state allowing new child aggregations or records to be created in the aggregation, or existing aggregations and records to be moved to it.


The function of opening a closed aggregation so that it can accept additional children that may be moved or created in it.


Any action generally taken by an MCRS in response to an internal processing rule or an external stimulus.

  • A function is a specialised form of operation which is usually (though not exclusively) initiated by a user, involves one or more participating entities, and may result in an event being generated.
Organisational quarter

A quarter, consisting of a three month period, in an organisational year.

Organisational year

Many organisations have a financial or administrative year consisting of four quarters, each of three months, that is not aligned with the calendar year.

Originated Date/Time

The date and time from which an entity originates.

  • By default, MoReq2010® uses the date and time on which the entity was created in the MCRS, however the entity’s actual originated date/time may be earlier than this.

Provide an explicit replacement for a default entity or value, especially with respect to overriding the inherited classification of an aggregation or record, or overriding the default disposal schedule for a record, derived from its class.

Go to top



Specifically with respect to search results, to divide a large set of search results up into smaller subsets that are returned individually to the user performing the search.


An entity, in a hierarchical structure, that has one or more child entities.

  • The link between parent and child entities is known as a parent/child relationship.
Parent aggregation

An aggregation that contains either child aggregations or records.

Parent/child relationship

The relationship between a parent and a child in a hierarchical structure.

  • In MoReq2010® this relationship is established by storing a reference to the parent as part of the metadata of the child entity.
Participating entity

An entity that is considered to have participated in an event, or for which the event is important.

  • The event forms a part of the event history of every participating entity.

To carry out or execute a function in relation to one or more entities.


Having a physical or real world presence.

  • For example, a record that has content consisting of paper with writing on it, as compared to a record with electronic content.
Plug-in module

A module of MoReq2010® that plugs into the core services and provides specialised functionality in a particular area.

  • Plug-in modules are organised into series and to be compliant each MCRS must implement at least one plug-in module from each series.
  • An MCRS may implement more than one plug-in module from the same series.

A technique for implementing the principle of discreteness in a logical, rather than a physical, way.

  • For example, assuming two different records have components that both contain the same content.
  • Rather than keep two copies of the content, the MCRS keeps two pointers to the content and a counter of the number of components that point to the same content.
  • When the first component is destroyed its pointer is deleted and the pointer counter is decremented from two to one.
  • When the second component is destroyed it pointer is also deleted and as the pointer counter decrements to zero, the content is also deleted.
Preconfigured role

A role, like a fixed role, that has been pre-defined by the supplier of an MCRS solution to allow its configuration.

  • Unlike a fixed role, a preconfigured role may be later modified or destroyed.

A module which must be implemented before the nominated module is able to be implemented.

  • Used to indicate that one module of MoReq2010® is reliant on the functionality of another also being implemented by the MCRS.
Presentation order

A user specified order in which items should appear, specifically the order in which metadata elements should be presented when an entity is inspected.

Principle of a system being supported

A non-functional aspect of a records system, a supported system is one that is being actively maintained and upgraded by the supplier and for which there exists an operational support facility for reporting issues and receiving information about new releases and software fixes.

Principle of a system being warranted

A non-functional aspect of a records system, a warranted system is one which is issued with a warrant from the supplier covering its use.

Principle of accessibility

A non-functional aspect of an information system that describes the extent to which it supports users with different capabilities and learning rates, including those with specific disabilities.

Principle of authenticity

Along with integrity, reliability and usability, one of the central characteristics of a record according to ISO 15489.

  • An authentic record is one that can be proven to be what it purports to be.
Principle of availability

A non-functional aspect of an information system that describes the period during which the system is fully operational and stable, especially by contrast with how long the system spends partially operational or offline.

  • This is sometimes expressed as a ratio or percentage.
Principle of completeness

When applied to the component of a record ensures that collectively the content of the record comprises a whole record ensuring the integrity of the record.

Principle of destructibility

When applied to the component of a record, ensures that the content of the record can be permanently destroyed as a result of undertaking the disposal process in response to the record’s disposal schedule.

Principle of discreteness

When applied to the component of a record, ensures that the content of the component is a single item that is separately identifiable from the content of other components and records.

Principle of immutability

When applied to the component of a record, ensures that the content of the component remains unaltered.

  • Once the record has been created the content of its components must not change over time.
Principle of integrity

Along with authenticity, reliability and usability, one of the central characteristics of a record according to ISO 15489.

  • "The integrity of a record refers to its being completed and unaltered." (ISO 15489-1:2001, 7.2.4)
Principle of maintainability

A non-functional aspect of a records system that describes how relatively easy a given application or site installation is to maintain an upgrade.

  • A system is considered less maintainable if it is difficult to service, must be taken offline for a significant period to apply upgrades and patches, or requires costly expenditure on third-party support or maintenance contracts.
Principle of manageability

A non-functional aspect of a records system that refers to how it is managed and administered.

  • The technical administrator’s task is to ensure the records system remains operational, while the records manager is charged with ensuring the records system is used effectively.
Principle of performance

A non-functional aspect of a records system concerned with the speed and efficiency of processing.

Principle of portability

A non-functional aspect of a records system that assesses the extent to which the system can be deployed onto different platforms, devices, and operating environments.

Principle of privacy

A non-functional aspect of a records system, privacy is concerned with the degree to which the system supports the principles of data protection as well as the broader issue of handling any form of sensitive information.

Principle of recoverability

Non-functional aspect of a records system that assesses its ability to recover from a system failure or disaster.

Principle of reliability

Along with authenticity, integrity and usability, one of the central characteristics of a record according to ISO 15489.

  • "A reliable record is one whose contents can be trusted as a full and accurate representation of the transactions, activities or facts to which they attest..." (ISO 15489-1:2001, 7.2.3)
Principle of reliability

Reliability is also a non-functional aspect of a records system, and when used in this sense it refers to the resilience of the system as a whole, and is often measured as the "mean time between failures".

Principle of scalability

A non-functional aspect of a records system that assesses the extent to which it can grow to support increased capacity without requiring replacement or extensive reconfiguration.

  • Systems typically need to be scaled as a result of organisational expansion, , peak usage and/or the regular accumulation ted entities over time.
Principle of security

A non-functional aspect of a records system referring to, and measuring, its integrity and its ability to withstand unauthorised access.

Principle of usability

Usability is also a non-functional aspect of a records system, and when used in this sense it refers to the system as a whole and the quality of the user experience, including how difficult it is to learn, and its ease of operation in day to day use.

Principle of usability

and reliability, one of the central characteristics of a record according to ISO 15489.

  • "A usable record is one that can be located, retrieved, presented and interpreted." (ISO 15489-1:2001, 7.2.5)

A step-by-step workflow described by MoReq2010® that should be implemented by all MCRS solutions in the same way, so that it will reliably produce the same outcomes each time it is performed.

  • The most important processes described by MoReq2010® are the disposal process and the export process.

COTS software, usually licensed from a supplier, that can be installed as a standalone application to provide an implementation of an MCRS.


An implementation that is specific to a particular product from a particular supplier and is incompatible with other records system implementations from other suppliers.

  • One of the primary design goals of MoReq2010® is to avoid incompatible proprietary records systems that are not fully interoperable.

Go to top



To change the classification of an aggregation or record.

  • Reclassification may occur as a result of overriding the default classification or, where the aggregation or record inherits its class, it may occur as a result of reclassifying a parent or ancestor entity.

Any "information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business"

  • In MoReq2010® a record may be further characterised as follows:
    - It has an extensible set of metadata that describe it;
    - It has one or more components that represent its content;
    - It is classified with a business classification;
    - It has a disposal schedule that describes explicitly if, how and when it willbe disposed of or destroyed;
    - It belongs to an aggregation of records;
    - Access to it is controlled and limited to authorised users;
    - Its destruction may be prevented by a disposal hold; and
    - It may be exported to another MCRS while retaining all of the characteristics listed above.
Record service

A logically separate service within an MCRS operationally responsible for managing aggregations, records and their components.

Records Management

The field of management responsible for the efficient and systematic control of the creation, receipt, maintenance, use and disposition of records, including processes for capturing and maintaining evidence of, and information about, business activities and transactions in the form of records.

Records system

An information system which captures, manages and provides access to records through time.

  • A MoReq2010® compliant records system delivers the functionality of a records system in a standardised way through its implementation of a set of core services, defined by the MoReq2010® specification, which may be further extended, adapted and localised through additional modules.

To cope with a system failure or disaster by replacing damaged hardware and software, and restoring the system’s data to bring it back to a previously known and stable state.


Specifically in the context of relationships between entities and the metadata of an entity, a metadata element is said to contain a reference when its whole purpose is to store the unique system identifier of another entity.

  • Relationships between entities are realised by one entity referencing the other.
  • If a user is authorised to inspect both entities then the MCRS must allow the user to browse the relationship, from one to the other, in either direction. (disambiguation) MoReq2010® also uses the term "reference" in its more general sense.
  • For example, most functional requirements have a "function reference" which is simply an index to the information model that allows the reader to look up the function definition matching the requirement.
Relevancy score

The, usually proprietary, weighting given to a full text search that allows more relevant results to be returned first.


The function of disassociating an entity from a set of entities, usually for the purpose of moving it elsewhere.

  • For example, removing a record from its parent aggregation so as to move it to a new parent aggregation.

The function of generating a report.


The structured assembly of information, using a preconfigured outline, in response to a specific enquiry or a more general enquiry, such as a search query.

  • Searching and reporting are closely related activities and often overlap.
  • A search that is subsequently made into a report is sometimes called an ad hoc report.
  • Traditionally a report has a report format that enables it to be stored as electronic content and potentially to be declared as a record itself.
  • MoReq2010® requires an MCRS to be able to provide both specific reports, in response to some functional requirements, and two types of general report: a detailed report and a summary report.
Reporting format

A common and widely recognised format for a report, such as:
- Comma or tab separated values;
- Spreadsheet formats, such as OOXML and ODF;
- XML and HTML based formats; and
- PDF or other document formats.


To prevent the further use of a role that was previously granted to a user or group.

  • Rescinding a role will update the access control list belonging to an entity or service and delete or modify an access control entry.
Residual entity

An entity that has been destroyed.

  • A residual entity is no longer active and upon its destruction it may have been pruned of some of its metadata and some of the events from its event history.

To recover an information system to a previously known and stable state using a backup following a system failure or disaster.


Keep a record in the MCRS and ensure that it is not deleted or destroyed.

Retain on hold

Retain a record and prevent its destruction for the duration of a disposal hold.

Retain permanently

Retain a record indefinitely and prevent its destruction unless or until it is given a different disposal schedule.

Retention period

The period of time that a record is retained from its retention start date, initiated by its retention trigger, until its disposal due date, marking the end of the retention period.

Retention start date

The date on which the conditions of the retention trigger in the record’s disposal schedule are met and the retention period begins.

Retention trigger

One of a number of possible conditions that may cause a record’s retention period to commence.

  • Each disposal schedule lists a retention trigger.
  • For example, a record’s retention trigger may be the date it was added to its parent aggregation.

The function of assessing a record that is due for review and determining what disposal schedule to apply to it.

  • An authorised user may complete a review by applying a new disposal schedule to the record and entering a review comment describing the review
Review decision

The decision made by the reviewer of a record when completing a review.


An entity representing a set of function definitions.

  • Granting a role to a user or group in relation to an entity, enables that user or any member of that group to perform that role on the entity and its descendants.
  • Roles are generally constructed to mirror the tasks of a staff member filling a particular position within the organisation.
  • For example, different roles may be constructed around each of the following usage types:
    - Office clerk,
    - Local records officer,
    - Senior records manager,
    - Personnel manager,
    - Sales representative,
    - Auditor,
    - External contractor,
    - Guest or office temp,
    - Executive personal assistant,
    - Senior executive officer,
    - And so on.
Role service

A logically separate service within an MCRS operationally responsible for managing roles.

Root aggregation

An aggregation that is not a child of another aggregation.

  • Each root aggregation is created directly under the record service.
Root aggregation

An aggregation that is not a child of another aggregation.

  • Each root aggregation is created directly under the record service.

Where the metadata elements or properties of entities are arranged into tables, each row of the table usually contains the metadata of a single entity, while each column contains the values for each entity of a single metadata element.

Go to top


Saved report

A report where the report format and search query used are saved by the MCRS and stored so the saved report may be shared with other users and generated again, as required.

  • A saved report is not an entity.
  • (disambiguation) A "saved report" refers to the saving of the report definition, not the report results.
Saved search

A search query which is saved so that it can be shared with other users, run again when required, and used as the basis of further searches.

  • A saved search is not an entity.
  • (disambiguation) A saved "search refers" to the saving of the search query, not the search results.
Scheduled activity

A planned process or routine carried out by an information system at regular intervals; particularly a resource intensive operation that is scheduled for a time of the day or week when usage of the system is low.

Scope notes

Guidance notes indicating how best to apply a particular entity and stating any organisational policies or constraints on its use.

  • For example, a class may have scope notes indicating which records the class should be applied to and which ted for classification under that aggregations, classes, disposal edules and contextual metadata elements.

Discover entities by specifying search criteria that partially or fully match the values of their metadata elements.

Search criteria

Individual conditions included in a search query.

  • Each search query will be made up of one or more search criteria.
  • Each search criterion is made up of metadata elements to search on, search operators and search terms.
Search description

A description of a search query that is included in an event so as to retain evidence of the search that was performed.

  • The search description may be in natural language or in a structured expression language.
Search engine

The heart of the MCRS solution’s searching and reporting service.

  • A search engine will typically index the metadata in the MCRS, apply the search criteria, execute and evaluate the search, and assemble and sort the search results.
  • Different search engines may be more or less sophisticated in the functionality they offer.
  • As search engines are often highly specialised, like databases, some suppliers will make use of third-party search engines in their MCRS solutions.
Search term

A part of a search criterion that holds a value that can be compared or searched on.

Searching and reporting service

A logically separate service within an MCRS that is, or is integrated with, a search engine and performs searches and generates reports for authorised users.


A unit of information is secure when only authorised users may access it and manipulate it.

  • In an MCRS, internal security is provided by access controls while external security is assessed under the non-functional principle of security.
Sentencing on creation

The general principle that the context of a record is best captured when the record is first created, and that this context should be used to govern the record’s disposal.

  • In MoReq2010®, the principle of "sentencing on creation" is embodied by the functionality required of the MCRS, where every record created must be classified and every class has a default disposal schedule associated with it.

A logical subset of the total functionality of an MCRS that focuses on managing only one or a small group of entity types.

  • For example, the disposal scheduling service only manages disposal schedules.
Service based architecture

An architecture adopted within the specification where functional requirements within the core of MoReq2010® are separated into discrete services.

  • Each service represents a bundle of functionality that could theoretically be undertaken by a separate application.
  • Dividing the core in this way helps to introduce the key concepts in a logical order, but it also points towards the future where one MCRS mayhave two services of the same type, such as two different classification services for different types of record or aggregation, or may share a service, such as its metadata service, with another MCRS.
Service identifier

A universally unique identifier provided by the DLM Forum® that is used in compliance reporting by an MCRS to indicate that it implements a particular major version of a core service of


When used in conjunction with a flag or Boolean value, meaning to assign it the value "true".


MoReq2010® also uses the term "set" as a collective noun to refer to groupings of entities.

Significant entity

An entity that is particularly important to another entity and must therefore always be exported with it as a placeholder, whenever it is exported.

  • For example, a record’s class is a significant entity to the record.
  • The record cannot be exported in full or as a placeholder without its class also being exported as a placeholder.

A representation of any data or unit of information, but especially an active entity and its metadata, frozen at a particular moment in time.

Summary report.

A report based on statistics rather than individual line items


The manufacturer or developer of a records system, or a body that holds some or all of the intellectual property rights, or a supplier’s representative, such as a reseller or service integrator.

System identifier

A universally unique identifier generated by the system for an entity or other purpose, such as an export identifier.

  • Some system identifiers are provided by MoReq2010®, including service identifiers, module identifiers, entity type identifiers, data structure identifiers, system metadata element definition identifiers and function definition identifiers.
System metadata

Metadata that is mandated by MoReq2010® and is predefined by the specification which includes the system metadata element definitions and their system identifiers.

  • Each entity type has its own set of system metadata associated with it.
System metadata element definition

A metadata element definition for a system metadata element.

  • All system metadata element definitions are provided as part of the MoReq2010® information model including the unique system identifier for each.
  • For example, the system identifier for the system metadata element "Title" is "077fc367-48ba-44a8-8afb-012d05ed1a16".

Go to top



An actual or conceptual laying out of the metadata of entities into rows and columns.

  • This layout is most successful when all of the entities in a table have the same metadata elements or properties, which usually means that they are of the same entity type.

A representation of a set of contextual metadata element definitions that can be applied to an entity.

  • Whenever a template is applied, each of the contextual metadata elements is instantiated and associated with the entity.

The activity of proving the correctness of software by performing functions and comparing the results to expected outcomes.

Specifically for MoReq2010®, formally testing a records system against the functional requirements using the MoReq2010® test framework.


Information transmitted using characters and typically expressed using words delineated by spaces and punctuation.

  • All text in an MCRS must use the Unicode character set.

Descriptor for a text based metadata element that is expected to contain a value expressed in a particular language.

  • The information may not be accessible to a user who does not understand that language.
  • Additionally, the language of a textual value may alter how it is automatically processed.
  • For example, it may be indexed differently by a search engine, sorted into a different order in a list, or rendered using different styles or fonts.
Time zone

The offset between a time measured locally and UTC (Universal Coordinated Time).

  • Time zone information must be incorporated into all timestamps generated by an MCRS to avoid events appearing to occur out of sequence.
  • This is particularly necessary to support interoperability.

A highly precise system generated value for the moment in time at which an event or other significant operation occurred.

Timestamps must include the full date, time and time zone and should be precise at least to the second, and should seek to be even more precise, such as for example, millisecond precision.


Mandatory name or identifying text for an entity.

  • Usually shorter than a full description.
  • In MoReq2010® the titles of entities do not need to be unique, even for records within the same aggregation, although this is considered good practice.

An operation performed by a business system that is stored in a transaction log so that it can be repeated should the system need to be recovered from a disaster.

  • User of transactions ensures that less data is lost if a system fails as the transaction log can be used to roll forward from the last backup to the moment immediately prior to the disaster.

A disposal action where records are moved to a secondary storage or archival facility.

  • Transfer will therefore usually involve export and import, followed by the destruction of the records in the originating sytem.
  • Successful transfer must be confirmed before the records in the originating MCRS are destroyed.
  • Transfer can also be referred to as migration, especially where all, or a substantive number, of the entities in an MCRS, or a service, are being transferred.

A hierarchical structure.

Go to top



The Unicode standard provides standardised character encodings and processing rules for text in all European languages and nearly all human languages.


A uniform resource identifier, or URI, is used to identify and locate a resource, such as a datafile, on the internet.

  • Uniform resource identifiers can be extended to identify resources in other locations, such as in the local operating system.

A person or system with an account that enables access to and use of an MCRS.

  • A user does not have to be a human and could be another business system.
  • Users must be authenticated before they can use an MCRS.
User and group service

A logically separate service within an MCRS operationally responsible for managing users and groups.

  • The user and group service may integrate with or provide a wrapper for a directory.

An identification number made up of 128 bits and commonly described as a UUID.

  • Universally unique identifier
  • If generated using a suitable algorithm there is only a tiny probability that any two UUID values will ever be the same, even among billions of entities.
  • UUIDs are invaluable in their support for interoperability as they allow system identifiers to be exchanged between different generating information systems.
  • Suitable algorithms for generating UUIDs can be found in RFC4122, and these can even support "high allocation rates of up to 10 million per second per machine" (RFC4122:2005, 2.).

Go to top



The data that is placed into a metadata element.

  • Values must adhere to a strict datatype described by the equivalent metadata element definition.

Each service and each module of MoReq2010® has a version number made up of a major version and a minor version.

  • A minor version represents a change to the service or module that introduces a clarification, correction or additional non-functional requirement without changing the underlying information model.
  • All implementations with the same major version number should therefore be compatible with one another even if their minor versions are different.
  • A major version represents a change to the information model, such as the addition of new functions or system metadata elements, that makes an MCRS that only implements one major version, incompatible with an MCRS that only implements another.
  • MoReq2010® provided Service identifiers and module identifiers are only replaced when major version numbers change.

Go to top



An application used to visit a website and load and view web pages.

Go to top



A document format for expressing data in machine readable text, where elements and entities are identified by markup inserted into the text.

XML data

Data representing entities that are formatted in the export data format used by MoReq2010® for transfers, including migration.

XML data streaming

XML data transmitted electronically as a stream, or a series of data

XML transformation

Manipulation of XML data so to represent it in an alternative XML format or as other types of data.

Go to top