13.2 Defining metadata

Metadata is defined using a Metadata Schema. This is an overall definition which includes definitions of all folder, document and issue types - see section 15 Issuing for more about issuing - and their related metadata. The metadata schema applies to an entire workspace. In other words, metadata is defined on a project by project basis. A new metadata schema can be created in your metadata schema bag. The metadata schema bag: is a personal object and contains all of the metadata schemas which you have created or have access to. (If you do not have a metadata schema bag and need to create or edit schemas, you should contact your Business Collaborator system administrator.)

When you are inside your schema bag, the location bar 'Location:' indicates your current location to be /Metadata Schemas followed by the specific location within a schema or the metadata types it contains, for example see Figure 13.2-1.

Figure 13.2-1: The location bar within the schema bag

A metadata schema is an abstract container which can be used to collect other abstract concepts, such as folder types, document types and metadata fields, which are then applied to a workspace and its contents based on the schema. There is a correspondence between the abstract concepts in a schema (Schema Type/Folder Type/Document Type/Issue Type) and the standard Business Collaborator equivalents (Workspace/Folder or Collection/Document/Issue or Review). (Issues are introduced in section 15 and Reviews in section 17.) Thus a metadata schema can be applied to a workspace, the folder types it contains can be used by folders contained within the workspace (see section 13.2.6 - Folder type), the document types are applied to documents in the workspace (see section 13.2.5 - Document type) and the issue types define the attributes of its issues and reviews (see section 13.2.7 Issue Type).

See Figure 13.2-2 which shows the hierarchical structure of the schema and its associated elements.

Figure 13.2-2: The hierarchical structure of an example schema

A new metadata schema is added by clicking Add | Metadata Schema from inside your metadata schema bag. Like many Business Collaborator objects, a metadata schema may have a name and description. Clicking on "Add Schema" adds the new schema, indicated by to your schema bag with its name and description displayed in the usual way.

To edit a metadata schema, click | Edit for the schema within your schema bag or click View/Change | Edit from within the schema itself. Editing the schema will display the Edit Schema Type page (see Figure 13.2-3 Edit Schema Type).

Figure 13.2-3: Example of the options available on the Edit Schema Type page

Clicking "Apply" saves the current settings for the metadata schema. Clicking "Reset" returns the settings to the last saved changes of the schema and undoes any changes made during the current round of editing.

There are various attributes of the metadata schema which can be edited. As these attributes can be shared with other metadata types, they are dealt with in separate sections. Default types are introduced in the context of specifying default document types for folder types - see section 13.2.12 Default types. Metadata fields are described in section 13.2.8 Metadata fields. Privacy is in introduced in section 13.2.2 Privacy. Validity policy is discussed in section 13.2.3 Validity.

Finally, for the metadata schema, there is an option to choose how documents should be revised. This setting is available at the level of the schema only and so applies throughout any workspaces using this schema. The choices are either to make the document type of a revision the same as that of the original document by default. The alternative is to revise documents with a version which is of the default type of folder initially. This might be used, for instance, to ensure that documents had a pending type (e.g. automatically invalid) no matter how they were added to the workspace.

13.2.2 Privacy

Business Collaborator objects are normally available to all of the members of the folder that contains the objects. These people are a combination of the users added as members to the folder, plus those who have access to the current folder because it is contained inside a folder or workspace which they have access to (see section 4.2 - Workspace and folder members).

Under some circumstances, it may be that access to documents of a particular type or to issues and their associated information (see section 15 - Issuing) should be restricted even within the set of folder members. This is accomplished using the privacy settings of the objects involved. Although privacy only applies to documents and issues, the settings are usually specified at the level of a container. For instance, privacy settings at the folder type level will often determine whether documents added to folders of this type are private or not. All metadata types - schema, folder, document and issue types - can have privacy settings specified on them. The container-level settings (i.e. those on the schema or folder type) are overridden by those set explicitly on the document and issue types. (See Figure13.2-4) In turn, these may be overridden by editing the settings on a document or issue directly.

Note

Privacy only applies to documents and issues, not, for example, to reviews or folders.
In the case of a document type, defined inside the schema, which is inherited by a folder type, a document directly inside the workspace inherits its privacy settings directly from those of the workspace. However, a document of the same type inside a folder may have a different privacy setting, inherited from the folder. Figure 13.2-4 illustrates this case. The document type note is defined within the Standard Project schema but is also inherited by the reports folder type. A note added to the workspace will inherit its privacy settings from the schema type applied to the workspace but one added to a reports folder may have different privacy.

