Metadata Storage and the Folder Structure | KnowledgeTree Document Management Software

This section explains the relationship between metadata and the folder structure in KnowledgeTree, and how permissions are assigned within this structure.

The efficiency of the repository depends on setting up an effective metadata storage structure, and a folder structure. These two structures are inter-related, and require accurate mapping.

When using ...

... then,

folders, without fieldsets

this structure may be too deep and complex.

Users may struggle to navigate the repository, and the search function is less effective.

Fieldsets, without structure

effective browsing, navigation, and search is prohibited when there are too many document fields and no folder structure.

User's are unlikely to properly complete information in all of the fields and fieldsets that are required when there is no accompanying folder structure.

More importantly, there is no way to apply Permissions when using this method of storage.

Although the folder structure may be designed to map exactly to the metadata, such a structure is hard to manage. This is because the lower levels of the folder structure (level 1 in the example) should be as static as possible.

In the following example, it's easier to change the structure at level 3 than at level 2, and it's easier to change the structure at level 4 than at level 3. In this instance, each time a new client is added, it is necessary to add a new Client[no] folder. By storing the client id (e.g. 001) in the metadata layer of the Invoice folder, users can browse to the Invoice folder, and rely on metadata after that.

Example: The document type, document title, and the client number, which are all metadata, are stored in the folder structure:

Level	Folder hierarchy
1	Accounts Receivable
2		Invoice
3			2005
4				Client 001

Note: To ensure usability, the folder structure should not be deeper than 3-4 levels.

The following example shows three layers of metadata, which may be represented as follows:

Project Department:      Human Resources
Project Name:               Recruitment
Project Document:         Applicant evaluation form

This storage method ...	provides this structure ...
Store all the information in a folder structure	>Human Resources >>Recruitment >>>Applicant evaluation forms
Place all documents in a single folder, and store the metadata in fieldsets, and in document types	Document type: Human Resources Pick list: Recruitment (Projects) Pick list: Applicant evaluation form (Project document types)
Create a hybrid of folder structure, and fieldsets/document types	Folder structure: >Human Resources >>Recruitment Document type: Applicant evaluation form

A single, secure, searchable organizational repository must have a system of permissions, Permissions are applied on the folder structure, while the repository's Search function is based on the metadata layer.

Without a folder structure, all the information about the documentation is in the metadata. It is impossible to apply permissions to this structure, because all the content is effectively in one folder - the root folder.

It is possible to apply a folder structure that is similar to the metadata structure - e.g. create a folder name of the same name as the document type: Invoice document type, and Invoice folder. This allows permissions to be assigned on the Invoice folder, and it allows searching of invoice related metadata.