Some suggested practices around the use of each element are identified in Table 1.
Table 1 Use of Naming Convention Elements
Think of the user/recipient and how they might search for and retrieve the document. Use a title that clearly describes the content of the document. The name should be intuitive to those who need to access it but not excessively long.
Use standard abbreviations that have been agreed on by the organization and/or business unit. When creating multiple versions, use the same title for all versions.
Consider if the sorting order is significant e.g. title first? date first?
For very large documents where the component parts are stored separately, the title may also contain the "Part" of the document (e.g. Title_Part#_version, etc.). Part may be the chapter or section of the document.
This is a significant date relevant to the document (e.g. version or published date). It is not the system-generated date that the software automatically updates each time a document is saved.
Use the metric (international) date standard YYYY_MM_DD to facilitate the sorting and display of files in a logical order (see Alberta Data Standard).
Use of the date should be defined by business needs, e.g. what is the most useful date for retrieval purposes. It may well be simply the year, e.g. for recurring reports.
Use first initial and last name.
While this information may be correctly captured in the desktop document profile, it can be used to avoid confusion where multiple people are creating different versions of the document.
Depending on the use of the information, this could be the business unit or program area.
Be cautious of using branch names as these are subject to continual change. Program areas (which are business functions) change less often (e.g. they may reside in different branches or divisions or ministries over time). If branch names are used, they may be meaningless as soon as the next reorganization occurs.
Identifying the program area can be useful in identifying the controller of the information. It may also be useful where there are committees with multiple sub-committees dealing with commonly titled documents.
Document type can help reduce the length of the title. Where this information is captured as a metadata element, it is not likely to be needed in the document name.
Do not include document type if its location (folder) identifies the type.
The following type codes are examples. A full list needs to be developed that is consistent with GoA metadata standards currently under development.
In most business units only a subset of these standard abbreviations may be needed. It is best to keep to a list of ten or less so that people can easily remember the codes.
Example or Sample
Paper (e.g. research paper, discussion paper)
An extension must be provided. It is not optional.
Use the appropriate extension for the application in which the document has been created. Extensions are automatically generated and attached to the end of the document name by the application. The extension will be used by the system to determine which application was used to create the document.
Do not add different extensions or text after the extension.