Your name:

Joanna Newman

Your organisation (if applicable):

Wellington City Council

Your role in organisation (if applicable):

City Archivist

Contact email address:

Joanna.newman@wcc.govt.nz

Contact phone number:

XXXXXXXX

I am making this submission:

as an individual

on behalf of my organisation a

General Feedback: Please Evaluate the Standard against its Goals

agree

disagree

1

2

3

4

5

The standard will support and improve government recordkeeping in New Zealand.

a

The standard clearly specifies minimum requirements for the creation and maintenance of public records and local authority records under the Public Records Act.

a

The standard will enable organisations to assess their recordkeeping capability against the Public Records Act requirement to create and maintain full and accurate records.

a

Overall

Overall, this is a useful standard, with good guidance for recordkeepers.

In general, language could be simplified. Some of the most glaring ones are dealt with below but I would recommend that some thought be given to ‘plain English’ in final editing.

As with the Create and Maintain Standard, the wording of Risks means that often they are not the real risk to the organisation, or sometimes just a description of the behaviour/action which will create the risk. Given that the aim of this column is presumably to highlight benefits to the businesses of following the standard, I think it is worth making them a bit stronger in some cases. Many comments below relating to Examples of Risk are therefore aimed at making it clearer what the risk is to the organisation.

The glossary is quite sloppy and could have done with a bit more checking before being sent out.

Executive Summary

2

Needs proof-reading/editing

Line 3/4 - “. . . they must have context. This is provided by recordkeeping metadata.” (recordkeeping metadata is not another word for context)

Line 5 – delete establish in front of principles

Line 1, para 2 – recordkeeping metadata does not enable creation – delete “creation”

Line 3, para 3 – delete “email” and “heading” – all the rest are information types not field names.

Line 4 – “as reliable” – not guaranteed. Improves reliability but nonsense subject could be entered. Delete “reliable” – “evidence” will do.

Para 5 – Believe the fact that it applies to electronic records is very important and should a) come at the beginning of this para and b) be in a sentence of its own e.g. “This standard applies to electronic records only. It is mandatory for all . . . and universities, but discretionary for state and integrated schools.”

Para 6, line 1. Fullstop; capital I for If

1.3

6

Bad verb – recordkeeping metadata can’t “interact” with processes

Suggest change to something like “is one aspect of”

2.2

9

Bullet 2 - Recordkeeping metadata is not going to make corporate information more comprehensive.

Bullet 4 – Should be explained better than by “through enhanced recordkeeping capability”

Bullet 8 – Doesn’t say how metadata helps transfer etc, which is the point being made presumably

Delete, and change to “improved long-term availability of corporate information”

Would something like “by ensuring their appropriate and timely transfer to archival repositories” say what I think you really mean?

3.1

13

Over-use of “recordkeeping”

Delete “recordkeeping” in front of “metadata elements”

3.1

14

“emerging consensus set of elements” – bad English

Suggest changing to “the emerging consensus on a set of elements”

3.1

14

“from which individual agency implementations” – use of extra words for the sake of it.

Suggest changing to “from which individual agencies will be able to draw”

3.1

14

Last para – this is the first instance of what, for this reader, was quite confusing information about whether the technical specifications were mandatory or not. This says they are not mandatory then says “organisations are required to use” and “should adhere to the minimum requirements”.

Need to consider whether there is a core set of metadata which is mandatory and, depending on the decision, review wording throughout the document.

3.2

14

Bullet 1 – this is the first instance of another problem which occurs a number of times in the document, where the term “adequate records” is used. (These comments apply equally to the frequent use of “full and accurate records”.) The way it is used implies that a record includes all the metadata, but the definition in the glossary does not say this. If record is used in the sense defined by the glossary, capturing contextual detail alone is not going to be sufficient to “ensure that adequate records are maintained”

Bullet 3 – capturing metadata won’t necessarily ensure transactions are managed as records.

Suggest changing to a real risk “to ensure that records can be understood and interpreted in future”

Suggest changing to “inability to manage transactions . . .”

4

15

“lightly modified application profile of” – what on earth does this mean

Rewrite/simplify

4

15

Last para – “The relationship and structuring of this standard in relationship to other standards”

Change to “The structure of this standard and its relationship to other standards”

4.1

18

Examples of Risk – “requirements are not outlined in organisational policies” – not the real risk to the organisation

Suggest changing to: Recordkeeping metadata is non-existent or inconsistent because it is not set out in the organisation’s information policies.

