Use the NGDC codelists

[jlblcc]

We should use the NGDC codelists for ISO output until we get our own lists up.

http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml

The ISO lists are older and don't include the NGDC additions, e.g. CI_RoleCode > collaborator.

Are the 19115-1 lists available online yet?

[stansmith907]

In the current mdTranslator design codelists are built into the gem. The lists are short and I wanted to avoid excessive external referencing.

We always planned to extend the codelists with additional ADIwg codeNames. We just haven't spent time to pick what new ADIwg items we wish to add. So extending the lists to include any NGDC items we like without pointing to the NGDC codelists would be the same thing. Generating our own set of XML codelists when we are ready seems like the better idea.

Which brings up another design issue. The mdTranslator design is set up for each writer to support its own set of codelists. This includes 19115-2 and 19115-1 having independent codelists. Before we take the next step of publishing an ADIwg XML codelist we should discuss the scope of our codelists. Should our codelists cover ALL writers? or just all ISO writers? or be unique to each writer?

Supporting all writers would make it easier on the mdEditor design. But we may need to filter the adiwgJson when writing to some standards. Not sure.

FYI - topicCategory is an enumerated type and cannot be extended.

Since we never got around to adding ADIwg items to the codelists I removed enforcing adherence to the codelists for now. After we extend our lists we may want to revisit this as we may not want to allow undefined codes in our metadata - that's why we have codelists after all.

[jlblcc]

One thing we need to keep in mind is that we're generating codelists(or CVLs) for ADIwg mdJSON not ISO. That's what we should be using as the scope. We could tie the json schema version to a particular version of the CVLs or not. In the case of the JSON standard, it would be fine to have a continuously updated set of CVLs - we're not enforcing them in the schema.

[stansmith907]

We can treat the CVL as a means to load the mdEditor but the values allowed in the codelists and the organization of codelists themselves have been highly dependent on the standards being supported. E.g. we use 'onGoing' and not 'inProgress' for a status code. But some non-ISO standard we choose to support in the future may prefer 'inProgress'. Since we only generate ISO at the moment and ISO is extensible we are probably fine, and I think FGDC supports many of the ISO codes.

It would be against our original design criteria to version adiwgJson depending on the planned output standard. So I also an advocate the CVLs for the adiwgJson. Which means the adiwgJson codes may need to be cross-walked in the writer to appropriate values if we choose our code values too freely or eventually support non-ISO writers.

I think the first step must be to determine what we want our codelist values to be. Presumable some combination of ISO, ADIwg, and NGDC with FGDC and ISO -1 considered.

And, of course, none of this discussion changes the fact that rendering of the codelists is dependent on the standard. So each writer will still need its own codelist section.

[stansmith907]

• a google spreadsheet was created to review all codelists and approve ADIwg additions
• the spreadsheet was review several times by the development group
• the spreadsheet will be circulated to ADIwg membership for review and additional codes
• mdCodes repository was created.
• complete ISO 19115-2, ISO 19115-1, NGDC, codelists plus additional ADIwg codes were entered into a YAML file.
• the mdCodes gem provides methods to return
  • all codelists (.../api/codelists);
  • a single codelist (.../api/codelists/{codelistName}) in a JSON or JSONp object.
  • an ISO CT_CodelistCatalogue (.../api/codelists?format=xml)