Metadata capture
Prior to loading any documents onto your system you need to define the classification scheme and the metadata to be captured at the class, folder, folder part, record/document and content component level to the system. If you are employing a thesaurus of subject terms you also need to define that by loading the data into the system.
TNA core requirement A.1 defines the functional requirements for loading and holding metadata at the Class; Folder and Folder Part level. It provides guidance on how folders should be managed as well.
TNA core requirement A.2 defines the requirements for record capture, declaration and management. This involves declaring a record and placing it in one or more folders and hence classifying it. It also then defines the metadata that should be captured for each record and some rules relating to how records and associated metadata can be imported in bulk.
The choices for capturing metadata are either to key it in manually which is labour intensive and prone to error or to try and automate the process by loading existing metadata if it does exist or by capturing metadata from the document/record itself when it is created/capture/declared to be a record.
As indicated in section on Background and assumptions above, in an active document and content management system with collaboration and business process management support there will often be a need to capture additional metadata relating to content/documents which is not mandated by the TNA requirements. This will include data needed to control the status of incoming documents or newly created content as they are moved through a defined business process plus additional data needed to uniquely identify documents and link documents with line of business applications etc.
Your information gathering and analysis in stage three and your survey of existing systems in stage four should have enabled you to identify areas where you need to capture additional metadata for specific document types. We look at how that data is managed in the next section below.
Where index data is vital you may need to ensure that it is accurate by adding in validation steps. If the solution is integrated with a line of business application then that can be achieved by checking data held in both databases and reporting anomalies. Even within the EDRM system you can build in look up tables of allowed terms etc and compare data entered against these. In other cases you can ensure that the data has to be entered twice by different operators and compared.
