Collections management system criteria checklist

A.1 Object entry

The management and documentation of the receipt of objects that are not currently part of the collections. These objects may or may not eventually be accessioned.

The number of criteria in this section of the full checklist is 21.

*A.1.1 Uniquely identify objects or object lots on deposit

The system can uniquely identify newly received objects or object lots, and assign a unique local deposit number which can be differentiated from accession numbers.

*A.1.2 Entry reason

The system can record a reason for an object or group of objects physically entering the organization.

*A.1.3 Unique system number assigned

The system can ensure that a unique system number is assigned to all objects or object lots (accessions, loans, temporary custody).

A.1.4 Entry number

The system can ensure that the institution is able to account for all objects or object lots on deposit with identifying data (for example, owner name, depositor name, location, unique identifier, number of lots, return date).

A.1.5 Provide receipt

The system can provide a receipt for the owner of the objects or object lots on deposit.

A.1.6 Establish institution's liability

The system can help to establish the extent of the institution's liability for deposited objects or object lots (for example, reference to paper file with signed deposit documents).

A.1.7 Record reason for deposit of object

The system can link the deposit of the objects or object lots to a type of event (for example, valuation, conservation treatment, identification or potential acquisition.)

A.1.8 Finite end to deposit

The system can allow the user to designate a finite end to the period that objects or object lots are temporarily deposited with an institution.

A.1.9 Notification of end to deposit

The system can provide notification about the end of a deposit (for example, a reminder that the user has to do something, or generate a report).

*A.1.10 Current owner

The system can record details of the owner of a loaned or temporarily deposited object, or other object in the organization’s custody which does not belong to the organization.

A.1.11 Entry number

The system allows a unique number to be assigned to the entry of an object or group of objects and used to track objects prior to their return or acquisition. It should serve as the reference to written documentation of objects entering the organization for the first time. The number should be the one assigned to an entry form or receipt.

*A.1.12 Entry date

The system allows recording of a date on which an object or group of objects enters the organization.

A.1.13 Entry method

The system allows recording of the method by which an object or group of objects have entered the institution (for example, courier).

A.1.14 Entry manager

The system allows an individual to be noted as the person who accepted the object or objects into the building.

A.1.15 Depositor

The system can record the person or organization from whom a loaned or temporarily deposited object was obtained, if different from the Current owner or Lender.

A.1.16 Depositor's requirements

The system can record the requirements made by a depositor or owner concerning the deposit of an object or group of objects, including conditions for deposition of archaeological archives.

A.1.17 Entry note

The system allows for blank fields to record non-controlled vocabulary information related to the deposit of an object.

*A.1.18 Objects returned to owner

The system can record that deposited objects or object lots have been returned to the owner as required (for example, track that the objects have been returned with a return date).

A.1.19 Packing note

The system can record information about the way an object received was packed or stored.

*A.1.20 Return date

The system can record the date an object is due to be returned to or collected by the current owner or depositor.

A.1.21 Conditions on deposit

The system allows for recording of any conditions applied to the deposit of an object or objects (for example, storage or display requirements).

A.2 Acquisition and accessioning

The management and documentation of the addition of objects or object lots to the collection

The number of criteria in this section of the full checklist is 33.

*A.2.1 Accession by lot

The system can accommodate accessioning by object lot. This means that it can assign a unique local number to a group of objects that are being accessioned together. The separate objects in the lot may eventually be numbered separately.

*A.2.2 Unique system number assigned

The system can ensure that a unique system number is assigned to all objects or object lots.

*A.2.3 Local unique numbers

The system can accommodate non-system local unique numbering systems (for example, accession numbers in a wide variety of formats, Borden numbers).

*A.2.4 Object number

The system can record a unique number identifying an object or specimens, including any separated parts.

A.2.5 Previous number

The system can document previous number(s) assigned to the acquired objects or object lots.

A.2.6 Other number

The system can record an alternative number for an object other than the object number.

A.2.7 Other number type

The system can record a description of an other number assigned to an object.

A.2.8 Number of objects

The system allows a record of the number of objects at the next level down in an object record.

*A.2.9 Object name

The system can record a description of the form, function or type of object.

*A.2.10 Title

The system can record the name assigned to an object or group of objects by the artist/creator or collector at the time of origin or subsequent titles either specifically assigned or generally understood to refer to it.

*A.2.11 Brief description

The system can record a text description of an object in approximately one sentence; normally used for administrative and identification purposes. It records the most important information from a number of separate descriptive units of information.

A.2.12 Object history note

The system can record the history of an object, including its creation, owners, vendors and the circumstances surrounding such events. Record information here which has not been recorded elsewhere using controlled terminology.

*A.2.13 Source

The system can record source information (for example, acquisition source, title, surname, address) about objects or object lots.

A.2.14 Preferred pronouns

The system can accommodate the preferred pronouns of previous owners, artists, etc. This field should be completed according to an institution's collections or acquisition policies requiring expressed confirmation of preferred pronouns from owners, artists, etc.

A.2.15 Owner's personal experience

The system can record a description of how and why a particular object or group of objects is known to have been of particular importance to a previous owner.

A.2.16 Credit line

The system allows for text acknowledging a donation or loan, normally used on a display label.

A.2.17 Acquisition source

The system can record the people, person or organization from whom an object was obtained, if different from the owner. The Acquisition source may be an agent or other intermediary between the acquiring organization and the owner. For archaeological archives, use Acquisition source to record the excavating body responsible for preparing and depositing the archive with the organization.

A.2.18 Justification of acquisition

The system can record the justification for acquisition of an object or object lot (for example, reason for acquisition, supporting documentation).

A.2.19 Title transfer

The system can note the transfer of title to the acquiring institution (for example, method of acquisition, evidence of original title, signature confirming transfer of title, brief description of objects or object lots, and previous owner information).

A.2.20 Title transfer number

The system can assign a unique identifying number for a transfer of title or acquisition event. It should serve as the reference to written documentation of a transfer of title or acquisition process. The number may be assigned to a transfer of title form.

A.2.21 Accessions register maintained

The system can ensure that an accessions register is maintained, describing all acquisitions and listing them by number.

A.2.22 Acquisition reason

The system can record a reason or justification for an acquisition.

A.2.23 Acquisition authorization

The system can record the name of the individual or employee who authorized the acquisition and the date this occurred on.

*A.2.24 Acquisition date

The system can record the date on which the object or objects are acquired.

A.2.25 Acquisition funding

The system can record the method of funding for the object, including the amount provided and any conditions on the funding.

*A.2.26 Acquisition conditions

The system can record any conditions on the acquisition of the object, such as donor access or display requirements.

A.2.27 Purchase price

The system can record the price paid for acquisition (including taxes), both by lot and per individual object, along with currency information and any bargaining that may have occurred.

A.2.28 Acquisition note

The system can record general information about the acquisition.

A.2.29 Acquisition provisos

The system can record restrictions applying to the objects in a single acquisition, including conditions for deposition of archaeological archives.

A.2.30 Acquisition funding source provisos

The system can record restrictions applying to all the objects acquired with the support from an acquisition funding source.

A.2.31 Use restriction

The system allows for a record of the restrictions on the use to an object or group of objects.

A.2.32 Use restriction date

The system can record the date on which a Use restriction was recorded.

A.2.33 Use restriction note

The system can record additional information about the Use restriction of an object which has not been recorded elsewhere using controlled terminology.

A.3 Location and movement control

The management and documentation of information concerning the current and past locations of all objects/object lots in the institution's care to ensure that the institution can locate any object at any time

A.3.1 Object location information

The system can record where an object is located. See Location information for the place itself.

The number of criteria in this section of the full checklist is 22.

A.3.1.1 Record of permanent location

The system can provide a record of the location where an object or object lot is normally displayed or stored (for example, permanent location).

*A.3.1.2 Location field

The system allows the location field to be made mandatory, even if a location is ‘unknown’.

A.3.1.3 Location type

The system can record the type of location an object is stored in (for example, permanent, temporary).

*A.3.1.4 Location search

The system can retrieve information about objects or object lots by location.

A.3.1.5 Record of displaced objects

The system can provide a record of the location of an object or object lot when it is not in its previously assigned location (for example, current location).

*A.3.1.6 Object number

The system can display a unique number identifying an object or specimens, including any separated parts.

A.3.1.7 Normal location

The system can record the place within the organization where an object is normally located.

*A.3.1.8 Current location

The system can record the place within the organization where an object is currently located.

A.3.1.9 Location reference name/number

The system can record a unique name, number, or identifier for a display or storage location. It can also apply to a location on a computer system used for digital objects.

*A.3.1.10 Location date

The system can record date an object was placed at the current location can be entered.

A.3.1.11 Current location fitness

The system can record a term describing the extent to which an object’s current location is fitted to an object’s requirements.

A.3.1.12 Current location note

The system can record information about the reason for an object being at its current location.

A.3.1.13 Location address

The system can record the street address of a location if it is outside the main property of an institution.

A.3.1.14 Location access note

The system allows for an uncontrolled field to record any extra details about accessing an object in a location (for example, door size, how to open a case etc.).

A.3.1.15 Location condition note

The system allows for recording the environmental condition of a location.

A.3.1.16 Location condition note date

The system can record the date on which a note on the environmental condition of a location was observed.

A.3.1.17 Location security note

The system allows for notes on the security of a location.

A.3.1.18 Environment measurement type

The system can record the type of environmental measurement taken at a location.

A.3.1.19 Environment measurement value

The system can record the value of an environmental measurement taken at a location.

A.3.1.20 Environment measurement value unit

The system allows the unit of measurement used when measuring an aspect of a location’s environment to be recorded.

A.3.1.21 Environment measurement value qualifier

The system allows the measurement of accuracy used when measuring an aspect of a location’s environment.

A.3.1.22 Environment measurement date

The system can record the date on which an environmental measurement was taken at a location.

A.3.2 Moving objects

The management and documentation of object movement in, out of, and within an institution

The number of criteria in this section of the full checklist is 28.

*A.3.2.1 Previous location field

The system can ensure that when an object or object lot is relocated the previous location details, including date, are automatically transferred to a previous location field.

A.3.2.3 Previous location begin date

The system can record a date at which an object, or group of objects, began a stay at a previous location.

A.3.2.4 Previous location end date

The system can record a date at which an object, or group of objects, ended a stay at a previous location.

A.3.2.5 Date moved field

The system can automatically update the "date moved field".

A.3.2.6 Override date moved field

The system allows a provision to override the "date moved" field.

A.3.2.7 Location of parts

The system can attach distinct locations to parts of a single object, or single items within an object lot (for example, indicate that the teapot is on display, but the rest of the tea set is in storage).

A.3.2.8 Group relocation

The system allows for the relocation of a group of objects, including parts of a single object or items within an object lot, by globally changing the location while still maintaining controls and authorizations.

A.3.2.9 Temporary location

The system can issue a notification when temporary time limits on locations have been reached.

A.3.2.10 Person responsible

The system can record the person who moved objects or object lots.

A.3.2.11 Authorizing movements

The system can note the members of staff responsible for authorizing movements of objects or object lots.

A.3.2.12 History of authorization for object movement

The system can record the history of authorization of movements of objects or object lots.

A.3.2.13 Transfer

The system allows the transfer of responsibility for objects or object lots between collections within the institution (for example, transfer from costume to ethnology collection).

A.3.2.14 Movement audit trail

The system can provide an audit trail for any movement of objects or object lots across the physical or administrative boundaries of the organization.

