Page History

...

A Complete Mapping will be added via a separate spreadsheet (a marked up version of Erich's excel sheet).

Suggested UMM-C class revisions: 

Bring together all information which describes a collection that has some type of on-line resource. For example:

WebResource/OnLineResource (1..*)

WebResource/RelatedUrl (1..*) 

Add two new objects to the RelatedUrl Object: GetData and GetService with Relationships: IsDistributedVia 

RelatedURL/DistributedVia/GetData (0..*) { Reference to a GetData Object which can distribute the actual data, in a given data format, size and units }

RelatedURL/DistributedVia/GetService (0..*) { Reference to a GetService Object which can visualize, subset, or distribute the actual data, in a given mime type, protocol, DataType, DataID, service, URI }

Suggested DIF/UMM/ECHO mappings are captured (see Notes column for changes in Green) in the attached spreadsheet (DIF-UMM-ECHO_Mapping_06102016.xlsx). UMM-C (Modified) column shows added/removed class/attributes. 

 Spreadsheet 

Suggested CMR-Common UML Model 

Figure 1. RelatedURL (Modified) UML Model

For RelatedURL the attributes are:

/RelatedURL/URL <The URL, e.g. "https://daac.ornl.gov/MODIS/"> 

/RelatedURL/Description <This is the description of the URL, e.g. "The FTP base directory for the collection"> 

/RelatedURL/URLContentType <valid keywords are: "CollectionURL", "PublicationURL", "OrganizationURL", "DistributionURL", "PersonnelURL", "VisualizationURL"> 

/Related/URL/Type <valid keywords are: "GetData", "GetService", or "GetVisualization"> 

/RelatedURL/SubTypes <valid keywords for GetData are: "Browse", "Media"> also for GetService: <"Web Coverage Service", "Web Feature Service", "Web Mapping Service", "OPENDAP," "THREDDS", "DODS", also for GetVisualization: "MIRADOR">. 

Recommend reviewing the use of Type and Subtype in the relevant GCMD keyword list for consistency of usage, and adding the URLContentType keywords to enable the definition of a a more comprehensive, unambiguous RelatedURL set of metadata.

...

For GetData object class 

Add the following attributes:

/GetData/Format

/GetData/Size

/GetData/Description 

/GetData/Unit

/GetData/Fees

/GetData/Checksum 

(This is the minimum set of attributes to enable the client to support the download of a data set).

For GetService object class 

Add the following attributes:

/GetService/Protocol

/GetService/MimeType 

/GetService/FullName 

/GetService/DataID 

/GetService/DataType

...

/GetService/URI (0..*)  URI(s) of actual data - as distinct from Catalog URL - use /RelatedUrl/URL for root catalog entry, e,g, for a THREDDS service. 

(This is the minimum set of attributes to enable the client to support visualization, subsetting or download of a data set via a service).

 

 

 

Depending on the RelatedURL "Type", either <"GetData", GetService", the Earthdata Search client can now distinguish between distribution of data via direct download (media) and/or via services. 

With suitable additional software on the client-side, the data can either be acquired directly in the appropriate format, or displayed in the client via a suitable service. The services typically provide metadata to aid auto-discovery. This can be the subject of a separate ticket.  

 

 Interoperability Considerations

...

 

We are not adopting any ISO classes or attributes directly into the RelatedURL class. However, we are proposing to include the OnlineResource class, which maps directly to the CI_OnlineResource class. 

RelatedURL class will be used to expand and clarify URL content types, types, and subtypes. It will ease mapping issues to the current DIF9, DIF10 and ECHO10 fields for most URLs. For some URLs, specifically those associated with Citations, OnlineResource class provides an alternate to RelatedURL and helps to bring the CMR towards interoperability with other systems.

...