Element

Text

Explanation

Title 

Free Form 

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.

Date

2005-02-28

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.

Creator/Author

sjones

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.

Business Unit/Program

IMB

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.

Type

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.

AGD

Agenda

AGR

Agreement

ARS

Action Request

BRN

Briefing Note

CPA

Cover Page

CON

Contract

DFT

Discussion Draft

EXA

Example or Sample

FRM

Form

Type (cont'd)

GRA

Grant

IDX

Index

LTR

Letter

LST

List

MAC

Macro

MEM

Memo

MIN

Minutes

MTG

Meeting

NTS

Notes

PLN

Plan

PAP

Paper (e.g. research paper, discussion paper)

POL

Policy

PRS

Presentation

PRC

Procedure

RPT

Report

SCH

Schedule

SPE

Speech

SUM

Summary

SUP

Supplement

Extension

.doc

.ppt

.xls

.pdf

(etc.)

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.