Page tree
Skip to end of metadata
Go to start of metadata

I. Summary

  • Total Reviewers: 11
  • Total Comments: 164
     

II. Review Detail

ReviewerReviewer FeedbackResponseResponded to User

Kathleen Baynes (NASA/ESDIS) kathleen.baynes@nasa.gov

  1. I wouldn't use the related URL types as search terms. I cannot comment on science keywords
  2. I think "OpenSearch" should be modified to all caps (OPENSEARCH)
  3. I prefer, long term to get rid of the verbs "GET", "VIEW", "USE", "GOTO", etc in favor of a simplified taxonomy
  1. The Related URL terms are not primary terms that users use within search, but there are use cases where users might want to search or refine their existing search for a specific Get Data type. For example, I want to search for data sets that have a MODAPS data type or a service that points to a software package as an end point.
  2. The term is consistent with the naming convention used by the OpenSearch organization and we are trying to be consistent with the accepted naming convention. Therefore, we recommend that the term stay as "OpenSearch".
  3. This terminology has been recommended by end users, the ARC team, DAAC metadata curators, and provides a clear understanding of the type of URL that users will obtain. I recommend that before making any decision, we consider the other feedback in the review. Do you have a use case or rationale for why these 'verbs' should be removed?
Yes

Treva Houska (LP DAAC/USGS) treva.houska.ctr@usgs.gov

  1. LP DAAC would like Related URL Keyword options for USGS EarthExplorer and AppEEARS.
  1. These Related URL keywords can be added. Can you please clarify that you want these sub-types added under 'DistributionURL > Get Data'?
Yes
Les Hook (ORNL DAAC) hookla@ornl.gov
  1. Categories as Variable Level 1 for Water Quality/Water Chemistry? Not my favorite thing.
  2. In this example, it appears that these Var_2 are only available as "Contaminants". True? This would not usually/necessarily be the case. Nutrients perhaps? Water Characteristics? Add to both categories?
    Contaminants >> Inorganic Matter
    Contaminants >> Nitrogen Compounds
    Contaminants >> Organic Matter
    Contaminants >> Phosphorous Compounds
  3. Don't put categories as Var_1. (Contaminants,
    Gases, etc.)
  4. Suggest that interested parties be invited to a telecon to discuss next "Topic-Term" update to be considered before review. Enough interest?
  5. How do these "WATER QUALITY/WATER CHEMISTRY" keywords relate to GROUNDWATER CHEMISTRY and SURFACE WATER CHEMISTRY?
  1. The naming convention is not ideal and there are plans to address this issue in future keyword releases since in many cases, keywords at the 'Variable Level 1' level are not true variables. The current naming convention was adopted at a time when there were fewer keyword levels and all keywords at this level were true variables. The categories being proposed under Water Quality/Water Chemistry are consistent with keyword categories across other keyword topic areas.
  2. Some of the variables under 'Contaminants' also apply as Nutrients since we define Nutrients as 'Elements essential for growth and survival of a given organism'. The following variables under 'Contaminants' can be added under 'Nutrients': Hydrocarbons, Inorganic Matter, Nitrogen Compounds, Organic Matter, Phosphorous Compounds. I agree that some of the variables under 'Contaminants' also apply as Water Characteristics since we define Water Characteristics as 'The major physical characteristics of water that respond to the senses of sight, touch, taste, or smell and include turbidity, color, taste, odor, and temperature'. The following variables under 'Contaminants' can be added under 'Water Characteristics': Hydrocarbons, Inorganic Matter, Nitrogen Compounds, Organic Matter, Phosphorous Compounds.
  3. Refer to the response in question 1 above.
  4. The Earthdata Unified Technical Committee (UTC) telecons can be used to surface stakeholder comments regarding the keyword review and discussion of upcoming keyword releases. The GCMD Keyword Forum at https://wiki.earthdata.nasa.gov/display/gcmdkey is also a venue where proposed keywords are posted. Participants can use the forum to ask questions, submit keyword requests, discuss trade-offs, and track the status of keyword requests. If you are suggesting a more targeted and focused meeting to discuss keywords, we can make this recommendation to ESDIS.  
  5. 'Ground Water Chemistry' and 'Surface Water Chemistry' keywords are used to capture the general water chemistry of the ground water and surface water. When keying records, users are encouraged to use either ground water or surface water to indicate the data set being described and the specific/detailed water quality variable being measured.  For example, a record describing Surface Water Turbidity would be keyed as follows:
    TERRESTRIAL HYDROSPHERE > SURFACE WATER > SURFACE WATER CHEMISTRY
    TERRESTRIAL HYDROSPHERE > WATER QUALITY/WATER CHEMISTRY > WATER CHARACTERISTICS > TURBIDITY
