...

Background:

NASA management wants uniform license information for all collection level metadata. Very few collections currently exist in the CMR where it looks like an attempt was made to add license information. Based on its definition, one element does exist in the UMM that can hold license information, but it is not adequate for NASA's needs. 

Analysis:

There have been several suggestions to use certain UMM-C elements for the license information and they are: access constraints, related URL, and use constraints. Looking at the definition of access constraints, it is clearly stated that this element is used to set permissions in order to access the metadata. Since license information doesn't pertain to permissions accessing the metadata this is not a proper fit. The related URL element is a general element that holds URLs. While this element could work for licenses that are located through a URL, it does not work for non URL license information that is to be inserted into the metadata. The UMM-C use constraints' definition states:

...

To be flexible we should be able to accommodate either a URL to where the license exists on the web, or to include the license text in the metadata itself. While I prefer the former the UMM-C should be able to handle license text. I don't think the UMM-C should allow both a URL and text at the same time. The reason for this is that one could contradict the other or one could be updated while the other isn't, producing conflicting information. I believe the UMM-C should allow a short description of the license or use of the product independent of the license text or URL.

Recommendations:

Therefore the following structure is proposed:

...

The sections below detail the proposed changes based on the analysis done by the ECSE team:

Changes to UMM-C elements

As shown in the Recommendations section, the Use Constraints element will be changed from a free text field to 3 sub-elements of which only 2 can be used at once: Description, LicenseUrl, or LicenseText. The UseConstraints Description element will be defined as its own definition so that it isn't defined twice. The resultant changes will look like what is described in Code Block 3.

Changes to UMM-Common elements

No changes are proposed for UMM-Common elements since the license information is only needed for collections. The definitions can be moved at a later date to UMM-Common if other UMM profiles need the license information.

Mappings to DIF, ECHO, ISO

DIF 9 and DIF 10:

Both DIF specifications include a Use_Constraint element. It is currently defined as a free text element and is mapped to the UMM-C UseConstraint element. In order to add license information in the same manor that is proposed in this text, it is proposed that the DIF 9 and DIF 10 specifications adopt the same approach. If either specification can't be altered the Use_Constraint element will be mapped to the UseConstraints/Description element.

...

Currently the translations for UMM-C AccessConstraints uses the ISO useLimitation element which we think isn't the best choice.  We recommend changing the translations for access constraints to use the ISO accessConstraints element.

Changes to CMR

The translation of the legacy formats into UMM will to take into account the translation process described above.

What should the MMT forms look like

The structure of the forms shouldn't change, but the entry form for Use Constraints should require entry of a description and either the license URL or license text.

How should the values in these fields be presented to the user on the EDSC

Use constraints along with license information should be available to the user when they view a collection.

Next Steps after approval

1. Write tickets and ask for changes in the supporting specifications (DIF 9, DIF 10, ECHO 10).
2. Update JAMA documentation and mapping spreadsheet.
3. Write issues to update the UMM schema.
4. Write issues to update the CMR ingest and its translations.

...