Scenario 3: Automatic population at item level

John Doe has configured the electronic document and records management system (EDRMS) to notify Eva Smith when a file is registered and available for her use. She wishes to place the email ‘Discussion issues’ into the system. She wrote the email on 15th October relating to internal discussions on the development of the Widget Zinger marketing and communication plan, but registers it into the system on 27th October. The metadata that is created at record object level is:

Note: the example below uses a single entity (Record) representation for simplicity. See Implementing as a single entity – record for more information.

Element name	Sub element name	Metadata value assigned	Automatically assigned (A) or manually filled (M)
Category		Item	A (defaulted for all end user interaction.)
Identifier	Identifier String	63045/07	A (this has been set up in configuration to allocate the next available number in a predefined numbering pattern defined for record objects.)
	Identifier Scheme	Department of Nice Things EDRMS Document Numbering Scheme	A (defined as default at set up / configuration.)
Name	Name Words	Discussion Issues	A (originally assigned by Eva Smith to the email, but when entering it into the EDRMS the system picks up the Email subject line. This is configured by John Doe to be free text at document level, so there is no associated scheme.)
Date Range	Start Date	2007.10.15	A (should be able to be inherited from the email properties, but in some circumstances Eva may have to change the default date to reflect the date she created the document.) Note: registration date is noted in Relationship: Change History
Format	Creating Application Name	Microsoft Windows XP Professional	A (default to inherit from email system properties.)
	Creating Application Version	5.1 2600 Service Pack 2 Build 2600	A (default from email system properties.)
Extent	Logical Size	7	A (default to inherit from email system properties.)
	Units	KB	A (default to inherit from email system properties.)
Relationship: Category		Provenance Relationship	A (at time of file/folder creation, provenance relationships should be established by the creating agent. After set up it would default to recording ‘recordkeeping event relationships’, but should either be able to be changed to provenance relationships should new items be placed in the file, or the action of placing an item in the container should trigger the creation of an instance of a ‘provenance relationship’.)
Relationship: Name	Name Words	Contains	A (recording containment relationships is mandatory in a single entity implementation. Therefore at set up this is the most likely relationship to be documented. This will be a reciprocal relationship with the file/folder level above.)
	Name Scheme	Archives New Zealand Technical Specifications for Electronic Recordkeeping Metadata Standard, v1.0, Appendix C4.1 Provenance Relationship Name Scheme	A (this value would be set up as a default for all provenance relationships established in the drop-down list. If John amends or adds to the scheme, the reference would be to the Department of Nice Things Relationship Name Scheme.)
Relationship: Date Range	Start Date	2007.10.27	A (date of the relationship established, inherited from the network system clock.)
Relationship: Related Entity	Assigned Entity Identifier	07/3456	A or M (this represents the file/folder into which the email is being contained. It would be desirable for these containment relationships to be automatically captured by the EDRMS, but this requires careful configuration.)
	Assigned Entity Identifier Scheme	Department of Nice Things EDRMS File Numbering Scheme	A (defined as default at set up / configuration.)
	Relationship Role	2	A (this represents that the relationship is read in the direction of the object – that is that the document ‘contained in’ the file, a passive relationship.)
Relationship: Change History		Eva Smith, Senior Marketing Analyst, 2007.10.27, registered	A (in the Department of Nice Things configuration, all events are captured automatically, and all are assigned to this metadata element following the workaround for single entity implementation.)
Agent Category		Person	A (a default has been set up to identify individuals when they interact with the EDRMS.)
Agent ID		PN 2346	A (Eva Smith’s personnel number – associated with her by the system as she is established as a user within the system.)
Agent Name		Eva Smith	A (Eva’s name – inherited from her user log on and password.)
The following metadata might be captured if optional metadata requirements were implemented.
Description		Rough notes on issues to be included in the first plan for the Widget Zinger.	M (Eva would need to create this unless there was an automatic synopsis, or it was determined that the first sentence of the document would be an adequate description, or some other defaulting technique is deemed suitable.)
Language		En (English)	A (default to English at set up.)
Document Form		Email	A (recognised by the system, established from encoding scheme.)
The following metadata would be inherited from the file level above
Keyword	Keyword Terms	Marketing – Develop Plans – Marketing and Communications Plans – Widget Zinger 2007	A (inherited.)
	Keyword Scheme	Department of Nice Things Records Classification Scheme	A (inherited.)
	Keyword Scheme Type	Functional	A (default established at set up.)
Security Classification		Unclassified	A (Default from the keyword classification scheme which has determined that only specific areas are subject to security controls, and Marketing is not one.) Note: This should be able to be changed at document level at the user’s discretion. When that occurs, it should trigger a reciprocal inheritance, that is, the container should be upgraded to reflect the security contents. This would not affect other items contained which would retain their existing security classification
Rights	Rights Statement	All internal users are to comply with Department of Nice Things records use policy. Permission to change is granted to the creating Department. All other users must have written permission to change from creating Department.	A (inherited from file/folder level as default, but should able to be changed if required by end user.)
	Rights Type	Use Permission	A (inherited from file/folder level as default, but should able to be changed if required by end user.)
Disposal	Disposal Authority	DA 793	A (inherited from file/folder level.)
	Disposal Class ID	17.5.3	A (inherited from file/folder level.)
	Disposal Action	Destroy six years after file closed	A (inherited from file/folder level.)
	Disposal Trigger Date	31.12.2008	A (inherited from file/folder level.)
	Disposal Action Due	1.1.2015	A (inherited from file/folder level.)
Medium		Hard Drive Intranet Server	A (inherited.)
Business	At the Department of Nice Things, there is no independent management of business. It is assumed to be in the keyword classification scheme. Therefore there is no separate metadata for Business
Mandate	At the Department of Nice Things, there is no independent management of mandates. Therefore there is no separate metadata for Mandate

All of the metadata attributed to the item detailed above would ideally be automatically captured into the system using defaults, inheritance and reciprocal relationships. Eva might, if she wished, add a manually configured description, but this would be optional.

The ideal situation in configuring an EDRMS is to reach a position where the end user only has to complete one or two elements manually and all the rest is automatically captured or configured for them. This remains a challenge, but the diagram below represents those elements that can be assigned, or configured to be automatically completed for an object or item.

Figure 11: Options for automatic population of metadata at record object / item level (Click for larger image)

Menu

Technical Guide: Implementing Recordkeeping Metadata in EDRMS: Tailoring the Technical Specifications for the Electronic Recordkeeping Metadata Standard

Scenario 3: Automatic population at item level

Footer