As more and more information is shared digitally, the use of structured, consistent and understandable naming conventions for information becomes vital. The BS promotes the following naming of containers. Containers refer to a named persistent set of data within a file system or application data storage hierarchy.
The naming convention for files is broken down into the following fields:
Field | Obligation | Description |
Project | Required | Code for project |
Originator | Required | Code for organisaiotn creating information. |
Volume or system | Required | Code for system reference. |
Levels and location | Required | Code to locate info (Floor 1 etc) |
Type | Required | Code for type of file Cost Plan, method statement etc) |
Role | Required | Code for role of organisation ( A - Architect etc) |
Classification | Optional | Code to reference asset (Uniclass or equivalent) |
Number | Required | Sequnetial file number |
Suitability | Meta-data | Code for status of data (WIP, Shared, published etc) |
Revision | Meta- data | Code for revisoin of data. |
Table 1: Summary of Naming Convention
For example:-
The first part of the naming convention is the Project code. This needs to be from between two to six characters in length, in letters or numbers. The project code should already have been established in the EIR. All parties on the project must use the same project code and not adapt it for their own organisations.
The second part of the naming refers to the Originator of the information, explicitly the organisation producing it. This code should be between unique and between three to six characters in letters or numbers.
The next two parts relate to spatial sub-division of the project starting with Volume or System with the use of 1 or 2 characters; ZZ is applied when all volumes are referred to. Next is Levels and Locations again made up of two characters as follows:
Levels & Locations | |
ZZ | Multiple Levels |
XX | No Level Applicable |
GF | Ground Floor |
00 | Base Level of Building or linear Asset |
Floor Levels | |
01 | Floor 1 |
02 | Floor 2, etc |
Mezzanine Levels | |
M1 | Mezzanine abovce Level 1 |
M2 | Mezzanine above Level 2 |
Below Ground Floors | |
B1 | Floor -1 |
B2 | Floor -2 |
Table 2: Summary of Levels & Locations
Next is Type which aids recognition. Every container should contain a single type of information e.g. a drawing, location model, typical assembly or detail information. Standards codes for drawings, models and documents are shown below:
Codes for Drawings & Models | |
AF | Animation File |
CM | Combined Model |
CR | Specific for the clash process |
DR | 2d Drawing |
M2 | 2D Model file |
M3 | 3D Model file |
MR | Model rendition file for other renditions (themal analysis) |
VS | Visualisation |
Codes for Documents | |
BQ | Bills od Quantities |
CA | Calculations |
CO | Correspondence |
CP | Cost Plan |
DB | Database |
FN | File Note |
HS | Health & Safety |
IE | Information Exchange |
MI | Minutes/Action Notes |
MS | Method Statements |
PP | Presentation |
RD | Programme |
RI | Request for information |
RP | Report |
SA | Schedule of accomodation |
SH | Schedule |
SN | Snagging List |
SP | Specification |
SU | Survey |
Table 3: Summary codes for document types
The next part of the name relates to the Role explicitly what the organisation does. On larger projects there might be several different companies working on the same discipline for example architect or engineer however the second portion of the naming convention, the company designation provides differentiation. The standard codes for roles are illustrated below.
Codes for disciplines & roles | |
A | Architect |
B | Building Surveyor |
C | Civil Engineer |
D | Drainage, Highways Engineer |
E | Electrical Engineer |
F | Facilities Manager |
G | Geographical and Land Surveyor |
H | Heating & Ventilation Designer |
I | Interior Designer |
K | Client |
L | Landscape Architect |
M | Mechancial Engineer |
P | Public Health Engineer |
Q | Quantity Surveyor |
S | Structural Engineer |
T | Town and County Planner |
W | Contractor |
X | Sub-Contractor |
Y | Specialist Designer |
Z | General |
Table 4: Codes for Roles & Discipline
The next part of the naming is Classification however this is an optional field. The classification field helps describe the asset represented using the chosen reference dictionary for example the latest version of Uniclass. Link to classification sub-task
Next is the sequential Number which should be used when a container is one of a series not distinguished by any other of the fields, this applies most often to files. The numbering for standard coding should be exactly four integer numeric digits, used sequentially. Leading zeros should be used.
The next part of the naming convention is the Suitability code which should be one or two characters given in Table 5 below.
Status | Description | Graphical | Non- Graphical | Document |
Work in Progress | ||||
SO | Initiall Status of WIP | Yes | Yes | Yes |
Shared (Non-Contractual) | ||||
S1 | Suitable for co-ordination | Yes | Yes | Yes |
S2 | Suitable for Information | Yes | Yes | Yes |
S3 | Suitable for review | No | Yes | Yes |
S4 | Suitable for approval | No | Yes | Yes |
WIP to Publish | ||||
D1 | Suitable for costing | Yes | Yes | Yes |
D2 | Suitable for tender | Yes | Yes | Yes |
D3 | Suitable for design | Yes | Yes | Yes |
D4 | Suitable for manufacture | Yes | Yes | Yes |
Published Docs | ||||
A1,A2,A3 | Approved/Accepted | Yes | Yes | No |
B1,B2,B3 | Partial sign off | Yes | Yes | No |
Table 5: Summary of codes for suitability
The final part of the naming convention is the Revision code based upon table 15.3.3. With regards the last two codes in the naming convention Suitability and Revision, if information passes through an environment that cannot track meta-data then these optional can be omitted all together.
Employers should consider developing automated file naming, suitability, naming, status and revision codes.