Figure 13.2-4: Example of setting privacy within a schema

By default, no privacy is applied. To apply privacy settings to workspaces using a schema, check the "Enable Privacy Settings for this schema" checkbox (refer Figure 13.2-4: Edit Schema Type). When a privacy setting is applied, only those users who satisfy the privacy conditions will be able to access any private objects. If you are prevented from having access to a document or issue, its name will be visible within the folder containing it but its name will not be a clickable link so you will not be able to read it. You will not be permitted to carry out any actions on the object. There will also be an icon beside the document (or issue) name to indicate why you cannot click on it.

At the schema level, you can set whether documents should be returned (visible) in searches or not (see section 5.5 Searching and section 16.4 Viewing and Searching a Collection. If private documents are returned in search results, they will not be clickable links for those who are denied access to them. Again, the icon will indicate that this is the case.

If you set privacy settings for a schema type, you can decide whether to make objects public or private by default. If privacy settings are enabled for a folder type, you can choose whether to make its contents private or public or whether to inherit their privacy settings from the schema type (the default setting).

An issued object is always available to the person who owns it (i.e. usually the creator). Thus you will therefore never see the icon beside any documents you own. In addition, issued objects will always be available to anyone to whom they are issued. The final configurable privacy setting is to decide whether you also wish to make objects accessible to other people in the same Business Collaborator group as the object owner. (For more on Business Collaborator groups, see section 4.2.5 Membership groups.)

A private document or issue can be made available to others by

editing its metadata settings to make it public - see section 13.3.4.1 - Editing metadata on a single object. (This can only be done by the person who created the document or issue.)
changing the metadata schema privacy settings - either at the workspace level, at the level of any folder types containing the relevant metadata type or at the level of the metadata type itself
issuing the document to a set of people - see section 15.2 Creating an issue. Those on the distribution list of an issue always have access to the issue and any related documents.

13.2.3 Validity policy

The validity policy on a metadata schema defines the behaviour of objects added to a workspace defined using the schema when the objects have "invalid" metadata. (A blank field will be the most common example of this, but further examples of invalid metadata are given in section 13.2.8 - Metadata fields). Any object - workspace, folder, document, issue and review - which can have metadata assigned to it may have invalid metadata.

It may be desirable to prevent users from being able to carry out actions on objects with invalid metadata in order, for instance, to encourage them to provide valid values for the required metadata fields. By default, anyone can carry out any of the usually available actions on a document irrespective of whether its metadata is valid or not.

If an object has invalid metadata, the will be displayed beside the object name. Clicking on this icon takes you directly to the Edit Metadata page for this object - see section 13.3.4. The actions available on the object are determined by the validity policy. The validity policy applies over the entire workspace. The validity policy applies to objects and it is irrelevant if you own the object or not.

The options for the validity policy are detailed below.

No policy - this is the default; anyone can do anything to any kind of object.
Edit Metadata Access and Get Access on all Objects - on all objects, | More Info , | Change Metadata Type and | Edit Metadata are available. Also, all users can click on any object to view its contents. (For workspaces and folders, the Contents action is available and, for workspaces, Goto Schema is also permitted.)
Edit Metadata Access on Documents Only - Workspaces, folders, collections, issues and reviews are unaffected by this setting - all the usual actions are possible. For documents with invalid metadata, users may only change the metadata type or edit the metadata. Documents cannot be read.
Edit Metadata Access on all Objects - the metadata type may be changed and metadata may be edited on workspaces, folders, documents, issues and reviews. No other actions are permitted, even reading documents or going into folders. (Also, the does not display beside folder names even if they are non-empty.)
Edit Metadata Access, with Get Access on Containers - as in the previous case, the metadata type may be changed and metadata may be edited on all objects. In addition, Get access is available on workspaces, folders, issues and reviews so that users can click on them to view their contents and then edit the metadata on the documents inside them. However, documents will not be readable, appearing as text rather than a clickable link, until their metadata is made valid.
Only Read-Only Operations - This setting applies to any kind of object. In addition to editing metadata and changing metadata type, only actions which do not alter the original object are permitted. Such actions include reading documents, going into folders, copying documents or folders, setting notification or obtaining the Distribution History of an issue (see section 15.6.1).

If an object has invalid metadata, this can be made valid by

editing the value(s) of its metadata - see section 13.3.4 Editing metadata - or changing its metadata type - see section 13.3.5 Changing the metadata type.
changing the validity policy which applies to the workspace containing the object.

(Changing the validity policy takes immediate effect.)

13.2.4 Actions on a metadata schema

A metadata schema is edited by either clicking | Edit on the schema in your schema bag or View/Change | Edit inside the schema. An overview of the metadata schema can be obtained by clicking | Summary for the Schema (or View/Change | Summary from inside the Schema). Such a summary of a schema is displayed in Figure 13.2-2 Summary of Schema. The summary can be invaluable as it shows all of the folder, document and issue types which the schema contains. It also shows the MIME types to which any document types apply and their default types. In addition, the summary also indicates which field sets are associated with each type of object.

Clicking on the names of any metadata type on this page will take you directly to the Edit Metadata Type page for this metadata type. For example, clicking on type in Figure 13.2-2 will display the Edit Document Type page for the Report Document type, as illustrated in Figure 13.2-5 Edit Report Document Type. The standard actions available on a schema are described in section 13.2.13 - Actions on metadata types.

Figure 13.2-5: Example of a document type edit screen

13.2.5 Document type

A document's type defines the metadata fields which are associated with a particular type of document. For example, a document type of Drawings could be defined to have associated with it a "Technical Author" name. This document type could then be associated with all the drawing filetypes which might be encountered, e.g. dwf, dwg, plt, dgn etc.

A document type can be created anywhere within a metadata schema by clicking Add | Document Type and giving the document type a name and (optional) description. The document type will appear at the level in the schema hierarchy where it was added and is indicated by a icon. This type of document will then be available in any workspace using this schema, at any level where this document type may be used.

For example, consider the schema illustrated in Figure 13.2-3. The document type Invalid Document Type is defined at the top level of the schema and so is available immediately within any workspace using this schema. Also, Invalid Document Type is available (by inheritance) within folders of the types Reports Folder Type and Documentation Folder Type. This means that documents added to these types of folders can also be automatically set as Invalid Document Type as determined by the documents MIME type. A new folder type could be added that did not inherit from folders or schema above it. In this case Invalid Document Type would not be available. Section 13.2.5 describes how to control which document types are available within which types of folder.

Clicking | Edit to edit the Report Document Type results in the Edit Document Type page - Figure 13.2-5. Like the Edit Schema Type page, the metadata fields to be applied to this document type are defined here - see section 13.2.8 Metadata fields.

The MIME types of document to which this document type applies are specified in the Applicable MIME Types section of this page. As an example, Figure 13.2-5 illustrates that the Report Document Type document type can be applied to MS Word, Adobe PDF or plain text documents but not, say, MS Excel spreadsheets.

By default, the document type will be available to all filetypes unless specifically restricted. To limit the document type to a few filetypes, select these MIME types in the multiselect list box. Alternatively, click the "Allow the document type to be assigned to any MIME type not highlighted in the list below." radio button and select the MIME types which are not to be associated with this document type.

A document type can have its own privacy settings (see section 13.2.2 - Privacy) applied to it. By default, the document type will inherit the privacy settings of its parent metadata type.

Version numbering and version control can also be prescribed at the document type level, as described in section 13.2.14 - Version numbering.

Note: A document type is not the same as a MIME type - e.g. MSWord document, AutoCAD DWF etc. The MIME type of a document is automatically associated with a document when it is added to Business Collaborator. The available MIME types are defined by a set of international definitions. The MIME type determines what icon is displayed beside the document and, in some cases, what actions are available on the document. It is also possible to search for documents by MIME type.

13.2.6 Folder type

A folder type groups together a particular set of document types. Thus, by imposing a specific type on a folder, you can restrict the types of documents, folders and issues available in folders of this type. Metadata fields can be assigned at the folder type level, as well as at the document type level - or even on the schema itself.
A folder type can be created anywhere within a metadata schema by clicking on Add | Folder Type . A folder type has a name and an optional description. The folder type appears at the level in the schema hierarchy where it was added and is indicated by a icon.
You can click on the name of the folder type inside the schema to display the document types and folder types which it contains. The folder types added inside the current type indicate the types of subfolder which folders of the current type may contain. Without defining any folder types inside the current folder type, it will only be possible to add folders of No Type inside folders of this type. In contrast, document types defined inside this folder type will be available not only in folders of this type but also in their subfolders. The available document types are further controlled by the definition of the default types for this folder type - see section 13.2.12 - Default types.

Clicking | Edit to edit the folder type results in the Edit Folder Type page which is very similar to the Edit Document Type page - see Figure 13.2-5.

Metadata fields are associated with the folder type in the same way as for document types - as described in section 13.2.5 - Document type.

A folder type can have its own privacy settings (see section 13.2.2 - Privacy) applied to it. By default, the folder type will inherit the privacy settings of its parent metadata type.

Note: It is recommended that a naming convention is adopted to ensure that no two metadata types have the same name. This will make searching using metadata (see section 16.4 Viewing and searching a Collection and section 5.5.4 Details of metadata searching) much clearer. For example, it may happen that a folder type and document type could both be called invoices. It would be preferable to give the document type the name invoice and to call the folder type invoices.

13.2.7 Issue Type

An issue type associates a set of metadata fields and, possibly more importantly field sets, with an issue (see section 15 - Issuing).

An issue type can be created anywhere within a metadata schema by clicking on Add | Issue Type . An issue type has a name and an optional description. The issue type appears at the level in the schema hierarchy where it was added and is indicated by a icon.

The attributes of the issue type can be edited by clicking | Edit for the issue type. The Edit Issue Type page is a considerably simplified version of the other Edit Metadata Type pages, e.g. see Figure 13.2.5. Metadata fields may be associated with the issue type as described in section 13.2.8 - Metadata fields. The issue type may be assigned its own privacy policy as described in section 13.2.2 - Privacy.

Note: Unlike document types, issue types defined at one level in the metadata schema cannot be inherited by folders at lower levels. Rather than copying an issue type and placing it at different levels in the metadata schema, the one issue type can be used if issues are created at the appropriate level in the hierarchy and documents attached to it when the issue is created (see section 15.3.5 Changing the documents in the issue).

13.2.8 Metadata fields

As stated previously, user-defined metadata permits project managers to categorise information using a method appropriate to the project. In some instances, the metadata may simply be a label so that the best way for users to enter the data would be via a simple text box (and the label would be stored as a string). For maximum flexibility, different formats for storing the metadata can be defined. Thus, the project manager must decide what each metadata field will be called and, by knowing typical values which might be stored in this field, what type of field is required. (Such fields are akin to the relational database field types described in section 8.3.3 - Field datatypes).

Metadata fields are available to the entire schema, irrespective of where they are defined.

A metadata field can be added to a metadata type from the Edit Metadata Type page (e.g. see Figure 13.2.5) by clicking on Add | Field . You will first be taken to the Add Field page where you will be required to make certain decisions regarding the metadata field:

What is its type?
- paragraph, date etc. see section 13.2.9 - Metadata field types
Should it be assigned on a per user basis?
- This permits a separate value to be recorded for every user who edits the metadata. This could for instance be useful to store ratings of a document where each user's rating should be maintained independently.
Should it be required?
- Required fields are those which are invalid until they are assigned valid metadata. For example, a project manager string could be required on a document type to make documents of this type valid. The validity criteria could be more complex, e.g. a date could be required to be in the future to be valid. The behaviour of a workspace containing objects with invalid metadata is defined by the Validity Policy set on the schema - see section 13.2.3 - Validity policy
Should it be shared with other schema designers?
- If so, it will appear as a Global Field for all schemas on the server. If not, the field will appear as a Local Field - only available to the current schema. On an Edit Metadata Type page, Global Fields appear above local ones in the Metadata Fields section of the page - see Figure 13.2.5

Clicking "Next" will display the Configure New Field page for the new metadata field. Here, the field can be given its name. Depending on the field type, further information may be required, e.g. for a drop-down list as illustrated in Figure 13.2-6, the options to display in the drop-down list may be entered here.
Clicking "Update" will refresh the page and, depending on the field type, may offer further opportunities for further configuring the new metadata field. In the example of Figure 13.2-6, clicking "Update" will allow you to add more than 6 options to the drop-down list.
Once the metadata field has been fully configured, you must click "Done" to submit your changes to Business Collaborator.

Figure 13.2-6: The "Configure New Field" page

You will be returned to the Edit Metadata Type page where you initially clicked Add | Field . The newly added metadata field will be added as a new row in the Metadata Fields section of this page - as shown in Figure 13.2.5. Required fields are indicated by a * after the field name. By default, this field will be a Local Field. If you specified that the field should be Global, it will appear in this (upper) portion of the table. Within the subheadings Global Fields and Local Fields the metadata fields are ordered alphabetically by name.

To associate a metadata field with a particular metadata type, simply check the box beside the field in the General column of the Metadata Fields table of this page. (The remaining columns relate to other field sets as discussed in section 13.2.11 - Metadata field sets.) As an example, see Figure 13.2.5 where the metadata fields

ApprovedOn - datetime type, no restriction
Rating - drop-down list box with opinions Poor, Average, Good, Excellent
Comments - Paragraph, required

apply to the document type incoming correspondence. The corresponding Edit Metadata page for a document of this type is shown in Figure 13.2-7.

Note

Once a metadata field has been added to a schema, this field is then available to be used by all metadata types within the schema. However, the field only applies to the objects for which it is explicitly selected.
Until the "Done" button on the Configure New Field page is clicked, the changes have not been saved. Leaving this page without clicking "Done" will therefore lose all changes made.

Figure 13.2-7: Example of an Edit Metadata page

13.2.9 Metadata field types

The available metadata field types are:

Checkbox
Datetime - date and time expected in the form dd/mm/yyyy hh:mm:ss. (If time is not specified, 00:00:00 is appended to the date as it is entered.) For this field type, a date range can be imposed by specifying a minimum and maximum date or by requiring that the date is always in the future.
Drop Down list box - a list of options only one of which may be selected at a time, e.g. Jan, Feb, Mar. Initially, 6 text boxes are provided in which to enter the items to appear in the list box. Clicking "Update" will cause a further 6 to appear. The order in which the list will appear is the order in which they are entered. Only one option may be selected at a time from such a list.
Float - a floating point number, e.g. 2.7, 3.14. (A value which does not contain a decimal point will be indicated not to be a valid floating point number.)
Integer - an integer, e.g. 412 (A value which contains a decimal point will be indicated not to be a valid integer.)
Invalidate - forces the metadata to be invalid when the object is initially added to the workspace - see section 13.2.3 - Validity policy for the consequences of having invalid metadata.
Multi Select List Box - a list of options many of which may be selected at a time. As for the Drop Down list box, 6 values can be entered initially and clicking "Update" will cause a further 6 to appear. Several options may be selected at a time from such a list.
Paragraph - a paragraph of text
RE Pattern Match - permits a regular expression pattern, defined according to Python conventions, to be defined. This could be useful if the precise value of metadata is unknown but its format is.
Redline - a Brava! Markup (see section 19 - Brava!)
String - a single line of text
This BC Object ID - the unique ID of the Business Collaborator object to which this metadata is being applied. (Note that issues are named using their Business Collaborator object ID if a name is not provided by the person creating the issue.)
User - the full name of a Business Collaborator user. When used, this field will provide a drop-down list containing the names of all the members at the current level in the hierarchy (see section 4.2 - Workspace and folder members) plus the option Current user.
User Details - one of the personal detail fields of the Business Collaborator user assigning the metadata, e.g. their organisation name. (These details can be seen by clicking on the name of a document or folder owner. Users enter their details initially when completing the Welcome screens the first time they log into Business Collaborator and may edit their details at a later date via the User | Edit Details action. Further information is available in section 5.6 - Personal details). This field should be allocated on a per user basis.

Note: As it is not possible to change one metadata field type into another, it will save time to plan ahead and identify the field types which you need.

13.2.10 Changing metadata fields

13.2.10.1 Editing metadata fields

13.2.10.2 Deleting metadata fields

13.2.10.3 Ordering metadata fields

13.2.10.1 Editing metadata fields

A metadata field can be edited by clicking on its name where it appears as a link on an Edit Metadata Type page. The field name may be edited and certain other attributes may be changed, e.g. the options in list boxes may be modified.
However, it is only possible to change a limited set of attributes.
It is not possible to alter the field type to change, say, a datetime field to a checkbox. It is also not possible to make a field required or per user retrospectively. Restrictions cannot be applied in retrospect to force datetime fields to be in the future or within a given date range.

Metadata fields may only be copied or cut within the schema where they were defined.

13.2.10.2 Deleting metadata fields

To delete a metadata field, go to the Edit Schema Type page (see section 13.2.1 Creating a metadata schema) for the schema which uses the field and click View/Change | Delete Fields . Select the field or fields to be deleted and confirm by clicking "Delete Fields". Deleting a metadata field does not move it into the user's waste bin.
If a metadata field which is already in use by a metadata type is deleted, the field moves to the Old Fields section of the Metadata Fields table on the Edit Metadata Type pages where it was being used. This obsolete field will no longer appear on the Edit Metadata Type pages for any types where it is not already being used and so no additional types can be associated with this metadata field. For objects of this type, it will still be possible to add or edit values for this metadata field. As soon as the obsolete metadata field is deselected on the Edit Object Type page where it appears, it will not be possible to add or edit values for this metadata field any more and the field will disappear from the Edit Metadata Type pages where it previously appeared.

Note

It is not possible to undo the Delete Fields action so you must be sure that you have no further use for these fields.
A field cannot be deleted once it has been shared with other schema designers.
Any metadata values submitted before a field was deleted will remain in place until the metadata on the object is edited again.

13.2.10.3 Ordering metadata fields

Where more than one metadata field is being used by a particular metadata type, the order in which the fields are presented to the end user can be set by the schema designer by clicking on the Field Set heading, e.g. General. The Sort Fields page will then be displayed - see Figure 13.2.8. You can set the ordering manually and click "Save" or order the fields alphabetically by clicking the other button.

Figure 13.2-8: The Sort Metadata Fields page

13.2.11 Metadata field sets

Metadata can be used in two contrasting ways. In the first, it can be used to attach additional descriptions or qualifications to information when it is added to Business Collaborator. This metadata provides categorisation which helps to sort or search for information later. Thus, if task number is a metadata field which is available on documents being added to a workspace in Business Collaborator, it makes it easy to retrieve all documents related to a specific task at a later date. section 13.2.8 - Metadata fields describes how to assign, view and edit such metadata. Searching using this metadata information is described in section 5.5.4.4 Details of metadata searching. Note that all metadata assigned for this purpose is set using check boxes in the General column of Edit Metadata Type pages.

In addition, once documents have been added into Business Collaborator, metadata may be used to store comment and review information obtained from other users. In such circumstances, the metadata fields which are employed are less likely to be categorisation information such as task number and more likely to be comments or a checkbox to indicate whether a document is approved to proceed to the next stage. As documents may be circulated to people for a number of different purposes - see section 15 - Issuing - it is important to be able to define different sets of metadata fields for use depending on the purpose of the issue or review. New Metadata Field Sets satisfy this requirement.

A new Field Set is added from an Edit Metadata Type page by clicking Add | Field Set . After entering the name for the new field set, decide whether it may be of use to others. If you wish to make the field set globally available check the checkbox and click on "Add Field Set". The new field set will appear as a new column in the Metadata Fields section of all Edit Metadata Type pages for this schema. If the field set is global, it will appear after the General field set and before any local ones.

Field sets can be removed from the Edit Schema Type page by clicking on View/Change | Delete Field Sets . Check the boxes to the left of the field sets to be deleted and click "Delete Field Sets". Deleting a metadata field set does not move it into the user's waste bin.

Note

It is not possible to delete a field set which is in use. Any metadata types using the field set are displayed as links to the relevant Edit Metadata Type page. Deselect any metadata fields checked in the field set column to prevent it being used by this metadata type then repeat for all types using the field set. Then it will be possible to delete the field set.
For a global field set, it is only possible to delete a field set from the schema where it was defined.
The General field set can never be deleted.

13.2.12 Default types

The only document types available within a folder type are initially those defined inside the folder type, i.e. each folder type does not inherit any document types from its parent (the schema type or another folder type). However, it is possible to specify that any document types defined at the parent level are also available to folders of the current folder type.

The parent level's document types can be permitted within folders of the current type by clicking the radio button at the top of the Edit Folder Type page (see Figure 13.2-9).

Figure 13.2-9: Example of how to inherit document types

When a document is added to a folder of the current type, the document type can be set on the document as described in section 13.3.3 Setting the metadata type of a document. This process can be speeded up by specifying the most commonly used document types as the default types for certain MIME types, i.e. by setting the Default Type for this MIME type. For instance, if most MS Word documents added to a folder are to be of the type report, this can be made the default type of all MS Word documents added to the folder. Then, only the MS Word documents which are not reports need have their type set manually. As the default type is set at the folder level, the same MIME type can default to different document types in different folders.

To set the Default Type for a particular MIME type or set of MIME types, click on Add | Default Type on the Edit Folder Type page. The full set of MIME types known to Business Collaborator is displayed. To select several MIME types, hold down the Ctrl key while making your selection. In the drop-down list below, select the document type (see section 13.2.5 Document type) from those available in this folder type. Beside the document type, the MIME types to which it can be applied are indicated. If you select a document type which does not correspond to the MIME type highlighted, this selection will be ignored. Click "Update" to return to the Edit Folder Type page where the default types will be displayed - see Figure 13.2-10.

Figure 13.2-10: Example of setting default mime types

Default types may be defined explicitly at the folder type level or the folder type may inherit its default types from its parent. The latter option is only possible if the parent's document types are being inherited. If the Default Type setting is changed to inherit from the parent, any explicitly set Default Types will be lost.

Default types can be defined for the entire schema. In this case, the default types apply until overridden by an explicit setting on a folder type within the schema.

To remove a default type setting on a folder type, go to the Edit Folder Type page and click View/Change | Delete Default Types . The default types set explicitly at this level are displayed. Select any to be deleted by checking the box beside their name and clicking "" to confirm your changes. You will be returned to the Edit Folder Type page where the deleted default type(s) will no longer appear.

13.2.13 Standard actions on metadata types

Document, Folder, Schema and Issue Types can be renamed and have their descriptions edited in the usual way, using | Rename and | Edit Description .
They can be cut, copied and deleted by selecting them and using the appropriate action from the Selected menu. Cut and copied objects will be moved to the bag until they are pasted. Cut or copied metadata types can only be pasted back into the schema where they originated or into the schema bag for schema types. Copying a metadata schema results in an object called "Copy of …" when it is pasted back into the schema bag.
Deleted metadata types can be undeleted back to their original location or destroyed.
Schema and folder types can be unfolded to display their contents to make the objects inside more easily available for editing. The | Summary action on a schema is described in section 13.2.4 - Actions on a metadata schema. The More Info page gives the usual information about the creator of the metadata type, its access permissions and events. Access Rights can be set on metadata types in the usual way.

The new , changed , moved and events inside event icons display in the usual way as described in section 4.7 - Events.

13.2.14 Version numbering

The standard version numbering system for documents in Business Collaborator is n.n where n is in fact a multi-digit number. The version number is automatically incremented when the document is revised, as described in section 3.7 - Version control and can be edited manually as required. However, it is often advantageous to impose a more complex numbering system on documents. This can be achieved by defining a version numbering format for documents of a given document type. The available version numbering formats are defined globally by a system administrator. To assign a format to a particular document type, click View/Change | Version Numbers on the Edit Document Type page. Select the option for version numbering required. (Default will always be available but other options will be dictated by those defined on the Business Collaborator server.)

By default, version control (see section 3.7 - Version control) is always switched on for all documents in the most recent versions of Business Collaborator. It may be switched off globally, across the entire server so that documents are overwritten by default, unless they are explicitly placed under version control (see section 3.7.1 - Putting a document under version control).
In addition, for each document type, it is possible to specify whether documents are under version control. By default, all document types will be auto-versioned or not as defined by the global server setting. This global setting is specified by the Business Collaborator server administrator. At the document type level, the schema editor can over-ride the global setting to force document control to either be always on or always off for this document type, irrespective of the global server setting. This setting is also controlled using the View/Change | Version Numbers action on the document type.

13.2.15 Sharing a metadata schema

You can make your metadata schema available to other metadata designers by adding them as members - click | Add Member from inside the Metadata schema. The schema will then appear in their metadata schema bag. In your metadata schema bag, a members icon will be displayed beside the schema name indicating that it is shared. This members page behaves in many ways like an ordinary folder members page (see section 4.2.4 - Membership page) e.g. it displays a list of the users who have access to the metadata schema and members may be removed by selecting their name and clicking Selected .| Remove .

Only someone who has access to the metadata schema (i.e. has it in their metadata schema bag) can | Goto Schema .

Note: Sharing the entire schema with other schema designers is entirely separate from sharing a single metadata field - see section 13.2.8 Metadata fields.

<<<<<

Section

>>>>>

Page