Element Description
The Access Constraints element describes any restrictions imposed on data access. Access Constraints can be described in a free text field with the option to provide an access control list (ACL) value.
Best Practices
There are two sub-elements that comprise Access Constraints: Description and Value.
- Description: The Description sub-element allows the author to provide information concerning access constraints. This includes any special restrictions, legal prerequisites, limitations and/or warnings on obtaining the data. Examples of values include: Public, In-house, Limited, and None.
- Value: Providers have the option to use the AccessConstraint/Value element to specify various restriction levels with access control lists (ACLs). The provider is responsible for defining their own ACL rules (http://en.wikipedia.org/wiki/Access_control_list). For example, a provider might specify a service level ACL that hides all items (collections for this example) with a value element set to '15.0' in order to hide metadata when it isn't ready for public consumption. There is no controlled mapping for what the values represent.
Examples:
AccessConstraints/Description: None
AccessConstraints/Value: 15
AccessConstraints/Description: Limited
AccessConstraints/Value: 4
AccessConstraints/Description: This product has full public access.
AccessConstraints/Value: 0
Element Specification
Providing Access Constraints is optional (Cardinality 0..1)
Model | Element | Type | Constraints | Required? | Cardinality | Notes |
---|---|---|---|---|---|---|
UMM-C | AccessConstraints/Description | String | 1 - 4000 characters | Yes, if applicable | 1 | Free-text description of the constraint. In DIF, this field is called Access_Constraints. In ECHO, this field is called RestrictionComment. |
UMM-C | AccessConstraints/Value | Number | n/a | No | 0..1 | Numeric value (ACL) used to restrict (or not restrict) access to this collection. In DIF, this field is called Access_Control. In ECHO, this field is called RestrictionFlag. |
Metadata Validation and QA/QC
All metadata entering the CMR goes through the below process to ensure metadata quality requirements are met. All records undergo CMR validation before entering the system. The process of QA/QC is slightly different for NASA and non-NASA data providers. Non-NASA providers include interagency and international data providers and are referred to as the International Directory Network (IDN).
Please see the expandable sections below for flowchart details.
Dialect Mappings
DIF 9
UMM Migration
None
Future Mappings
History
UMM Versioning
Version | Date | What Changed |
---|---|---|
1.12.0 | 01/22/2019 | No changes were made for Access Constraints during the transition from version 1.11.0 to 1.12.0. |
1.11.0 | 11/28/2018 | No changes were made for Access Constraints during the transition from version 1.10.0 to 1.11.0. |
1.10.0 | 05/02/2018 | No changes were made for Access Constraints during the transition from version 1.9.0 to 1.10.0. |
ARC Documentation
Version | Date | What Changed | Author |
---|---|---|---|
1.0 | 9/28/18 | Recommendations/priority matrix transferred from internal ARC documentation to wiki space |