Yes
Leigh Sinclair (UAH) slb0012@uah.edu
  1. Keywords are very similar to GET SERVICE Type.
  2. Users who are not familiar with APIs may not be able to distinguish between these two Types, and both of these types are a 'service'.
  1. Can you please provide additional details for this question.
  2. DAACs and stakeholders who are building search clients have requested and need a distinct URL type for service APIs and understand the types being proposed. A definition of the keyword type and sub-type is provided with the keyword. The metadata user guides will be updated to reflect the changes and examples will be provided.
Yes
Pam Rinsland (ASDC) Pamela.l.rinsland@nasa.govNo Comments
Yes
Bruce Vollmer (GES DISC) bruce.vollmer@nasa.gov
  1. From a developers perspective the addition of the Service API keywords for Related URL types serves the stated purpose. However, this may not be clear from a metadata consumer perspective. Additional information must be available on how to leverage the published URL, not necessarily in the metadata.
  2. Regarding the the addition of the Service API keywords for Related URL types improve the exposure, discovery, and access of web services in metadata records, a qualified yes. With the wide variety of subtypes for RelatedURLs I don't see them as being distinctive to minimize overlap. For example, what's the difference between On-Line Archive and Download? Between Software Package and Tool? Between data usage and product usage? Between How-to and recipe?
  3. Perhaps users will be able to distinguish between the two types of 'Service URL keywords, provided that other subfields are available to adequately describe the service that is being invoked (e.g., Description, data format, etc.).
  4. CollectionURL:DOI is a proposed new keyword. GES DISC DOIs are currently populated in DIF10:DatasetCitation:PersistentIdentifier:DOI. What happens to this field if the new keyword is approved?
  5. For RelatedURL subtypes too many choices are offered. This will add to confusion as to which is a proper choice and reduce the possibility for consistent population of metadata across DAACs. Perhaps consistent conventions can be enforced through limited keyword choices.
  6. With the proposed keyword changes to RelatedURL there will likely be substantial changes to existing metadata records from GES DISC. To bring records into compliance with approved changes assistance from the CMR/GCMD group to perform bulk updates is required.
  1. DAACs and stakeholders who are building search clients have requested and need a distinct URL type for service APIs and understand the types being proposed. A definition of the keyword type and sub-type is provided with the keyword. The metadata user guides will be updated to reflect the changes and examples will be provided.
  2. Based on feedback that we have received, we are currently reevaluating the sub-types to reduce overlap. We have already identified some types that will get deprecated. For example, some of the 'DistributionURL > Get Data' sub-types can be handled through Related URL mime types. Other types under 'PublicationURL > View Related Information' have been specifically requested by DAACs and other stakeholders, so we want to accommodate their needs. We agree that there is redundancy between 'ON-LINE ARCHIVE' and 'DOWNLOAD' and we will be deprecating those keywords and merging them into 'DATA TREE' and/or 'DATA COLLECTION BUNDLE' per the feedback received from DAACs. Regarding 'DistributionURL > GET SERVICE > SOFTWARE PACKAGE' and 'DistributionURL > GET SERVICE > Tool', we will be deprecating 'Tool'. Regarding 'PublicationURL > VIEW RELATED INFORMATION > RECIPE' and 'PublicationURL > VIEW RELATED INFORMATION > HOW-TO' there is a distinct difference in that a 'How-To' provides generic documentation on how to use a data set, where 'RECIPE' provides specific step-by-step instructions to help users learn to discover, visualize and use new data, information, software and techniques. DAACs and stakeholders have also explicitly requested the 'RECIPE' sub-type keyword. The specific web service types under 'DistributionURL > GET SERVICE' (e.g. 'WEB FEATURE SERVICE') are being consolidated under 'DistributionURL > USE SERVICE API'. There may be other consolidation of keywords as user comments are being reviewed.
  3. The following fields/sub-fields are included with Related URL in the UMM model that help describe the type of URL being provided for metadata collection and services. This format has previously been vetted with DAACs and other CMR stakeholders.
    RelatedURL
    RelatedURL/URL
    RelatedURL/Description
    RelatedURL/URLContentType
    RelatedURL/Type
    RelatedURL/Subtype
    RelatedURL/GetData
    RelatedURL/GetData/Format
    RelatedURL/GetData/Size
    RelatedURL/GetData/Unit
    RelatedURL/GetData/Fees
    RelatedURL/GetData/Checksum
    RelatedURL/GetService
    RelatedURL/GetService/MimeType
    RelatedURL/GetService/Protocol
    RelatedURL/GetService/FullName
    RelatedURL/GetService/DataID
    RelatedURL/GetService/DataType
    RelatedURL/GetService/URI

  4. After additional consideration and the recommendation to populate the DOI and DOI authority within 'Dataset_Citation', we retract the proposed new keyword for 'DOI' from the Related URL type.
  5. See comments in #2 above.
  6. The Change List tool will support bulk updates of the Science Keyword and Related URL fields. We can discuss in more detail later regarding the level of assistance that you will need.