A.3.2.15 Handling and packing

The system can document information about the handling, packing, storage and display of objects or object lots.

A.3.2.16 History of movement

The system can record an unlimited number of previous locations for an object or object lot.

A.3.2.17 Movement note

The system has an uncontrolled field for additional information related to movement of an object.

A.3.2.18 Movement reference number

The system can record a unique identifying number for the movement of an object or group of objects. It should serve as the reference to written documentation of a movement.

*A.3.2.19 Movement authorizer

The system can record a person giving final approval for a movement to take place.

*A.3.2.20 Movement authorization date

The system can record a date on which the movement authorizer gives final approval for a movement to proceed.

A.3.2.21 Movement reason

The system allows the entry of a reason or purpose for the movement of an object or group of objects.

A.3.2.22 Planned removal date

The system can record a date an object is due to be returned from a current location which is not its normal location.

A.3.2.23 Removal date

The system can record a date an object is actually removed from a current location.

A.3.2.24 Movement contact

The system can record the member of staff responsible for an object during the move.

A.3.2.25 Exit reference number

The system can record a unique identifying number for an exit. It should serve as the reference to written documentation of an exit. The number may be assigned to an exit note or receipt.

A.3.2.26 Delivery date

The system can record a precise date on which an object or objects leaving the organization is due to be delivered at its destination.

A.3.2.27 Expected return date

The system can record the date objects are expected to return to your buildings.

A.3.2.28 Expected return method

The way objects will be returned to your buildings.

A.4 Inventory

The maintenance of up-to-date information identifying all objects or object lots for which the institution has a legal responsibility, including objects on loan, not-yet-accessioned, or previously undocumented items and enquiries

The number of criteria in this section of the full checklist is 10.

*A.4.1 Object number

The system can display a unique number identifying an object or specimens, including any separated parts.

*A.4.2 Object name

The system can display a description of the form, function or type of object.

A.4.3 Number of objects

The system can display the number of objects at the next level down in an object record.

*A.4.4 Object location

The system can display details about the current location of objects or object lots.

*A.4.5 Object status

The system can indicate the status of all objects or object lots. For example, indicate whether the object or object lot is accessioned, not-yet-accessioned, loaned, exhibited, deaccessioned or missing).

*A.4.6 Basic physical inventory

The system can record basic physical inventory information (for example, record location, date inventoried, staff name).

A.4.7 Spot-checking (verifying inventory information)

