ICSM ISO19115-1 Metadata Best Practice Guide

Resource Security Constraints ★★★★★

When constraints (MD_Constraints) on a spatial resource [MD_Identification] concern security it is important to document these. Potential users need to be informed of the presence or absence of concerns about security that apply to the use of such resources.

   
Element Name resourceConstraints
Parent MD_Metadata.identificationInfo>MD_Identification.resourceConstraints
Class/Type MD_SecurityConstraints
Governance Common ICSM, Agency, Domain
Purpose Discovery, Identification
Audience machine resource - ⭑
  general - ⭑ ⭑ ⭑ ⭑ ⭑
  resource manager - ⭑ ⭑ ⭑ ⭑
  specialist - ⭑ ⭑ ⭑
Metadata type administrative
ICSM Level of Agreement ⭑ ⭑ ⭑

Definition

Handling restrictions imposed on this cited resource for national security or similar concerns e.g. commercial sensitivity, privacy considerations.

ISO Obligation

Discussion

Many spatial resources carry some security restrictions regarding their access and use, such as national security, financial or commercial sensitivity, or privacy concerns as is common with census data. These security restrictions need to be documented for users and resource managers along with the identity of the applier of these constraints. Each agency needs to develop consistent guidance on the use of such a statement and share a clear understanding of its meaning. This is often done by reference to an external body that manages the definitions of the security constraints applied.

Outstanding Issues

Australian security classification codes The official codes used in Australia as mandated by Australian Protective Security Policy Framework, differ from those in the MD_RestrictionCode codelist. How to address using codes other than those supplied by MD_RestrictionCode needs to be discussed. For interoperability, should we include the MD_RestrictionCode as well as the PSPF?

Other security frameworks support There will be cases where other security frameworks and classification systems need to be cited, such as for New Zealand Defence. Instructions for how to include these are needed. Should such guidance be prescriptive or general?

ICSM Best Practice Recommendations

Therefore - it is important to capture all security constraints that apply to a spatial resource. If there be none it may be useful to capture such, particularly if your organisation does regularly handle sensitive resources. Agencies should develop consistent guidance on the use of security classifications and share a clear understanding of their meaning with users.

The MDWG recommends populating resourceConstraints with security constraint information to a sufficient level to determine the security structures and restrictions on a cited resource.

At a minimum, the name (primary and alternate) and version by which this security restriction on the access and use of this cited resource is known should be captured along with the classification value selected from the codelist - MD_RestrictionCode, or the codelist mandated by your agency, e.g. Australian Protective Security Policy Framework

Also Consider

Crosswalk considerations

ISO19139

See guidance provided in MD_Constraints

RIF-CS

Maps to the aggregate Rights/@accessRights

Examples

XML

<mdb:MD_Metadata>
....
 <mdb:identificationInfo>
  <mri:MD_DataIdentification>
  ....
    <mri:resourceConstraints>
      <mco:MD_LegalConstraints>
        <mco:useLimitation>
         <gco:CharacterString>Not to be used for navigation
         </gco:CharacterString>
        </mco:useLimitation>
        <mco:reference>
         <cit:CI_Citation>
           <cit:title>
            <gco:CharacterString>
            “Creative Commons Attribution 4.0 International 
            Licence”
            </gco:CharacterString>
           </cit:title>
           <cit:citedResponsibleParty>
            <cit:CI_Responsibility>
              <cit:role>
               <cit:CI_RoleCode 
               codeList="https://schemas.isotc211.org/19115
               /resources/Codelist/cat/codelists.xml#CI_RoleCode" 
               codeListValue="rightsHolder"/>
              </cit:role>
              <cit:party>
               <cit:CI_Organisation>
                 <cit:name>
                  <gco:CharacterString>OpenWork Ltd
                  </gco:CharacterString>
                 </cit:name>
                 <cit:contactInfo>
                  <cit:CI_Contact>
                    <cit:address>
                     <cit:CI_Address>
                       <cit:electronicMailAddress>           
                       <gco:CharacterString>
                       info@openwork.nz
                       </gco:CharacterString>
                       </cit:electronicMailAddress>
                     </cit:CI_Address>
                    </cit:address>
                  </cit:CI_Contact>
                 </cit:contactInfo>
               </cit:CI_Organisation>
              </cit:party>
            </cit:CI_Responsibility>
           </cit:citedResponsibleParty>
         </cit:CI_Citation>
        </mco:reference>
        <mco:accessConstraints>
         <mco:MD_RestrictionCode 
         codeListValue="copyright" 
         codeList="https://schemas.isotc211.org/19115/resources
         /Codelist/cat/codelists.xml#MD_RestrictionCode"/>
        </mco:accessConstraints>
        <mco:useConstraints>
         <mco:MD_RestrictionCode 
         codeListValue="otherRestrictions" 
         codeList="https://schemas.isotc211.org/19115/resources
         /Codelist/cat/codelists.xml#MD_RestrictionCode"/>
        </mco:useConstraints>
        <mco:otherConstraints>
         <gco:CharacterString>For non-commercial purposes only
         </gco:CharacterString>
        </mco:otherConstraints>
      </mco:MD_LegalConstraints>
     </mri:resourceConstraints>
   ....
   </mri:MD_DataIdentification>
</mdb:identificationInfo>
....
</mdb:MD_Metadata>

\pagebreak

UML diagrams

Recommended elements highlighted in yellow

resourceSecurityConstraints

\pagebreak