The Service Concept in the Unified Metadata Model (UMM) is a relatively new concept in the UMM with some uncertainty as to how it is to be populated. In order to elucidate how it should be populated, it is important to spell out the core Use Cases for the concept, which are listed below.  The Use Case for a given UMM-S record is actually dependent on the type of service or tool in the record. For the purpose of this document, we classify Services and Tools into 4 categories, based on how they are invoked by the users:

1. Headless Services

2. Full Stack Services

3. Web Tools

4. Local Tools

Headless Services are services which are intended to be primarily exercised  through an HTTPS bested API. In the EOSDIS, a user may interact with the service through either a rich client user interface, such as IDV or panoply or via a user-specific script. An example is the OGC Web Map Service, which can be consumed by a number of tools, including IDV, ArcGIS, qgis, and Google Earth.

Full Stack Services are services that provide interaction with the data through both a rich web front end and an HTTPS API. The AppEEARS tool provides an example of this class.

Web Tools are rich web interfaces providing interaction with the data, but lacking a robust, well-advertised API. AN example of this class is the State of the Ocean tool.

Local Tools are those which must be downloaded to the user’s processing platform in order to use them. examples of these include local GUI tools like Panoply and command line tools such as NCO.

Note that these categories occur along a continuum requiring some judgement to classify the tool or service. For example, OPeNDAP services provide both API access and a web form interface. However, the web form is typically used for inspecting data and troubleshooting, not routine access. Most access is via scripts and Opendap-enabled clients such as Panoply, IDV, ArcGIS and nco, putting OPeNDAP  closer to the Headless Service than Full Stack Service.

We will use this classification to show how a given tool or service class maps to the Use Cases envisioned for UMM-S.

Use Cases for UMM-S

Service Infrastructure:  Headless Services and Full Stack Services

In order to attain a service Infrastructure in EOSDIS that is scalable to the variety of both services and of datasets, we seek to build a framework that enable a scale out that is database-driven. That is, we would like to be able to add services to datasets and new services to the system with writing (much) code. For instance, each OPeNDAP server instantiation should be able to be added simply by adding a UMM-S record identifying the service endpoint, with some information about the server’s capabilities and associations with the the collections that it serves.* In this Use case, the target user of the UMM-S record is the software making up the Service.s Infrastructure.  This software tends to be unforgiving of incomplete or inaccurate information in the UMM S records.

Dataset-capable Tools:  Local Tools and Web Tools

With prevalence of API-based data formats in EOSDIS,  many users would like to save time and effort by using off-the-shelf tools. However, determining which tools can correctly read ,and process a given dataset is not always inferrable from the data format.  Small deviations from standards and conventions can render datasets unreadable by the tools that rely on them. One use case envisioned for UMM-S is to record the known associations between data collections and the tools that are known to work with them. The tools known to work for a given dataset would be presented in the dataset landing page and dataset info pages. Enabled by UMM-S, a preliminary smart-handoff capability has been demonstrated with Web Tools (Giovanni, SOTO) allowing the user to transition from Earthdata to the Web Tool with their data search criteria intact.

Legacy SERF Hosting:  Correct and Complete SERFs satisfying one of the above use cases

With the merging of GCMD collections and keywords into CMR, only the legacy SERF population was left outside of CMR. In order to deprecate the GCMD database and supporting infrastructure while fulfilling NASA’s international commitments, an activity was begun to migrate SERFs to the CMR UMM-S. The population effort for this should be informed by whether the Legacy SERFs satisfy one of the above Use Cases. That is, the criteria should be:

1. For Headless or Full Stack Services, is the information quality high enough for use in Services Infrastructure?

2. For Local Tools, Web Tools and Full Stack Services, is the value to the user community high enough to warrant cleanup of the SERF for re-hosting in CMR?