The system can document the process of spot-checking to verify the location of an object or object lot, and other inventory information (for example, record the date checked, checker's name).

A.4.8 Distinguish between spot check and inventory

The system can distinguish between information that has been gathered during an inventory, and during a spot check (for example, field identifying whether the information was gathered during inventory or during spot check, or separate fields for inventory and spot check information).

*A.4.9 Recorder

The system can record the person recording the information.

*A.4.10 Recording date

The system can record the date information is added to the record.

A.5 Cataloguing

The compilation and maintenance of primary information describing, formally identifying, or otherwise relating to objects in the collection

The number of criteria in this section of the full checklist is 52.

*A.5.1 Object number

The system allows a unique number identifying an object or specimens, including any separated parts.

*A.5.2 Other number

The system can record an alternative number for an object other than the object number.

A.5.3 Other number type

The system can record a description of an other number assigned to an object.

*A.5.4 Object name

The system can display a description of the form, function or type of object.

A.5.5 Number of objects

The system allows the display of the number of objects at the next level down in an object record.

*A.5.6 Title

The system can display a name assigned to an object or group of objects by the artist/creator or collector at the time of origin or subsequent titles either specifically assigned or generally understood to refer to it.

A.5.7 Comments

The system allows for additional comments made about an object by visitors, curators or researchers.

*A.5.8 Brief description

The system can display a text description of an object in approximately one sentence; normally used for administrative and identification purposes. It records the most important information from a number of separate descriptive units of information.

*A.5.9 Distinguishing features

The system allows a description of features which could uniquely identify an object, bringing together details from other groups of units of information such as identification, inscription, and condition which could in a sentence uniquely identify an object.

A.5.10 Age

The system can record the numeric age of a natural science specimen when it died. Use Age unit to describe the unit of measurement used and Age qualifier to qualify the information. Use Phase for a textual description of Age.

A.5.11 Colour

The system can document the colour of an object.

A.5.12 Copy number

The system allows a number assigned to an object by the maker within a limited edition or special run.

*A.5.13 Dimension

The system can document an aspect of a part or component of an object being measured.

A.5.14 Dimension measured part

The system can document part of an object measured.

*A.5.15 Dimension value

The system allows the numeric value of the measurement of a dimension.

A.5.16 Dimension value date

The system can record the date on which the Dimension value was recorded.

*A.5.17 Dimension measurement unit

The system allows the use of a single term, without punctuation or capitalization, or use a standard abbreviation. Maintain a list of standard terms. The organization should decide which are the standard units for different dimensions and types of object.

A.5.18 Form

The system allows the use of a single term, without punctuation or capitalization. Maintains a list of standard terms.

A.5.19 Inscription content

The system can record the text inscribed as part of the decoration or construction of an object recorded in the original language.

*A.5.20 Material

The system can record the basic materials and media from which an object is constructed.

A.5.21 Object status

The system allows a statement of the standing of a natural science specimen or other object in relation to others in existence.

A.5.22 Phase

The system can record the textual expression of the age or developmental phase of a natural science specimen.

*A.5.23 Physical description

The system can document the general visual appearance of an object.

A.5.24 Sex

The system can document the gender of an animal specimen.

A.5.25 Style

The system can indicate styles or schools relating to an object.

A.5.26 Technical attribute

The system allows a technical attribute possessed by an object which can be described and/or quantified.

A.5.27 Responsible department/section

The system can indicate the department or section of the organization responsible for the management of the object or group of objects.

*A.5.28 Current location

The system can record the place within the organization where an object is currently located.

A.5.29 Location reference name/number

The system can record a unique name, number, or identifier for a display or storage location. It can also apply to a location on a computer system used for digital objects.

*A.5.30 Recorder

The system can identify the person recording the information.

*A.5.31 Recording date

The system can ensure date information is added to the record.

A.5.32 Ownership

The system can provide reference to ownership of the object or object lot.

*A.5.33 Object history

The system can document the history of the object or object lot (for example, historical data).

*A.5.34 Ownership history

The system can document the history of the ownership of objects or object lots.

A.5.35 Scholarly research

The system allows information produced by researchers to be recorded (for example, reference to research files, or actual research data).

A.5.36 Publication history

The system can record references to the object that appear in publications.

A.5.37 Frames and other supports

The system can document information about frames and other supports.

A.5.38 Reference to files

The system can allow an object record to include references to documents or records outside of the collections system.

A.5.39 Reference

The system can record details of a bibliographic or other reference to an object. The reference can be in any media, for example, published, unpublished, audio, video, computer record.

A.5.40 Reference author/editor

The system can record the person or organization responsible for the intellectual content of a referenced work.

A.5.41 Reference association

The system allows a single term describing the nature of the relationship between the reference and an object.

A.5.42 Reference details

The system can include details, pages, and illustrations of a bibliographic reference.

A.5.43 Reference note

The system can indicate details of the specific nature of the relevance of the reference to the object, including an abstract if required.

A.5.44 Reference number

The system can record a number or identifier unique to a reference.

A.5.45 Reference publication date

The system can indicate a date when a referenced work was published.

A.5.46 Reference publication place

The system can indicate the place where a referenced work was published.

A.5.47 Reference publisher

The system can record the organization or person responsible for the publication of a referenced work.

A.5.48 Reference title

The system can indicate the title of a referenced work.

A.5.49 Reference type

The system can record a term describing the nature of the reference.

A.5.50 Document location

The system can indicate where a referenced document is stored in an organization’s documentation system.

A.5.51 Catalogue number

The system can record an assigned number to an object in an exhibition catalogue.

*A.5.52 Whole or parts relationships

The system allows for the management of information about relationships between parts of a single object, between single items within an object lot, and between multiple objects.

A. 6 Object exit

The management and documentation of objects or object lots leaving the institution's premises

The number of criteria in this section of the full checklist is 15.

*A.6.1 Location information about accessioned objects

The system can maintain location information for accessioned objects or object lots leaving the institution's premises.

A.6.2 Maintain location information about unaccessioned objects

The system maintains location information for unaccessioned objects or object lots leaving the institution's premises.

*A.6.3 Responsibility

The system can record information about persons responsible for authorization of the dispatch of objects or object lots.

A.6.4 Transportation

The system can document details about transportation of objects or object lots.

*A.6.5 Exit reference number

The system creates a unique number for action of an object leaving the institution.

A.6.6 Delivery date

The system can record an anticipated date of delivery to their destination for objects that have left the institution.

*A.6.7 Exit date

The system can record the date an object has left the institution.

*A.6.8 Exit destination

The system can document the person or organization to whom the object is being sent.

*A.6.9 Exit reason

The system allows for the documentation of the reason why an object is leaving the institution.

A.6.10 Exit method

The system can record the method by which an object or group of objects leaves the organization.

*A.6.11 Expected return date

The system can document the date an object is expected to return to the institution.

A.6.12 Expected return method

The system can document transportation details for the return of the object.

*A.6.13 Exit authorizer

The system can indicate the person giving final approval for an object exit to take place.

*A.6.14 Exit authorization date

The system can record the date on which the exit authorizer gives final approval for a movement to proceed.

A.6.15 Exit note

The system allows additional information relating to the exit of an object which cannot be recorded elsewhere.

A. 7 Loans in (borrowing objects)

Managing and documenting the borrowing of objects for which the institution is responsible for a specific period of time and for a specified purpose, such as display, research, education, or photography

The number of criteria in this section of the full checklist is 17.

*A.7.1 Automatic loan number

For incoming loans, the system can automatically assign a unique loan number to objects or object lots within the loan. The unique number assigned to the loan of objects from outside the organization. The number should also refer to a file containing written documentation about the loan.

A.7.2 Loan in reference number

The system can create a unique number assigned to the loan of objects from outside the organization. The number should also refer to a file containing written documentation about the loan.

A.7.3 Establish periods

The system can designate fixed periods for incoming loans.

A.7.4 Special considerations

The system can document special considerations regarding borrowed objects or object lots (for example, maintain information about security requirements).

A.7.5 Loaned objects

The system can manage individual objects within an incoming loan (for example, one object from a group of loaned objects to be returned sooner than the rest).

A.7.6 Generate loan-in agreements

The system can generate incoming loan agreements to be signed by both borrower and lender before the loan commences.

*A.7.7 Loan in reason

The system can record the reason for the object to be loaned.

*A.7.8 Loan in begin date

The system can record the date on which the institution begins to borrow the objects.

*A.7.9 Loan in end date

The system can record the date on which the institution ends borrowing the objects.

*A.7.10 Lender

The system can record the organization or individual that is loaning the object.

A.7.11 Lender's authorizer

The system can record the name and contact information of the employee or individual associated with the lender who gives final permission for the loan to proceed.

A.7.12 Lender's authorization date

The system can record the date on which the lender authorizes the loan to proceed.

*A.7.13 Lender's contact

The system can record the contact information of the employee or individual managing the loan on behalf of the lender.

A.7.14 Lender's address

The system can record the address of the lender.

A.7.15 Loan manager

The system can record an employee or individual responsible for managing the loan on behalf of the institution or organization.

A.7.16 Loan in status

The system can provide status updates where in the process a loan is currently at.

A.7.17 Loan in status date

The system can track the dates for when a loan changes status.

A. 8 Loans out (lending objects)

Managing and documenting the loaning of objects to other institutions for a specific period of time and for a specific purpose, such as display, research, education, or photography

The number of criteria in this section of the full checklist is 30.

*A.8.1 Automatic loan number

For outgoing loans, the system can automatically assign a unique loan number to objects or object lots within the loan.

A.8.2 Establish periods

The system can designate fixed periods for outgoing loans.

A.8.3 Special considerations

The system can document special considerations regarding loaned objects or object lots (for example, maintain information about security requirements).

*A.8.4 History

The system can document the history of outgoing loans for each object or object lot within the loan.

*A.8.5 Loaned objects

The system can manage individual objects within an outgoing loan (for example, one object from group of loaned objects to be returned sooner than the rest).

A.8.6 Generate loan-out agreements

The system can generate outgoing loan agreements to be signed by both borrower and lender before the loan commences.

*A.8.7 Record of loans

For outgoing loans, the system can maintain a record of all loans, including details of the borrower, the venues, the loan period and the purpose of the loan.

A.8.8 Payments

For outgoing loans, the system can record and calculate payments by the borrowers.

A.8.9 Overdue loans

For outgoing loans, the system can track any objects or object lots within an outgoing loan that are overdue.

*A.8.10 Loan out reason

The system can indicate the reason why a loan out (lending) event is taking place.

A.8.11 Loan out note

The system can record general information about a loan out.

*A.8.12 Loan out authorizer

The system can record the name and contact information of the employee or individual who gives final permission for the outgoing loan to proceed.

*A.8.13 Loan out authorization date

The system can record the date on which the loan out authorizer gives final approval for a loan to proceed.

*A.8.14 Borrower

The system can record the individual or organization that has borrowed an object or objects on an outgoing loan.

A.8.15 Borrower's status

The system can indicate the status of the person or organization borrowing the objects.

*A.8.16 Borrower's contact

The system can record the contact information of the employee or individual managing the loan on behalf of the borrower.

A.8.17 Loaned object status

The system can provide status updates on where in the process an outgoing loan is currently.

A.8.18 Loaned object status date

The system can track the dates for when an outgoing loan changes status.

*A.8.19 Loan out begin date

The system can record the date on which you begin to lend the objects.

*A.8.20 Loan out end date

The system can record date on which you end lending the objects.

A.8.21 Special conditions of loan

The system can record a statement of conditions on the loan of an object from an organization in addition to those normally laid down.

A.8.22 Logistics of loans

The system allows the handling and insuring of objects loaned or borrowed.

A.8.23 Insurance activities

For incoming and outgoing loans, the system can record insurance activities such as requirements, insurer, appraisers, valuation, etc.

*A.8.24 Shipping activities

For incoming and outgoing loans, the system can record shipping activities such as schedules and references to files.

*A.8.25 Shipping resources

The system can generate documents for shipping (for example, shipping manifest, labels).

A.8.26 Link objects to cases

For incoming and outgoing loans, the system can link objects to packing cases.

A.8.27 Location tracking

For incoming and outgoing loans, the system can track the location of objects or object lots while on loan.

A.8.28 Packing cases

For incoming and outgoing loans, the system can track the location of packing cases.

A.8.29 Packing list

For incoming and outgoing loans, the system can generate packing lists.

A.8.30 Associated costs

The system can record and calculate costs associated with incoming and outgoing loans.

B.1 Condition checking and technical assessment

The object aspects of a condition or technical assessment

The number of criteria in this section of the full checklist is 16.

*B.1.1 Condition checking and technical assessment

The object aspects of a condition or technical assessment.

B.1.2 Completeness

The system allows a single term describing the completeness of an object.

B.1.3 Completeness date

The system can record the date on which the completeness of an object was recorded.

B.1.4 Completeness note

The system can indicate additional information about the completeness of an object which has not been recorded elsewhere using controlled terminology.

*B.1.5 Condition

The system allows a single term describing the condition of an object.

*B.1.6 Condition date

The system can record date on which the condition of an object was recorded.

*B.1.7 Condition note

The system can record a brief description of the condition of an object.

B.1.8 Conservation treatment priority

The system can record a term describing an object’s need for conservation treatment.

*B.1.9 Environmental condition note

The system allows a record of the environmental conditions in which an object is kept.

*B.1.10 Environmental condition note date

The system can record the date on which an environmental condition note applies.

B.1.11 Next condition check/assessment date

The system can indicate the date on which the next condition check or technical assessment is due.

B.1.12 Technical assessment

The system allows detailed assessment of the condition of an object and the required treatment.

B.1.13 Technical assessment date

The system can record the date on which a technical assessment of an object was recorded.

B.1.14 Hazard

The system can record the details of potential hazards to people or other objects that the handling and storing of an object can present.

B.1.15 Hazard date

The system can indicate the date on which a hazard was identified.

B.1.16 Hazards note

The system allows details of potential hazards to people or other objects that the handling and storing of an object can present which are not recorded using controlled terminology in Hazard.

B.2 Collections care and conservation

The documentation and management of information about the conservation of objects from a curatorial and collections management perspective

B.2.1 Conservation

The number of criteria in this section of the full checklist is 17.

B.2.1.1 Request for conservation

The system can record request or recommendations about conservation work for an object, object part, or object lot.

B.2.1.2 Examinations

The system can record the process and results of conservation examinations and any supporting documentation held by the institution, such as archival materials or contracts.

*B.2.1.3 Preventive measures

The system can record any preventative measures that are taken and any supporting documentation held by the institution, such as archival materials or contracts.

*B.2.1.4 Treatments

The system can record any remedial treatment and any supporting documentation held by the institution, such as archival materials or contracts.

*B.2.1.5 Conservation history

The system can document the history of the conditions and treatments of an object.

B.2.1.6 Notification of treatment call-backs

The system can send an email or other notification triggered by an event in the conservation workflow (for example, 5 years after an object is repaired or examined).

B.2.1.7 Access to information by unique local number

The conservation information is accessible via the object's unique local number (Borden number, accession number, etc.).

B.2.1.8 Conservation reference number

The system can generate a unique number for each conservation action.

B.2.1.9 Conservation authorizer

The system records the name and contact information of the employee or individual who authorized a conservation action.

B.2.1.10 Conservation authorization date

The system can record the date on which a conservation action was authorized.

B.2.1.11 Conservation method

The system can indicate the method used in the conservation of an object.

*B.2.1.12 Conservator

The system can record the individual who performs a conservation treatment.

B.2.1.13 Treatment begin date

The system can record the date at which the treatment of an object, or group of objects began.

B.2.1.14 Treatment end date

The system can record the date at which the treatment of an object, or group of objects ended.

*B.2.1.15 Treatment report

The system allows for a detailed description of the conservation treatment undergone by an object.

B.2.1.16 Conservation project management

The system has conservation project management capabilities such as assigning conservation related tasks, tracking of environmental readings, etc.

B.2.1.17 Integrated pest management

The system can record information regarding the institution's integrated pest management system (for example, types of traps, locations, schedules).

B.2.2 Risk management

The management and documentation of information relating to potential threats to an institution's own collection and the objects and object lots for which it is temporarily responsible

The number of criteria in this section of the full checklist is 4.

*B.2.2.1 Information on threats

The system can document information relating to potential threats to an institution’s collections.

*B.2.2.2 Preventive measures

The system can document information on preventive measures.

*B.2.2.3 Contacts and procedures

The system can maintain files of individuals and organizations to approach, and procedures to be followed in the event of a disaster.

B.2.2.4 Accountability

The system can enable accountability for any object or object lot during and after a disaster (for example, generate lists of objects by location, condition, or institution's liability).

B.3 Valuation

The number of criteria in this section of the full checklist is 4.

B.3.1 Valuation reference number

The system can generate a unique number for each appraisal action.

B.3.2 Valuation authorizer

The system can record the name of the employee or individual who authorized a valuation action.

B.3.3 Valuation authorization date

The system records the date on which a valuation action is authorized.

B.3.4 Valuation information confidentiality

The system can help to ensure that valuation information is treated in confidence and not released to anyone without the appropriate authority (for example, only authorized users can access the valuation information).

B.4 Insurance and indemnity

The documentation and management of the insurance needs of objects in an institution's permanent collection, and those for which it is temporarily responsible (such as loans or deposits). Valuation control is the management of information relating to the valuations placed on individual objects or groups of objects, normally for insurance/indemnity purposes.

The number of criteria in this section of the full checklist is 34.

*B.4.1 Object number

The system can display the reference numbers (accession, loan, in take, etc.) of the objects being covered

*B.4.2 Brief description

The system allows a text description of an object in approximately one sentence; normally used for administrative and identification purposes. It records the most important information from a number of separate descriptive units of information.

*B.4.3 Loan in reference number

The system allows a unique number to be assigned to the loan of objects from outside the organization. The number should also refer to a file containing written documentation about the loan.

*B.4.4 Appraisal

The system can document information about appraisals.

*B.4.5 Appraiser

The system can document information on people who perform appraisals.

B.4.6 Value history

The system can document information relating to the history of valuation placed on individual objects, object lots or other groupings of objects.

B.4.7 Insurance reference number

The system can generate a unique number for each insurance policy.

*B.4.8 Insurer

The system can record the company or organization that provides an insurance policy.

B.4.9 Insurance note

The system can provide an uncontrolled field for notes about insurance taken out on an object.

*B.4.10 Insurance amount

The system can record the amount of insurance cover that is provided in an insurance event.

B.4.11 Insurance amount currency

The system allows the use of institution specific currency

B.4.12 Insurance authorizer

The system can record the person giving final approval for an insurance event to take place.

B.4.13 Insurance authorization date

The system can indicate the date on which the insurance authorizer gives final approval for an insurance event to proceed.

*B.4.14 Insurance begin date

The system can record the date when an insurance policy begins to be active.

*B.4.15 Insurance end date

The system can record the date when an insurance policy stops being active.

B.4.16 Insurance note

The system allows the other information about an insurance event not recorded elsewhere.

*B.4.17 Insurance renewal date

The system can record the date when an insurance policy is due for renewal.

*B.4.18 Insurance policy number

The system can indicate the number of the insurance policy as assigned by the insurer.

B.4.19 Objects appropriately insured

The system can check that all the objects in an institution's care are appropriately insured (for example, report on insurance values, policy numbers, and policy expiry dates).

B.4.20 Insurance claim

The system can document all decisions and actions in the institution's response to insurance claim(s) including cross reference to paper files.

B.4.21 Notification of renewal

The system can provide notification when insurance policies need to be reviewed and renewed (for example, a reminder that the user has to do something or generate a report).

B.4.22 Indemnity reference number

The system can generate a unique number for each indemnity or indemnity agreement.

B.4.23 Indemnifier

The system can record the company or organization that provides indemnification of objects.

B.4.24 Indemnity authorizer

The system can record the name of the employee or individual who authorized an indemnity event.

B.4.25 Indemnity authorization date

The system records the date on which an indemnity event is approved.

B.4.26 Indemnity request date

The system records the date on which an indemnity request is made.

B.4.27 Indemnity confirmation date

The system can record the date on which confirmation of indemnity cover is received from the indemnifying body.

B.4.28 Indemnity note

The system can provide an uncontrolled field for notes about indemnity cover for an object.

B.4.29 Indemnity begin date

The system can record the date on which indemnity cover begins.

B.4.30 Indemnity end date

The system can record the date on which indemnity cover ends.

B.4.31 Indemnity request date

The system can record the date on which indemnity cover is requested.

B.4.32 Indemnity renewal date

The system records the date when an indemnity arrangement is due for renewal.

B.433 Indemnity confirmation date

The system records the date confirmation of indemnity cover is received from the indemnifying body.

B.4.34 Object minimum liability sum

The system allows for recording the sum for which the indemnified organization is responsible.

B. 5 Damage and Loss

The management and documentation of damage to, or loss of objects in your care

The number of criteria in this section of the full checklist is 7.

*B.5.1 Object number

The system can display the object number of objects owned by the institution.

*B.5.2 Entry number

The system can indicate an entry number for loans and any other objects that do not belong to you (for example, enquiries).

*B.5.3 Damage/loss date

The system can record the date when an object was first established as damaged or missing.

*B.5.4 Damage/loss method

The system can indicate the method by which an object or group of objects was damaged or lost to the collections

*B.5.5 Damage/loss note

The system allows for additional information about the damage or loss of an object.

B.5.6 Damage/loss reference number

The system can record a reference number for the damage event.

*B.5.7 Damage/loss reporter

The system can record the person reporting the damage to, or loss of, an object.

B. 6 Deaccessioning and disposal

The management of object disposals (transfer, sale, exchange, or destruction) and deaccessions (documentation of the disposal)

The number of criteria in this section of the full checklist is 18.

B.6.1 Transfer of title

The system can record the transfer of title to any receiving institution.

B.6.2 Approval

The system can ensure that deaccessioning does not occur without approval being recorded.

B.6.3 Legal title

The system can ensure that the institution has legal title to the object or object lot before commencing with deaccession or disposal (for example, will not allow user to fill in deaccession or disposal fields unless the institution has demonstrated legal title).

B.6.4 Audit trail

The system can keep an audit trail on objects or object lots that have been disposed of.

*B.6.5 Reason for disposal

The system can document the reason for disposal.

B.6.6 Disposal reference number

The system can generate a unique number for a particular disposal action or event.

*B.6.7 Disposal method

The system can record the method by which an object is disposed of for example, sold, destroyed.

*B.6.8 Deaccession date

The system can record the date on which an object is deaccessioned.

*B.6.9 Disposal date

The system can record the date on which an object is disposed of.

B.6.10 Disposal recipient

The system can record the people, person or organization receiving an object to be disposed of by way of transfer, gift or sale.

B.6.11 New object number

The system allows for entry of a new accession number given to a disposed object by the institution that it was transferred to.

*B.6.12 Disposal note

The system allows for an uncontrolled field to record any other information related to a disposal.

B.6.13 Disposal price

The system can record the amount of money an object sold for when disposed of.

B.6.14 Disposal conditions

The system can record any conditions on the disposal of an object for example, that it must be disposed of within the country.

B.6.15 Disposal proviso

The system can indicate restrictions applying to all the objects to be disposed of.

B.6.16 Disposal proposed recipient

The system can record the people, person or organization receiving an object to be disposed of by way of transfer, gift or sale.

B.6.17 Disposal authorizer

The system can indicate the person giving final approval for a disposal to take place.

B.6.18 Disposal authorization date

The system can record the date on which the disposal authorizer gives final approval for a disposal to proceed.

B.7 Rights management

The documentation and management of information about the reproduction of objects, including the preparation of images, casts, and models

The number of criteria in this section of the full checklist is 18.

B.7.1 Rights management

The system integrates a variety of rights management schemes (Canadian copyright, Creative Commons, other jurisdictions) into its workflow.

*B.7.2 Record copyright ownership

The system can document ownership of copyright of an object.

B.7.3 Use Restrictions

The system allows for a variety of use restrictions.

*B.7.4 Ownership of copyright of reproductions

The system can document the ownership of copyright of any reproduction.

B.7.5 Document information about reproductions

The system can document information about reproductions of objects, including images, casts and models.

B.7.6 Access to reproductions by unique local number

The system allows reproductions to be accessed via the unique local number (for example, if any type of reproduction exists can it be documented) and searched via the unique number (accession number, reproduction number, Borden number).

*B.7.7 Copyright

The system can record the copyright information for both the master digital image and its surrogates.

B.7.8 Right reference number

The system can record a unique number identifying a right.

*B.7.9 Right type

The system can identify a specific type of right being recorded in relation to an object, reproduction, or text.

*B.7.10 Right holder

The system can record the holder of the right associated with an object, reproduction, or text.

B.7.11 Right holder's contact

The system can record the organization or person designated by the right holder to be responsible for dealing with rights on their behalf.

*B.7.12 Right begin date

The system can record the first date on which a right is current.

*B.7.13 Right end date

The system can record the last date on which a right is current.

B.7.14 Right note

The system allows any details of the right not covered elsewhere.

*B.7.15 Photos/images related to collections management processes

The system can link images to specific collections management events (for example, photographs taken before and after a specific treatment to the conservation process).

B.7.16 Print images

The system can print any image.

B.7.17 Print image/text and copyright

The system allows the notification of copyright to be provided upon printing of images/text.

*B.7.18 Export images

The system can export images in a number of formats. High resolution for publishing, lower resolution for PowerPoint, social media use, online use.

B.8 Reproduction

Use to record information about a reproduction. Reference the object(s) that are reproduced using their Object number unit in the Object identification information group. For the management of rights associated with reproductions see the Rights information, Rights in information, and Rights out information groups.

The number of criteria in this section of the full checklist is 12.

*B.8.1 Object number

The system can record the reference number of the object with the right.

*B.8.2 Reproduction number

The system allows for a unique identifier for the reproduction.

B.8.3 Current reproduction location

The system can record the current location of a reproduction.

*B.8.4 Reproduction date

The system can indicate the date on which a reproduction was created.

B.8.5 Reproduction description

The system allows a description of features which could uniquely identify a reproduction.

*B.8.6 Reproduction location

The system can document the location of a reproduction.

*B.8.7 Reproduction creator

The system can document the individual or organization that created a reproduction.

B.8.8 Reproduction format

The system can specify the format of a reproduction (for example, TIFF, JPG).

B.8.9 Reproduction status

The system can specify the status of a reproduction, especially amongst copies (for example, master, working copy).

B.8.10 Reproduction type

The system can specify the medium of reproduction (for example, digital image; plaster cast).

B.8.11 Reproduction reason

The system allows for documentation of the reason a reproduction was made.

B.8.12 Reproduction requestor

The system can record the name of the individual or organization who has requested a reproduction be made, if any.

B.9 Use of collections

The management and documentation of how collections, including images and other reproductions of them, are used.

B.9.1 Use of collections

The system allows the management and documentation of how collections, including images and other reproductions of them, are used

The number of criteria in this section of the full checklist is 15.

B.9.1.1 Use reference number

The system can record a unique number assigned to the use of an object or group of objects. The number should also refer to a file containing all written documentation about the use.

B.9.1.2 Use request note

The system allows additional information about request for use.

B.9.1.3 Use type

The system can record a term describing the nature of the use event.

B.9.1.4 Use authorizer

The system can indicate the person giving final approval for a use to take place.

B.9.1.5 Use authorization date

The system can record the date on which the use authorizer gives final approval for a use to proceed.

*B.9.1.6 Use title

The system can record the name of a use event (for example, exhibition title).

*B.9.1.7 Use begin date

The system can indicate the date on which a use began.

*B.9.1.8 Use end date

The system can indicate the date on which a use began.

B.9.1.9 User

The system can record the person or organization researching, using, selecting or viewing an object or group of objects.

B.9.1.10 User’s contact

The system allows details of a person designated by the user to be responsible for dealing with the use on their behalf.

B.9.1.11 Use organizer

The system can indicate the person or organization organizing a use event (for example, exhibition, display, and demonstration).

B.9.1.12 Use venue

The system can indicate the place where a use takes place.

B.9.1.13 Use note

The system allows additional general use information.

B.9.1.14 Use provisos

The system can indicate the restrictions applying to the research or use of an object.

B.9.1.15 Use result

The system can record information about the outcome of the use.

B.9.2 Object user’s contribution information

The system can record information about an object contributed by a user of an object. See Use of collections information group for the procedure. Link to the relevant Use of collections information using the Use reference number.

The number of criteria in this section of the full checklist is 5.

*B.9.2.1 User's reference

The system allows the documentation of any additional reference to the object provided by a user for example, an event, object, document, person or organization.

*B.9.2.2 User’s role

The system can record the role of a user in relation to the object.

B.9.2.3 User’s personal experience

The system allows a description of how and why a particular object or type of object is of particular importance to a user.

B.9.2.4 User’s personal response

The system allows a description of the way in which a user responded intuitively to the object.

B.9.2.5 User’s contribution note

The system can record any observations or comments on a user’s contributions which the organization wishes to record, for example, the way in which the information was obtained or any discrepancies noted.

B.10 Collections review

Use to record an audit event. Reference the object(s) involved using their Object number unit in the Object identification information group.

The number of criteria in this section of the full checklist is 16.

*B.10.1 Collections review criterion

The system can indicate the criterion of a collections review that is being recorded.

*B.10.2 Collections review result

The system can record the result of a collections review for an object or group of objects for a collections review criterion.

B.10.3 Collections review result date

The system can indicate the date on which a collections review result was given to an object or group of objects.

B.10.4 Collections review action

The system can indicate an action to be taken to an object or group of objects as a result of a collections review.

B.10.5 Collections review reference number

The system can record a unique number assigned to the record of a collections review.

B.10.6 Collections review authorizer

The system can indicate the person giving final approval for a collections review to take place.

B.10.7 Collections review authorization date

The system can record the date on which the collections review authorizer gives final approval for a collections review to proceed.

B.10.8 Collections review title

The system can record the name given to a collections review.

*B.10.9 Collections review reason

The system can indicate the reason a collections review takes place.

B.10.10 Collections review method

The system can record the way in which the collections review is carried out.

B.10.11 Collections review manager

The system can indicate the person or organization responsible for carrying out the collections review.

B.10.12 Collections review note

The system allows for information about a collections review not recorded elsewhere.

B.10.13 Collections review status

The system can indicate the status of the process of carrying out a collections review.

B.10.14 Collections review status date

The system can record the date on which a Collections review status was recorded.

*B.10.15 Collections review begin date

The system can record the date on which a collections review begins.

*B.10.16 Collections review end date

The system can record the date on which a collections review ends.

B.11 Audit

The process to ensure that the object records match the physical reality of your collections (for example, location, accession number)

The number of criteria in this section of the full checklist is 13.

B.11.1 Audit reference number

The system can record a unique identifying number for the audit of an object or group of objects. It should serve as the reference to written documentation of an audit.

*B.11.2 Audit method

The system can indicate the method used to audit an object or group of objects.

B.11.3 Audit authorizer

The system can record the person giving final approval for an audit to take place.

B.11.4 Audit authorization date

The system can indicate the date on which the audit authorizer gives final approval for an acquisition to proceed.

*B.11.5 Auditor

The system records the person or organization carrying out an audit. The auditor is individually accountable for the object audit result.

B.11.6 Object number

The system displays the object number for objects belonging to you.

B.11.7 Entry number

The system displays the entry number for objects belonging to others.

B.11.8 Object audit category

The system allows a code indicating the priority of an object for auditing purposes.

B.11.9 Audit type

The system can indicate the type of audit carried out on an object, group of objects, or information.

*B.11.10 Object audit date

The system can record the date an object was last checked in its location.

B.11.11 Object audit information unit

The system can record the unit of information within an object record that was audited.

B.11.12 Object audit note

The system allows additional information about the result or circumstances of the audit of an object.

*B.11.13 Object audit result

The system can record the result of an audit of an object.

C.1 Exhibition management

The management and documentation of temporary exhibitions and permanent displays from the curatorial and collections management perspective

The number of criteria in this section of the full checklist is 8.

*C.1.1 Exhibitions & displays process

The system supports the management and documentation of both analog and digital exhibitions.

C.1.2 Analog and digital exhibitions

The system allows analog and digital exhibits to be coordinated or managed separately.

C.1.3 Object reservation

The system can place notices of reserves of objects or object lots for special events.

C.1.4 Document research

The system can document research for an exhibition or display.

C.1.5 Exhibition tracking

The system can document information about an exhibition's itinerary.

C.1.6 Object exhibition history

The system can document the history of exhibition activities.

*C.1.7 Exhibition history of objects

The system can document the exhibition history of specific objects.

*C.1.8 Online exhibit management

The system can create accessible web pages for online/digital exhibits.

C.2 Discipline features

Data fields and tasks related to specialized collections, topics or disciplines relevant to collections

The number of criteria in this section of the full checklist is 2.

*C.2.1 Discipline

The system has built-in modules or functions specific to discipline (for example, separate module for ethnology, history or fine arts).

*C.2.2 Specify modules

The supplier can provide a list of the disciplinary modules handled by the system.

C.3 Public access features

The number of criteria in this section of the full checklist is 22.

C.3.1 Search suggestions

The system can provide related objects of interest to users.

*C.3.2 Internet public access

The system can provide public access via internet.

*C.3.3 Subset access

Public users can define subsets at a level controlled by the institution.

C.3.4 Welcome display

The system allows the display of a user-defined introductory/welcome screen.

C.3.5 Crowd sourcing support

The system supports integration of crowd-sourced comments, tags and other documentation.

*C.3.6 Application Programming Interface (API)

An API provides access to a third party product to access and work with system data

*C.3.7 Online capacity

As well as online search, the system provides creation of tours and/or virtual exhibits or other displays.

C.3.8 Sharing

The system allows sharing of items (for example, Send a link or search result).

C.3.9 Mobile

The public access system supports use on mobile.

*C.3.10 Image display

The system supports International Image Interoperability Framework (IIIF) in its public access interface.

*C.3.11 Alternate language

The system allows the selection of an alternate language by the public.

C.3.12 Restart

The system can provide a continuously displayed option to restart a session.

C.3.13 Multiple databases

The system allows the public to select the database of choice (for example, if an institution has many departments, can the public select only one or two?).

C.3.14 View selected fields

The system allows viewing only selected fields.

*C.3.15 Search refinement

The system allows the public to refine searches, both by including other search criteria and amending existing ones.

C.3.16 Save searches

The public can create accounts to save searches and results.

C.3.17 Collect information from public

The system can collect information from the public.

*C.3.18 Print results

The system allows the public to print the results from searches.

C.3.19 Print control

The system allows the institution to control the format, content and the number of records to print.

C.3.20 Print pricing

The system allows a charge to be applied to printed outputs.

C.3.21 Printing of images

The system allows images to be printed by the public over the web.

C.3.22 Visitor statistics

The system can run statistics on visitors, hits, etc.

D.1 Metadata administration

The way in which metadata is stored, tracked and recognized

The number of criteria in this section of the full checklist is 6.

*D.1.1 Metadata standards

The system can follow any particular standard for recording metadata about multimedia files. List the standards (for example, National Information Standards Organization (NISO) standard, MPEG-7, Digital Imaging group (DIG35), International Press Telecommunications Council (IPTC).

*D.1.2 Metadata import/export

The system allows metadata about multimedia files to be imported/exported (for example, Exchangeable Image File Format (EXIF)).

*D.1.3 Metadata search

The metadata about multimedia files can be searched (for example, the user wants to find all the images created with a Canon scanner) in the system.

D.1.4 Recognition of metadata

The system can recognize existing metadata produced by digital equipment (for example, recognize and automatically read in metadata produced by a digital camera).

D.1.5 Language of metadata

The system flags the language of the metadata.

D.1.6 Display of metadata

The system allows users to view metadata for specified data fields, such as classification fields, and files, such as image files.

D.2 Multimedia files

The support and handling of metadata for multimedia files

The number of criteria in this section of the full checklist is 29.

*D.2.1 Indexing

The system's multimedia files are indexed.

*D.2.2 Sound files

The system supports sound files using standards supported by the institution.

*D.2.3 Associated sound files

The system can associate (link) sound files to an object.

*D.2.4 Image files

The system supports various common image file formats, such as *,jpg, *.gif and *.tiff, as well as specific image file formats required by the institution.

*D.2.5 Associated image files

The system can associate image files to an object and the image files can be viewed within the system.

D.2.6 Streaming data files

The system can accept and deliver streaming data.

D.2.7 Associated streaming data files

The system can associate link streaming data files to an object.

D.2.8 Animation files

The system supports Flash and non-Flash content.

D.2.9 Associated animation files

The system can associate (link) animation files to an object.

*D.2.10 3-D images

The system supports 3-D imaging. (*.mov, (movie) *.dwg (DraWinG)).

D.2.11 Associated 3-D files

The system can associate (link) 3-D files to an object or object lot.

D.2.12 Other files

The system allows other multimedia formats to be supported, including any file format currently in use by the institution. [Note: Formats to be listed by the institution.]

*D.2.13 View both images and text

The system allows images and text to be viewed together on the same screen.

D.2.14 Automatic production of multiple image resolutions

The system can automatically produce images into multiple resolutions for display within the system, for reports generated by the system or for export.

D.2.15 Options for display of images

The system allows users to have access to non-destructive editing features, such as dynamic rotate or resizing, that only change the way the image is displayed.

D.2.16 Image text descriptions

The system allows for verbal descriptions and ALT tags.

*D.2.17 Image captions

The system can record a caption that is to be displayed with the image.

D.2.18 Images per object

The system can associate multiple images with an object.

D.2.19 Maximum images

The supplier can provide the institution with information about the maximum number of images that can be associated with an object.

D.2.20 Tiling of images

The system can tile multiple images on the screen.

*D.2.21 Images stored in CMS

The database is capable of storing derivative image files.

D.2.22 Convert images

The system allows images to be converted to multiple image file formats and resolutions.

D.2.23 Reference to original images

The system can document information about the original image (for example, image reference number, classification, storage location).

D.2.24 Retrieval by image characteristic

The system can enable image retrieval by image characteristic (for example, find images of objects that are a certain colour (blue), shape (round) or layout (portrait/landscape)).

D.2.25 Search object and image info

The system can search object information and image information at the same time (for example, search for the name of a photographer in both object record and image record).

D.2.26 Image editing

The system can provide functionality for editing digital images (for example, colour correct, rotate, resize, resample).

D.2.27 Management of digital files

The system can rename, move, copy digital object files (WAV (waveform audio file), AVI (audio video interleave), JPG, etc.).

D.2.28 Multimedia plug-ins

The system can use plug-ins required by the institution.

*D.2.29 Export images

The system can export images in a number of formats. High resolution for publishing, lower resolution for PowerPoint, social media use, online use.

D.3 Data field structure

The way in which data fields are defined

The number of criteria in this section of the full checklist is 4.

D.3.1 Date

The system's date format can be defined by the institution (yyyymmdd etc.).

D.3.2 Money

The system can record money ($99999.99) with the number of characters (for example, 12) required by the institution.

*D.3.3 Variable-length fields

All fields can be stored as variable length fields in the system.

*D.3.4 Fixed length fields

A field can be defined as fixed length when needed in the system.

D.4 Data validation

The number of criteria in this section of the full checklist is 11.

*D.4.1 Numeric

Numeric values can be validated (for example, integer only for a specific field such as number of items in a lot) in the system.

*D.4.2 Real

The system can validate real values (for example, decimal numbers).

*D.4.3 Alphabetic

Alphabetic values can be validated in the system.

*D.4.4 Upper/lower case

The system can validate that values are the correct mix of upper or lower case (for example, Borden number = AaAa).

*D.4.5 Date

The system allows the validation of data values.

D.4.6 Data entry tools

The system supports data entry tools to facilitate validation (for example, date pickers).

D.4.7 Time

The system can validate time data type (for example, hh:mm:ss).

D.4.8 Fixed-length

The system can validate fixed length values (for example, enter data which exceeds the field length, update, retrieve and display).

D.4.9 Minimum/maximum value

The system can validate minimum/maximum values (for example, minimum value is 1 and/or maximum value is 10).

D.4.10 Pattern matching

Values can be matched against a pre-defined pattern (for example, Canadian postal codes, US zip codes) in the system.

D.4.11 Input masks and smart data validation

The system supports input masks and/or smart data validation.

D.5 Data update

The manner in which the system keeps data current

The number of criteria in this section of the full checklist is 5.

*D.5.1 Real-time updates

Updates are processed as soon as they are made in the system.

*D.5.2 Batch updates

Updates can be grouped and processed in a designated sequence (for example, several changes made to different records and processed in a batch) in the system.

*D.5.3 Global updates

Updates can be processed against all records (for example, one change made to all records) in the system.

D.5.4 Validation batch updates

Validation can be applied to batch updates in the system.

D.5.5 Validation global updates

Validation can be applied to global updates in the system.

D.6 Indexing of fields

The process of data indexing tasks performed by the system

The number of criteria in this section of the full checklist is 3.

D.6.1 Multiple fields to one index

The system can allow one index to be used to search on many fields (for example, the index name could be location and under the index named location would be all the location fields like room, cabinet, drawer).

D.6.2 Concatenation of fields and character string

The system allows the field and a character string to be concatenated to create a single entry in the index.

D.6.3 Updates indices automatically

The system has indices that are updated automatically and immediately whenever a change (addition, update, deletion) in an indexed field occurs.

D.7 Vocabulary control

D.7.1 Authority control

For the purposes of this document, "authority" should be taken to mean a simple list of permissible terms (not arranged hierarchically) to be used during data entry and/or retrieval.

The number of criteria in this section of the full checklist is 13.

D.7.1.1 Authority control with software

Authority control is available within the software.

*D.7.1.2 Update authority lists procedure

The system can provide a separate procedure to update an authority list.

*D.7.1.3 Develop authority lists

Authority lists can be developed within the software.

D.7.1.4 Fields with authority control

The system allows the user to choose the fields for authority control.

*D.7.1.5 Integrate pre-built authority lists

External pre-built authority lists can be integrated into the software at any time.

D.7.1.6 Authority lists for entry and validation

The system has authority lists that can be used to assist in the entry and validation of data (for example, user can select from the authority list during data entry).

*D.7.1.7 Authority lists included in the system

The supplier can provide a list of authority lists that are included in the system.

D.7.1.8 Authority lists for search

The system has authority lists that can be used to assist in the formulation of search criteria (for example, user can select from the authority list to help select terms to enter as search criteria).

D.7.1.9 Update authority lists in entry mode

The system can add terms to authority lists and update these lists without leaving the data entry mode.

D.7.1.10 Authorization to alter authority lists

The system can control permissions to add, change, and delete terms in an authority list to ensure that a specific user is authorized to make changes.

D.7.1.11 Print authority lists

The system allows all authority lists to be printed.

D.7.1.12 Several authority lists used within one field

The system can handle several different authority lists used within a single field (for example, Object Name field has separate term list for Textile department, Ethnology department).

*D.7.1.13 Deletion/change of terms - implications for records

The system can handle the change or deletion of an authority term if the term is currently used in the records.

D.7.2 Thesaural control

For the purposes of this document, "thesaurus" is taken to mean a list of terms showing hierarchical, synonymous, and other relationships.

The number of criteria in this section of the full checklist is 26.

*D.7.2.1 Thesaural control with software

Thesaural control is available within the software.

D.7.2.2 Update thesaurus files procedure

The system provides a procedure to update a thesaurus file.

*D.7.2.3 Developed thesauri

Thesauri can be developed within the software.

*D.7.2.4 Fields with thesaural control

The user can choose the fields for thesaural control.

*D.7.2.5 Integrate pre-built thesaural files

External pre-built thesauri (for example, Thesaurus of Geographic Names, Art & Architecture Thesaurus, or a locally-built thesaurus that is already in use by the museum) can be imported and integrated with the system.

D.7.2.6 Thesauri for entry and validation

The thesauri can be used to assist in the entry and validation of data in the system (for example, user can browse and select from the thesaurus during data entry).

D.7.2.7 List pre-built thesauri files

The supplier can list the pre-built thesauri files that are included in the system.

D.7.2.8 Thesauri integration

The system can incorporate linked data authorities such as the Getty vocabularies

D.7.2.9 Thesauri for search

The system allows thesauri to be used to assist in the formulation of search criteria (for example, user can browse and select from the thesaurus to help select terms to enter as search criteria).

D.7.2.10 Thesauri for term expansion during retrieval

The system allows Thesauri to be used during the retrieval process to expand a users’ search to include synonyms and narrower terms (for example, if a user searches for “Painting”, the system invokes the thesaurus to include narrower terms like “Watercolour”).

D.7.2.11 Equivalent term retrieval

Misspellings or alternate spellings will yield relevant search results (for example, 'Watercolour' and 'Watercolor')

D.7.2.12 Update thesaurus files in entry mode

The system supports terms that can be added or updated for the thesaurus files without leaving the data entry mode.

D.7.2.13 Authorization to alter thesaurus

The system can provide a control over who can add, change, and delete terms in a thesaurus file.

D.7.2.14 Homonyms within thesaurus

The system can handle homonyms within the thesaurus and prompt users towards options (for example, "drum" as a percussion instrument or as a container).

D.7.2.15 Thesaurus viewed hierarchically

The terms in the thesaurus can be viewed and browsed hierarchically in the system.

D.7.2.16 Unauthorized term

The system can create and use an unauthorized term which can then be marked for review at a later date.

D.7.2.17 Print thesauri files

All thesaurus files can be printed.

D.7.2.18 Display all thesaurus information

The system can display all information associated with a thesaurus term (for example, relationships, definition, scope notes, etc.).

*D.7.2.19 Several thesauri used within one field

The system allows for more than one thesauri to be linked in a single field (for example, Object Name field has separate thesauri for Textile department, Ethnology department, etc.).

D.7.2.20 Monolingual and multilingual thesaurus, ISO (International Standards Organization) standard

The system can support ISO 25964-1:2011 - Information and documentation -- Thesauri and interoperability with other vocabularies -- Part 1: Thesauri for information retrieval.

*D.7.2.21 Development of multilingual thesauri

Multilingual thesauri can be developed within the software.

D.7.2.22 Development of monolingual thesauri

Monolingual thesauri can be developed within the software.

D.7.2.23 Change of terms - implications for records

The system can handle the change of a thesaurus term if the term is currently used in the records.

D.7.2.24 Change of terms - implications for narrower terms

The system can handle the change of a thesaurus term which has narrower terms linked to it.

D.7.2.25 Deletion of terms - implications for records

The system can handle the deletion of a thesaurus term if the term is currently used in the records.

*D.7.2.26 Prevent deletion of terms which have narrower terms

The system will prevent the user from deleting a thesaurus term which has narrower terms linked to it.

E.1 Help features

The number of criteria in this section of the full checklist is 9.

*E.1.1 Default data entry/update screen(s)

The system can provide default data entry and update screen(s).

E.1.2 Tutorial available

The system has an integrated tutorial.

E.1.3 On-line help

The system can provide on-line help.

E.1.4 Help on request

The system only offers help when requested.

E.1.5 Context-sensitive help

When the help function is invoked, the information displayed always relates to the process being executed in the system (for example, while in query invoke help).

*E.1.6 Help at the field level

The system has help available to describe the proper content of a field during data entry or retrieval.

E.1.7 Self-explanatory help

The system's on-line help is self-explanatory (must not consist only of codes that requires the operator to consult a manual).

E.1.8 User-defined help

The system allows users to add to or change the current help information.

E.1.9 User-built help file

The system allows users to build their own help files (for example, adding help for a field which currently does not have help).

E.2 Data entry

The number of criteria in this section of the full checklist is 22.

E.2.1 Repeatable field

The system allows a field entry to be flagged as being repeatable for subsequent entries until the flag is removed.

*E.2.2 Repeatable multiple entries

The system allows multiple entries to be flagged as being repeatable for subsequent entries until the flag is removed. (batch/bulk update)

E.2.3 Record duplication

The system allows data duplication to be performed automatically at the record level.

E.2.4 Default values

The system allows any data field to be assigned a start-up default value that will be automatically entered for new entries (for example, department name).

*E.2.5 Mandatory fields

The system allows any number of fields to be flagged as mandatory.

E.2.6 Override mandatory fields

The system allows mandatory fields to be temporarily overridden.

E.2.7 Calculated fields

The system allows field entries to be calculated from other field entries or constants (for example, taxes are set at a fixed rate and calculated automatically).

E.2.8 Cut and paste

The system allows cut and paste operations (for example, cut a field and paste it to another field within the same document).

E.2.9 Fields copying

The system allows copying of fields selectively from one record to another (for example, copy two fields from an existing document into a new document).

E.2.10 Data formatting

The system can support text format standards (italic, bold, underline, etc.).

E.2.11 Macros

The system can record information inside macros to speed data entry (for example, create a new document, update, retrieve and display).

E.2.12 Hot-key

The system allows macros to be executed for data entry purposes by pressing special key combinations (for example, Ctrl + R will execute a macro to print the document that has been entered).

E.2.13 Search and replace within record

The system can offer a search and replace function within a single record during the data entry process (for example, identify a source name, search for the name within one record only, and replace with new text).

E.2.14 Search and replace between records

The system can offer a search and replace function between records during the data entry process (for example, identify a source name, search for the name across the database, and replace with new text).

*E.2.15 Import data from other sources for part/entire records

The system can draw date from required formats, such as MS Office, open source files, etc.

E.2.16 Field level controls

The system allows the institution to set controls over mandatory/optional settings for each field to set the default value of a field and to apply input masks.

E.2.17 Date pickers

The system includes a date picker.

*E.2.18 Spell checker

There is an on-line spell checker in the system.

E.2.19 Autocompletion

Frequently used terms will be offered as autocompletion in the system.

E.2.20 Language of spell checker

Users can choose the language of the spell checker in the system.

E.2.21 Add terms to spell checker

Users can add terms to the spell checker in the system.

E.2.22 Hyperlinks

The system supports the use of hyperlinks (for example, within record fields).

E.3 Date formats

The number of criteria in this section of the full checklist is 9.

*E.3.1 Date format

The system supports date formats required by the institution.

*E.3.2 Date entry

The system supports date pickers and pop-up calendars.

E.3.3 Date searching

The system can specify the date format for searching.

E.3.4 Date display

The system can specify the date format for display.

E.3.5 Date output

The system can specify the date format for output (for example, reports).

*E.3.6 Attribution dates

The system supports approximate dates (for example, prior to, later than, circa, ?, BC, AD).

E.3.7 Date conversion

The system can convert dates to a standard format (for example, when entering dates different formats (050596, 05 MA 96, 05 May 1996, 19960505, 960505) can be entered and the system will convert to a standard format).

*E.3.8 Unknown dates

The system allows unknown dates to be entered as such (for example, unknown).

E.3.9 Fuzzy dates

The system handles date spans like 'circa' and can calculate results based on spans.

E.4 User customization

The number of criteria in this section of the full checklist is 4.

*E.4.1 Data entry screen(s)

The system allows users to customize the layout of data entry screens.

*E.4.2 Data retrieval screen(s)

The system allows users to customize data retrieval screens (for example, on the data retrieval screen change a field label, retrieve and display a document).

E.4.3 Field tags (labels)

The system allows users to customize field tags (labels) on the data entry screen (for example, while in the data entry screen change a field label, display document).

E.4.4 Error messages

The system allows users to customize error messages (for example, generate an error message, change the wording in the error message, invoke new error message).

E.5 Multilingual

The number of criteria in this section of the full checklist is 6.

*E.5.1 Alternate language

The system can function in an alternate language.

E.5.2 Language selection at login time

The system allows an alternate language to be selected at login time.

E.5.3 Language selection on any screen

The system allows an alternate language to be selected from any screen.

E.5.4 English or French information

The system allows all information to be displayed in either language (for example, English or French).

E.5.5 English and French information

The system allows all information to be displayed in both languages (for example, English and French).

*E.5.6 UTF-8 (Unicode transformation format)

The system supports at least Unicode UTF-8 character-set standard.

E.6 Web integration

The number of criteria in this section of the full checklist is 10.

*E.6.1 Access via internet

The system can provide access through a web browser.

*E.6.2 Offline data entry

The system allows data collection offline and uploaded/imported later

*E.6.3 Consistent between platforms

The system can provide full functionality through a web browser.

*E.6.4 Cross-platform browser support

The system can operate in chrome, Firefox, Safari, Ede on PC and Mac.

E.6.5 Software as a service (SaaS)

The system can be provided as a cloud-based Software as a service.

E.6.6 Scalable hosted storage

The system can store large amounts of data, will be able to increase in response to repository growth.

E.6.7 Access via mobile/tablet

The system can be used on a mobile device.

E.6.8 Metrics

The system can provide metrics on the online use of the collections (object views, object sharing).

E.6.9 Up-to-date data management

The system offers a Java or web-based client for admin and data management.

E.6.10 Open access

The system supports data sharing and partnership initiatives with third-party platforms including content aggregators, nonprofit and for-profit companies.

E.7 Accessibility

The system supports tools for ensuring the user interface and content is accessible to people with disabilities.

The number of criteria in this section of the full checklist is 4.

E.7.1 Alternative formats

The system supports alternate formats for accessibility.

*E.7.2 Input methods

The system offers a choice of input methods (keyboard, touchscreen, speech).

*E.7.3 Output methods

The system offers a choice of output methods (keyboard, touchscreen, speech)

*E.7.4 Web Content Accessibility Guidelines (WCAG) Compliance

The system is compliant with WCAG.

F.1 General requirements

The number of criteria in this section of the full checklist is 7.

F.1.1 Query using native language

A query can be executed using the query native language in the system.

*F.1.2 Formatted screens

The system can use formatted screens to execute a query.

*F.1.3 Query any field

A query can be run against any field in the system.

*F.1.4 Boolean AND

The system allows the boolean operator AND to be accepted.

*F.1.5 Boolean OR

The system allows the boolean operator OR to be accepted.

*F.1.6 Boolean NOT

The system allows the boolean operator NOT to be accepted.

F.1.7 Nesting expressions

The system can enter nested searching expressions in the command line or search box (for example, First Name=TOM AND ((Surname=SMITH) OR (Surname=BROWN)) to a level required by the institution.

F.2 Range searches

The number of criteria in this section of the full checklist is 5.

F.2.1 Search operators

The system allows range searches using the =,<,> operators are accepted (for example, find artists whose birth dates are greater than or equal to 1950).

F.2.2 Range searches on numeric fields

The system allows range searches on numeric values (for example, find all objects in the database that have a value between $5,000 - $10,000).

F.2.3 Range searches on date fields

The system allows range searches on date fields (for example, find all objects that were accessioned between May 12, 1999 and June 14, 2000).

F.2.4 Using attribution dates

In the system, date arithmetic can be performed on date fields with attributions (for example, there is data that is c1945. Find everything from 1920-1944 will be including a search of ‘c1945’).

F.2.5 Range searches on character fields

The system allows range searches on alphanumeric fields.

F.3 Wildcard searches

The number of criteria in this section of the full checklist is 4.

F.3.1 Right truncation wildcard

The use of wildcards at the end of a stem is always accepted (for example, book*).

F.3.2 Left truncation wildcard

The system allows the use of wildcards at the beginning of a stem (for example, *book).

F.3.3 Wildcard on any field

The system allows the use of wildcards on any field.

F.3.4 Character substitution

The system allows the use of wildcards for any character substitution (for example, "sm*th" finds both "smith" and "smyth").

F.4 Query results

The number of criteria in this section of the full checklist is 14.

*F.4.1 Save results

The system allows the results from a query to be saved for future use. (Not saving the query, but saving the results from the query).

*F.4.2 Export results

The system can export query results into excel documents.

F.4.3 View results in alternative format

The results of the query can be displayed and formatted in the data entry screen in the system.

F.4.4 Default format

The system has a default record display order.

F.4.5 Object display order

The system has a default field display order.

F.4.6 Define default field display order

The system allows the default field display order to be changed.

F.4.7 Field display

The system can select the fields to be displayed.

F.4.8 Forward, backward browsing

The system can browse forward and backward through individual records and/or groups of records.

F.4.9 Carry forward

When viewing a record that has many screens, the system can carry forward basic information which identifies the record (for example, unique key, accession/catalogue number, object lot).

F.4.10 Relative position

The system can indicate the relative position of the current screen within the record or set of records being displayed (for example, Screen N of N or Record N of N).

F.4.11 Access to related objects

The system can retrieve and display related objects based on their whole/part relationship (for example, retrieve a record with a whole/part relationship, display all related information).

F.4.12 Sort results

The system allows results from a query to be sorted by various fields (for example, perform a query, sort results on 3 different fields and display the documents).

F.4.13 Ascending

The system allows results from a query to be sorted by various fields in ascending order (for example, perform a query, sort the results in ascending order, and display the documents).

F.4.14 Descending

The system allows results from a query to be sorted by various fields in descending order (for example, perform a query, sort the results in descending order, display the documents).

F.5 Features

The number of criteria in this section of the full checklist is 19.

F.5.1 Phonetic (sounds like) searching

The system offers phonetic (sounds like) searching (for example, hyda/haida).

F.5.2 Using natural language

The system allows queries to be created using natural language phrases (for example, would the system find the relevant records if a user typed in "find all the dolls that are currently on exhibit"?).

F.5.3 Adjacency or proximity searching

The system allows searches for words or expressions adjacent to or within a specific number of words of another word (for example, find all occurrences of the word "stained" when it is within two words of "glass").

F.5.4 Presence/absence searching

The system allows searches for the presence of a value or expression or for the absence of a value or expression (for example, search for the presence of a value, then search for the absence of a value).

F.5.5 Non-indexed fields

The system allows searches to be performed on non-indexed fields.

*F.5.6 Multiple field searches

The system allows a search to be performed on multiple indexed and not-indexed fields.

F.5.7 Query hitlist

The system can browse through lists of previous queries.

F.5.8 Number of hits

The system can inform the user of the number of hits (query results).

F.5.9 Display of query results

Upon receiving the number of hits in a search, the system can give the option to proceed with the display.

*F.5.10 Search refinement

The system can refine search results with new search criteria (for example, a search was done for Tom Thomson paintings; a new criteria is used to find the Emily Carr paintings in the same result set).

F.5.11 Narrow the search scope

The system allows the scope of a result set to be narrowed (for example, a search was done for works by Tom Thomson; a new criteria can be added to narrow the result to sketches only).

*F.5.12 Filter search

Search results can be filtered by facets in the system.

F.5.13 Search history

The system can provide a facility for displaying previous search results.

F.5.14 Review results in query mode

The system can view the results from a query without having to exit the query function.

F.5.15 Modify query

Once a query has been executed, it can be modified for re-execution in the system.

*F.5.16 Save query

A query can be saved for future use in the system.

*F.5.17 Print query results

Query results can be printed from the system.

F.5.18 Simple (Google style) search

The system has a simple Google-type search interface available to the public.

F.5.19 SQL (Structured Query Language) compatibility

The system supports SQL standard for data queries.

G.1 Pre-defined reports

Ways in which users can define the outputs of system-created reports

The number of criteria in this section of the full checklist is 12.

G.1.1 Pre-defined reports provided

The system comes with a series of pre-defined reports that can be generated in file formats required by the institution.

G.1.2 List pre-defined reports

The system can list the pre-defined reports available (for example, accession/catalogue number, artist/maker, object, source).

*G.1.3 Change pre-defined reports

The system can change a pre-defined report.

G.1.4 Save changed reports

The system can save a changed report as a new report for future use.

G.1.5 Specify sort order

The system allows the user the flexibility to specify the sort order of a pre-defined report.

G.1.6 Frequency report

The system can provide a frequency report for any field (for example, Object Name - 10 dolls, 5 chairs).

G.1.7 Concatenated fields

The system can provide a frequency list for any concatenation of fields (for example, Object Name, Object Type (10 chairs; rocking, 11 chairs; arm)).

G.1.8 Count of terms

The system can provide a frequency report on a count of unique terms (for example, a query for Tom Thomson finds 300 works. Provide a frequency list for the object name field - 100 paintings, 200 sketches).

G.1.9 Records processed

The system can provide a frequency report with totals (for example, total number of records processed).

G.1.10 Off-line object worksheets

The system allows the user to work off-line on printed or electronic worksheets and use the system to synchronize changes for the database.

G.1.11 User input

The system can provide a pre-defined report in columnar format with user input required (for example, pre-defined report with six columns, user specifies the fields, headings, and the width of columns).

G.1.12 Modify report format

The system allows users to temporarily change a pre-defined report.

G.2 User defined reports

G.2.1 General requirements

The system offers ways in which users can choose and limit data for reporting.

The number of criteria in this section of the full checklist is 20.

*G.2.1.1 User defined reports

The system allows users to define reports.

G.2.1.2 Copy and modify reports

The system allows the user to copy an existing report, modify it and create a new report.

*G.2.1.3 Saving reports

Newly created reports can be saved for re-use in the system.

G.2.1.4 Labels

The system can create labels using any fields defined by the user.

G.2.1.5 Generate form(s)

The system offers a report generator that can generate a form (for example, legal form).

G.2.1.6 Include/exclude fields

The system has a report generator allows any field(s) to be included or excluded from a report.

G.2.1.7 Full boolean search

The system offers a report generator that allows the use of boolean searches.

G.2.1.8 Sort on any field

The system offers a report generator that sorts on any field.

G.2.1.9 Ascending sort

The system offers a report generator that sorts fields in ascending sequence.

G.2.1.10 Descending sort

The system offers a report generator that sorts fields in descending sequence.

G.2.1.11 Calculates totals

The system has a report generator that calculates totals (for example, total insurance value for the entire collection).

G.2.1.12 Calculate sub-totals

The system has a report generator that calculates sub-totals (for example, total insurance value for entire collection by department with sub-totals).

G.2.1.13 Columnar reporting

The system has a report generator that produces columnar reports (for example, select a group of records, sort by object number, print these fields in columns - object number, object, location).

G.2.1.14 Redefine field names

The system has a report generator that allows for field names to be customized when printed (for example, Object Name field name changed to Name of Object).

G.2.1.15 Report browsing

The system allows users to browse reports.

G.2.1.16 Indication of progress

When a report is run on-line, the system displays an indication of progress (for example, scale or percentage completed).

G.2.1.17 Report display on screen

The system allows a user to view the output from a report on the screen.

G.2.1.18 Reports printed

The user can print the output from a report in the system.

G.2.1.19 Reports saved on disk

The system allows users to save reports on disk (for example, save output form report, retrieve report from disk and display).

G.2.1.20 Reuse saved output

The system allows the saved output from the report to be reused (for example, retrieve the saved report from G.2.1.20 and display in a word processing package, csv, Excel or PDF).

G.2.2 Formatting features

Ways in which users can define the look of reports

The number of criteria in this section of the full checklist is 4.

G.2.2.1 Text formatting

The system supports text format standards including diacritics and different fonts.

G.2.2.2 Document formatting

The system supports document formatting including headers and footers, margin control.

G.2.2.3 Date produced

The system has a report generator that outputs the date that the report was generated.

G.2.2.4 Date formats

The system has a report generator that outputs the date that the report was generated in various date formats selected by the user.

G.3 Document production

Ways in which users can define the outputs of system-created reports

The number of criteria in this section of the full checklist is 3.

*G.3.1 Templates

The system has the functionality to edit report and other templates by users. It is possible to change report templates without system customization.

G.3.2 Web Reports

The system can create reports in accessible HTML.

G.3.3 Emails

The system can generate emails based on user-defined triggers.

G.4. Visual representation of data

The system offers features that would allow users to see broad data categories through visual representations, rather than through lists.

The number of criteria in this section of the full checklist is 3.

G.4.1 Browsing taxonomies

The system can highlight or visually represent characteristics of taxonomies, such as taxonomy structures, or usage and search statistics.

G.4.2 Temporal data

Temporal data can be rendered through timelines or other forms of visualization in the system.

G.4.3 Geographic data

The system can render geographic data through maps, floor plans or other visualization formats.

H.1 Import/export functions

H1.1 Import files

The number of criteria in this section of the full checklist is 12.

H.1.1.1 List of file types

The suppler has provided a list of all file types that can be imported into the system without customization.

*H.1.1.2 Field selection available

The system can import American Standard for American Interchange (ASCII) files and load the information into specific fields (for example, create a word processing file containing information for Accession number and Object name; import to specific fields).

*H.1.1.3 Summary report

The system can generate a summary report for the import function listing such things as number of records read, rejected, accepted, etc.

H.1.1.4 Field validation

The system can perform field validation when importing data.

*H.1.1.5 Duplicate checking

When importing records, the system can check for duplicate records.

H.1.1.6 Duplicate checking defined by database administrator

When importing records, the system can check for duplicate records based on a key defined by the database administrator.

H.1.1.7 Bypass field validation

The system can permit bypassing of field validation during imports and generate appropriate error reports.

H.1.1.8 Hold for verification

For records that have failed data validation during import, the system can produce an error report or hold these records for user verification (for example, import data with an invalid term to an authority-controlled field).

H.1.1.9 Long fields

The system can provide a report if data has been rejected or truncated on import.

*H.1.1.10 Import extensible markup language (XML)

The system can import in XML.

H.1.1.11 List XML import standards

List the XML import standards followed (for example, Dublin Core or Spectrum) by the system.

*H.1.1.12 Specify import formats

The system offers import formats that are required by the institution (for example, CHIN Microtext, delimited ASCII (American Standard for Information Interchange), MARC (Machine Readable Cataloguing), or SGML (Standard Generalized Markup Language).

H.1.2 Export files

The number of criteria in this section of the full checklist is 11.

*H.1.2.1 Fixed length records

The system can export ASCII files having fixed length records.

*H.1.2.2 Variable length records

The system can export ASCII files having variable length records.

*H.1.2.3 Field selection available

The system has an export function allows the selection of fields to be exported (for example, export the Accession number and Object name data from records imported).

H.1.2.4 Summary report

The system can generate a summary report for the export function listing such things as number of records read, number of records exported, etc.

H.1.2.5 Flag data records

The system can flag the record(s) that have been exported.

H.1.2.6 Flag data fields

The system can flag the fields that have been exported.

H.1.2.7 Dynamic Data Exchange

The system supports Dynamic Data Exchange (DDE) or equivalent (for example, link to a range of cells in a spreadsheet).

H.1.2.8 Object linking & embedding

The system supports object linking and embedding or equivalent (for example, link to (or embed) a Word document within a text field).

H.1.2.9 Specify export formats

List other export formats that are supported by the system (for example, CHIN Microtext format, delimited ASCII, MARC)

*H.1.2.10 Export for linked data

The system exports data in at least one RDF (resource description framework) serialization (for example, JSON-LD (javascript object notation for Linked Data), RDF/XML (extensible markup language), Turtle (terse RDF triple language) etc.).

*H.1.2.11 Export XML

The system can export in XML in a standard or schema (for example, Dublin Core or Spectrum) or customizable format.

H.1.3 Interface with other software

The number of criteria in this section of the full checklist is 10.

*H.1.3.1 Word processor

The system allows data to be imported from and exported to word processing software.

*H.1.3.2 Attachments

The system allows document attachments from many types of software to a specific record.

H.1.3.3 Spreadsheet

The system allows data to be imported from and exported to spreadsheet software.

*H.1.3.4 Import/Export to other software

The system has other software package types that interface (import/export) with the software.

*H.1.3.5 Import/Export to other software - digital asset management system (DAMS)

The software can be integrated with a DAMS.

*H.1.3.6 API

The system has an API provided for harvesting by third party websites and other systems for data sharing.

H.1.3.7 API documentation

There is full documentation of the API provided by the supplier or in the system.

H.1.3.8 ODBC (Open Database Connectivity) Compliant

The system allows queries to be performed from outside the institution using ODBC.

*H.1.3.9 Interoperability

The system can exchange data with other systems based on interoperability standards (for example, OAI, Dublin Core).

H.1.3.10 Open source

The system is open source.

H.2 Special features

Data fields and tasks related to special forms or types of information relevant to collections

The number of criteria in this section of the full checklist is 15.

H.2.1 Customization by the supplier

The software can be customized by the supplier.

H.2.2 Customization by the user

The software can be customized by the user.

H.2.3 Customized sort table

The system allows sort tables to be customized to change the order (collating sequence) of the results (for example, sort accession numbers in a logical order).

H.2.4 Saving sort table

The system allows a modified sort table to be saved for further use.

*H.2.5 Multi-tasking

The system lets the user interrupt what they are doing to perform other tasks.

H.2.6 Reminder function

The system can interrupt a user to do other tasks.

H.2.7 Measurement conversion

The system can automatically convert and display imperial and metric measurements.

H.2.8 Converts measurements on reports

The system can automatically convert imperial and metric measurements for reports.

H.2.9 Selection of measurements

The system allows users to select preferred measurement units for data entry, display, reports, etc.

H.2.10 Overrides converted measurements

The system can change the values of the converted measurements (for example, change converted measurements while in data entry mode).

*H.2.11 Supports scannable codes

The system supports barcode, RFID, (radio frequency identification) and QR (quick response) code information.

H.2.12 Bar code labels

The system can produce bar code labels.

H.2.13 Bar code software

Bar code support software comes with the system.

H.2.14 Support bar-code scanners

The system allows information scanned by a bar code scanner to be loaded into the collections management system at a later time.

H.2.15 Supports optical character recognition (OCR)

The system supports OCR.

I.1 Documentation and Support

The number of criteria in this section of the full checklist is 15.

*I.1.1 User documentation

The supplier can describe options for user documentation, release notes and updating documentation.

I.1.2 User documentation - language

The supplier provides documentation in both official languages.

I.1.3 Number of copies

The number of printed copies of the documentation provided by the supplier is acceptable to the institution.

I.1.4 On-line documentation

All documentation is available on-line.

*I.1.5 Documentation for new users

A ‘quick start’ version of the full documentation is available to support new users.

I.1.6 System documentation

The supplier can fully describe the components of the system, including base software.

*I.1.7 Help desk support

The supplier can fully describe help desk options, costs and availability.

I.1.8 Help desk support - language

The supplier can provide support in both official languages.

I.1.9 Help desk support

The supplier offers different levels of support packages.

I.1.10 Support hours

Support within 24 hours of contact?

*I.1.11 Data dictionary formats

The system's data dictionary is available electronically or online, and it is included as part of the documentation package.

I.1.12 Customized modules

The system can be customized to add functions specific to disciplines (for example, separate module for ethnology, history or fine arts) and are able to migrate through system updates.

I.1.13 Source code provided

The system has rights associated with the source code are acceptable to the institution, such as open-source or source held in escrow.

I.1.14 Protection

The supplier agrees to have a machine-readable copy of the full source code for all the purchased software, plus necessary supporting documentation, delivered to an agreed third party at the time of installation and with each new release.

I.1.15 Institution’s rights if the supplier withdraws from business

The supplier can confirm and provide proof that the institution will have the right to maintain and develop the collections management system itself if the supplier withdraws from business or from supplying the system.

I.2 Training

The number of criteria in this section of the full checklist is 7.

*I.2.1 Training included with software

The supplier can describe and provide costs related to all training options, including specialized and customized training (for example, security and control, backups, and system administration).

I.2.2 Third-party training

Third-party suppliers are in place to provide training.

I.2.3 On-site training

The training will be provided at the client site.

I.2.4 Remote training

The training will be provided remotely.

I.2.5 Training - multilingual

Training can be provided in other languages.

I.2.6 Train-the-trainer option

The supplier can provide or support a train-the-trainer program.

I.2.7 Additional training materials

The supplier offers additional training materials on their website including webinars, tutorials, wikis, demos, etc.

J.1 Security

The way in which the system handles the identity of users and the control and tracking of permissions to change data

The number of criteria in this section of the full checklist is 13.

*J.1.1 Multi-level security

The system provides security for different levels of user (for example, sdministrator, data rntry clerk, curator, public access, scholarly research).

*J.1.2 User ID security

The system requires user-id for access to the system.

*J.1.3 Password security

The system requires all users to enter a password for access to the system.

*J.1.4 Password administration

The system has procedures for initiating and changing passwords.

J.1.5 User function security

The system allows system administration to define security at the function level (for example, allow a user to access data entry functions only).

J.1.6 User profile security

The system allows you to create task-specific environments for different groups of users. Read/write privileges for different fields based on group.

J.1.7 File security

The system allows system administration to control access, for different levels of user, to one or more specific files.

J.1.8 Field(s) security

The system provides controls to limit access to one or more specific fields within the system (for example, amending location information).

J.1.9 Record(s) security

The system provides controls to limit access to a specific record or group of records within the system.

J.1.10 Security by discipline

The system provides controls to limit access to one or more specific disciplines within the system.

J.1.11 Record amendment security

The system requires when a record is being amended by a user, that record is protected from being changed or deleted by other users in the system.

*J.1.12 Record locked & available

The system requires when a record is being amended by a user, that record is available to other users in read-only mode.

J.1.13 Record locked & not available

The system requires when a record is being amended by a user, that record is unavailable to other users.

J.2 Indexing

The administration of indexing activities

The number of criteria in this section of the full checklist is 2.

*J.2.1 Change of index

System administration can change the index of any field.

J.2.2 Restructuring of affected indexes

The system can be used while indexes are being rebuilt.

J.3 Back up

The system’s role in creating and storing back-ups of data, interfaces, configurations, metadata, data structures, reports, etc.

The number of criteria in this section of the full checklist is 12.

J.3.1 Backup and recovery process

The software has a built in backup and recovery process.

J.3.2 Back-end database back-up and recovery

The standard functionality of the back-end database will completely backup and recover the system. This includes data, settings, transactions, users, interface, etc.

J.3.3 On-line backup

The system allows online backup in a multi-user environment.

J.3.4 On-line recovery

The system allows on-line recovery in a multi-user environment.

J.3.5 Backup process

The system has a built in backup process or can use the standard functionality of the back-end database for back-ups.

J.3.6 Backup process – SaaS (Software as a service)

Hosted, SaaS solution regular backup is provided automatically.

J.3.7 Recovery process

The system has a built in recovery process or can use the standard functionality of the back-end database for recovery

J.3.8 Backup time

The supplier can offer estimates on the time to execute the back-up procedure. Briefly describe the estimated time to execute the backup procedure.

J.3.9 Recovery time

The supplier can offer estimates on the time to execute the recovery procedure. Briefly describe the estimated time to execute the recovery procedure.

J.3.10 Automate backups

The system has a backup process that can be automated. Briefly describe how the backup process is automated.

J.3.11 Automate recovery

The system has a recovery process that can be automated. Briefly describe how the recovery process is automated.

J.3.12 Downtime

The system can provide 98% or above uptime.

J.4 Audit reports

Options for reporting on the system itself, rather than the data in the system

The number of criteria in this section of the full checklist is 14.

*J.4.1 Audit report on data

The system provides a report of all newly created/amended/deleted records (for example, display the report of all newly created/amended/deleted records).

*J.4.2 Deleted records

The system's audit reports contain all of the contents of deleted records.

*J.4.3 Audit report on changes

The system provides a report of all changes in a record.

*J.4.4 User access profiles

The system provides a report of all user access profiles.

J.4.5 Assigned tasks

The system offers workflows and tasks that can be assigned to a user. Notifications sent to user

*J.4.6 Audit report on user activity

The system provides a report by user id of login/logout time on the system over a specific period (for example, list login/logout times for each user).

J.4.7 Automated notification

Specific activity in the system will send an alert to another user.

J.4.8 Audit report on module activity

The system provides a report of functional usage by user ID of system activity over a specific period (for example, list the number of times each type of system activity (report, query, accession) was accessed on a certain day by a user.

J.4.9 Audit trails/edit history

The system has modifications viewed in the audit log that can be rolled back if necessary

J.4.10 Audit module usage

The system provides a report by system activity on user access over a specific period (for example, for each system activity (report, query, accession, etc.) list each user who accessed on a particular day).

J.4.11 Query report

The system provides a report of the queries performed by users.

J.4.12 Further supplier demonstration

The supplier will be given the opportunity to demonstrate features that are not included here related to system limits (for example, database size, number of records, number of fields, number of users).

*J.4.13 System limits

The system can support the number of objects managed now and anticipated to be managed in # years.

J.4.14 Technical limitations

The system has technical limits. Document the technical limitations of the system (for example, maximum number of users, concurrent users, query length).