HSRMS Metadata and Classification Rules

HSRMS Metadata and Classification Rules

Purpose

Consistent metadata enables records to be identified, located, compared, and maintained without relying solely on filenames, page titles, or individual recollection.

These rules establish the intended principles for HSRMS metadata handling. Specific field names, permitted values, mandatory fields, and validation logic must be reconciled with the authoritative HSRMS data dictionary before implementation.

Identifier integrity

Every controlled record should have a distinct assigned identifier.

The established HSRMS pattern is HS-[class]-[six digits]. The actual identifier must be issued through the applicable assignment process; it should not be generated by guessing the next available number or copying an example.

An identifier should remain stable when a record’s title or presentation changes, unless a documented identity-management rule explicitly requires otherwise.

Duplicate identifiers, malformed identifiers, and references to nonexistent records should be treated as validation issues.

Classification integrity

Classification must follow the current HSRMS classification scheme and its defined codes.

A classification should not be inferred from a filename, search result, or superficial subject match where authoritative classification data is available. Ambiguous cases should be flagged for review.

HSRMS internal classification is an organizational mechanism. It must not be represented as a government security designation or an external certification unless separate, applicable evidence establishes that status.

Metadata states

A metadata implementation should distinguish among a known value, a missing value, an inapplicable field, an unverified value, and a conflicting value.

These states are not interchangeable. For example, a blank verification date does not mean that verification occurred on the publication date.

The specific vocabulary and storage representation for these states should be defined centrally rather than invented independently by each page.

Version control

Version metadata should identify the record version according to the applicable HSRMS versioning rules.

A presentation-code release, such as a label renderer version, is not automatically the same thing as the version of the document being labeled.

When records are revised, the relationship between the current and prior versions should remain understandable. A superseded record should not be silently overwritten when its historical identity must be retained.

Provenance and source fidelity

Where provenance is available, preserve the source reference and relevant acquisition or revision information. Do not replace source metadata with an inference without identifying that transformation.

Derived artifacts should be distinguishable from their source records when the system supports such relationships.

Relationships and canonical locations

Related-record references should use stable identifiers or other defined references wherever possible. URLs should be checked for correctness and should not be treated as permanent identifiers unless the system explicitly defines them that way.

Where a canonical URL is used, it should resolve to the intended record and agree with the publication configuration.

Validation rules

A validation process should check, as applicable:

1. Identifier format and uniqueness.
2. Required identity fields.
3. Classification code validity.
4. Version and status values.
5. Canonical URL validity.
6. Relationships to other records.
7. Duplicate or contradictory metadata.
8. Agreement between the authoritative record and its displayed label.

A check should report the condition it actually tested. Passing a formatting check does not establish provenance, authorship, completeness, or overall record validity.

Change management

Changes to classification definitions, required fields, identifier rules, or allowed status values should be documented and applied consistently.

The current HSRMS data dictionary and classification rules are authoritative for implementation. This public specification should be revised when those source definitions change.