4.2

19

Examples of Risk – “clearly defined roles . . . will not be assigned” – not the real risk to the organisation

Suggest changing to: Metadata schema are not developed and recordkeeping metadata not maintained because roles and responsibilities not assigned.

4.2

19

Examples of Risk – “documentation . . . will be undermined” – not the real risk to the organisation

Not entirely sure what you’re getting at here but suggest changing to: Unauthorised changes may be made to metadata schema and elements.

4.2

19

Examples of Risk – “employees are unaware of how to carry out their recordkeeping responsibilities” – not the real risk to the organisation

Suggest changing to: Those responsible for recordkeeping metadata do not carry out their roles adequately, resulting in poor metadata.

4.3

20

Examples of Risk – “full and accurate records are not maintained” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Suggest changing to: Unauthorised or inappropriate changes are made to metadata, resulting in records losing context and becoming inaccessible.

4.4

21

Examples of Risk – “Meaning (semantics). . .”

“Meaning” will do just fine!

Delete “(semantics)”

4.4

21

Examples of Risk – “the recordkeeping framework . . . not reliable” – not the real risk to the organisation

Suggest changing to: Records are not reliable because users cannot trust or understand the meaning of metadata

4.4

21

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation. (This also becomes more meaningless the more frequently it is repeated.)

Delete

4.5

22

Requirement - Sentence structure/terminology obfuscates meaning

Suggest changing to “Metadata in all business-critical systems which create records must be mapped to the record-keeping metadata schema.”

4.5

22

Examples of Risk – “Transactions in business systems . . .” – not clear enough what the risk is

Suggest changing to: Transactions in business-critical systems are not managed as records, therefore not available as evidence of business activity when required.

4.5

22

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Delete

4.6

23

Examples of Risk – “Inappropriate management of records.” – too vague

Delete

4.7

24

Explanation - “Technical specifications outline five entities as appropriate to implementing. . .” – unnecessarily complicated; obscures meaning.

Simplify to: “Technical specifications outline five metadata entities.”

4.7

24

Explanation - Mention of “minimum” requirements several times, including “organisations must comply with the minimum requirements.” Are the Technical Specifications mandatory or not?

Clarify whether Tech Specs are mandatory or not and check wording here and elsewhere in the standard.

4.7

24

Examples of Risk – “Organisations are unable to defend their records of business action resulting in increased exposure to litigation and business risk” – meaning unclear, link to requirement and explanation not clear.

Hard to determine what was being intended here, but could it be something like: Organisations are unable to defend their lack of contextual and other information about records, resulting in increased exposure to litigation.

4.7

24

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Delete

4.8

25

Requirement – the terms used here do not tie in with those used in the Technical Specifications, which is not helpful to users.

Also, “title” is a field name, and it would be better to suggest field content (like the others) e.g. subject rather than this.

What does “What business is being conducted” mean? Perhaps an example would help.

Use the same terms as in the Tech Specs, which are supposed to be a model.

Change title to “meaningful summary of content” or similar.

4.8

25

Explanation – apart from being unnecessarily wordy, use of tem “full and accurate record” is used again – see comment above under 3.2.

“Without these minimal metadata elements reconstruction of a record is impossible.”

Decide with ‘a record’ includes all the metadata or not and adjust text throughout the document accordingly.

Change to: Without these minimal metadata elements, reconstruction of a record’s context is impossible.

4.8

25

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Delete

4.9

26

Requirement – check terms are used in Tech Specs

4.9

26

Explanation – unnecessarily wordy.

Simplify

4.9

26

Examples of risk – “Records context cannot be determined . . . integrity.“ – risk could be clearer

Suggest changing to: Actions taken on a record, and responsibility for them, cannot be determined, resulting in inability to interpret meaning accurately, vouch for authenticity or trust the record.

4.9

26

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Delete.

4.10

27

Explanation – “. . . the Technical Specifications represents a record minimum”. See earlier comments. Presumably this is either a minimum and should therefore be mandatory, or it is not? Page 14 says the Tech Specs are “not mandatory”, therefore how can they be the minimum requirement in a mandatory standard?

Sort this one out.

4.10

27

Explanation – unnecessarily wordy; suggest more use of plain English.

E.g. why not “meaning”, instead of “semantics”?

How about “Extensions often involve adding terminology commonly used in a specific discipline or industry.”

4.10

27