Yes

Tammy Beaty (ORNL DAAC) beatytw@ornl.gov

  1. Regarding the Related URL keywords, this entire list is overly complicated, we feel it will be confusing to users.
  2. ORNL DAAC has Science Discipline based reviewers for applicable keyword domains. This collaborative entry does not address Water Quality/Water Chemistry categories.
  3. Regarding if users will be able to distinguish between the two different types of service keywords used under the Related URL type, some will understand but we fear the majority will not.
  4. The ECHO schema needs to be updated to support 'Related URL' subtype, if it is not then 'OnlineAccessURL' must be used.
  5. We may make additional keyword recommendations at a later time.
  1. Based on feedback that we have received, we are currently reevaluating the sub-types to reduce overlap. We have already identified some types that will get deprecated. For example, some of the 'DistributionURL > Get Data' sub-types can be handled through Related URL mime types. Other types under 'PublicationURL > View Related Information' have been specifically requested by DAACs and other stakeholders, so we want to accommodate their needs. The specific web service types under 'DistributionURL > GET SERVICE' (e.g. 'WEB FEATURE SERVICE') are being consolidated under 'DistributionURL > USE SERVICE API'. There may be other consolidation of keywords as user comments are being reviewed. Do you have specific examples of where you feel the list is overly complicated?
  2. Will you have additional domain experts reviewing the Water Quality/Water Chemistry keywords? I did see that Les Hook provided comments.
  3. DAACs and stakeholders who are building search clients have requested and need a distinct URL type for service APIs and understand the types being proposed. A definition of the keyword type and sub-type is provided with the keyword. The metadata user guides will be updated to reflect the changes and examples will be provided.
  4. Regarding the ECHO schema, there are no plans to update the schema. The 'OnlineAccessURL' 'OnlineResource' 'Type' will continue to be mapped to the Related URL types as they currently are. There are no actions that providers need to take. CMR will update the mapping based on the published version of the keywords.
  5. You are welcome to make keyword recommendations at any time.


Yes

Dave Connell (AADC) Dave.Connell@aad.gov.au

No Comments
Yes

Kemo Dassau (ASDC) Kemo.j.dassau@nasa.gov

  1. Requires changes to multiple tools and related databases.  
  2. URL Content Types (to delineate between Distribution URL, Visualization URL, Collection URL, Publication URL). This field currently does not exist in ASDC URL Metadata lexicon.
  1. You can retrieve the versioned keywords via the Keyword Management System (KMS) API. Keywords are referenced via unique UUIDs and for keyword updates, the UUID does not change. This allows providers to map the old keyword to the new keyword. Can you provide more details on the changes you need to make so we can determine if there is any additional mitigation we can do on our end to minimize impacts to users?
  2. The 'URLContentType' keywords are primarily being used by web clients (e.g. Earthdata Search Client) to distinguish between the types of URL's. There will be a mapping between 'URLContentType' and the 'Type' and 'Subtype' for client support including the Earthdata Search Client, so metadata curators won't have to populate that level and therefore, no impact to metadata providers is expected. The full keyword hierarchy will be available via the Keyword Management System (KMS) API for metadata providers who wish to utilize them in their metadata.
Yes

Jeanne' le Roux (UAH) jeanne.leroux@nsstc.uah.edu


See Excel Spreadsheet

See Excel Spreadsheet CommentsYes

Kaylin Bugbee (UAH) kaylin.m.bugbee@nasa.gov

See Excel SpreadsheetSee Excel Spreadsheet CommentsYes

Keyword Change Summary



  • No labels