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-Common | 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-Common | 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
UMM Migration
None
Future Mappings
History
UMM Versioning
Version | Date | What Changed |
---|---|---|
1.10.0 |
| |
1.9.0 |
ARC Documentation
Version | Date | What Changed | Author |
---|---|---|---|
1.0 | 9/28/18 | Recommendations/priority matrix transferred from internal ARC documentation to wiki space |