Examples of Risk – Not clear why “costly and time consuming re-keying of metadata” is a risk

If it is because you’ll have to add it later if you haven’t thought about it at the start of implementation, clarify this.

Princ 3

Intro

28

What does “sustain” mean? Suggest a word which makes meaning clearer.

e.g. accompany?

3.11

28

Explanation: Here we seem to have an alternative ‘definition’ of a record to the one that is used in the glossary (see comments under 3.2). If this is the definition of record meant for this standard, I suggest this is reflected in the glossary. However, because it is the first time it has been stated explicitly the ‘record’ includes all the metadata, all previous comments have assumed that it only referred to content.

Even here, it could be better expressed . . .

Suggest changing to “Records consist of . . . .associated with its management and context.”

3.11

28

Examples of risk: one doesn’t justify authenticity

Change to “establish”

3.11

28

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Delete.

3.12

29

Examples of Risk – “Full and accurate records . . .” – too vague; see comment above re “adequate records”; not the real risk to the organisation

Delete.

3.13

30

Would be helpful to clarify in the intro that this means removal of metadata from its association with the record. Putting para 2 of the Explanation first might also assist with clarity. (and insert “of” after “dispose”).

I also wonder if this requirement couldn’t be combined with Requirement 3 – they’re both about protecting the metadata from unauthorised change, whether that’s alteration or deletion. Doing this would simplify the standard.

4.13

30

Examples of Risk – “records are subject to fraudulent change” - clarify

Suggest changing to: Metadata associated with records is subject to fraudulent removal.

4.13

30

Examples of Risk – “records will be destroyed illegally” - how is this necessarily a consequence of removing metadata?

Delete

4.13

30

Examples of Risk – “authorised disposal actions cannot be demonstrated . . . ” - not the real risk to the organisation

Absence of metadata which policy indicates should exist may be regarded negatively by regulatory bodies or auditors.

4.14

31

Explanation – “according to a risk based decision making process linked to the business” - unnecessarily wordy – suggest plain English

Suggest changing to: Such decisions should be made based on the risks associated with the business and should be documented . . .

4.14

31

Examples of Risk – “Records are subject to fraudulent change ” - needs clarification and reframing as a risk to the organisation or deletion. (If it means that without a formal process for such decisions, key metadata could be removed fraudulently, this is a risk more associated with lack of security/control)

Delete

4.15

32

Requirement – Question why the metadata for deleted records should be kept for the life of the system. If you have an approved RDS, and have destroyed records in accordance with this, why should it be necessary to retain the metadata relating to those records? Given that the ‘life of the system’ could be indefinite but certainly decades, this could prove a huge overhead on the system. Which raises another question - is the ‘life of the system’ the life of an EDRMS or the life of a particular software package at any time providing the functions of an EDRMS?)

4.15

32

Examples of Risk – “Records are subject to challenge . . .”. Too vague; don’t see exactly how this is a consequence of not retaining metadata for destroyed records.

Glossary

33

Aggregation – “each of these layers is referred to as an aggregation”. Confusing. I would have thought all the layers together formed the aggregation, not each layer.

Clarify

33

Capture – good, but this is more like the definition required in the Create & Maintain Standard.

Use the same definition in the Create & Maintain standard. (In fact, in general, check that definitions across standards are in accord.)

34

Destruction – unnecessary inclusion of “a recordkeeping term” because (a) destruction is not exclusively a recordkeeping term (b) the point of the glossary is to give terms which have other meanings their recordkeeping meaning and (c) this is not a format used for all other terms.

Delete “A recordkeeping term for”

34

Disposal – defined above under “Control Tools”, but with a different definition! Presumably it is not necessary to define it under Control Tools if it is defined here.

Remove definition from under Control Tools and decide which definition is appropriate.

35

Metadata element – it does not seem accurate to describe a metadata element as a discrete unit of “data or metadata”

Delete “data or”

36

Record - Review definition - see earlier comments about “full and accurate records” and “adequate records” and lack of clarity over whether the record includes the content, or the content and the metadata.

Review

36

Record object – not a clear definition

Review

37

Recordkeeping metadata – not required, because already have a definition of metadata (although I think it should be reviewed) and this standard is only talking about recordkeeping metadata. (This is still not a good definition as an alternative to the earlier one, however – requires something about being the data which describes the record etc.)

Delete

38

Tamper-proof – is a definition of tamper-proof really necessary? It’s not used in a different sense from ordinary English usage

Delete