The Art of Discovery: Data, Services, and Applications
Discovery is an art, at least if the desired object is more complex than a simple blog web-page such as this one. Here we are talking about discovery of Earth Observation (EO) products, services providing on-demand processing capabilities, and applications that are not deployed yet but waiting in an application store for their ad-hoc deployment and execution. The OGC Innovation Program has developed an architecture that allows the containerization of any type of application. These applications can be deployed on demand and executed in cloud environments close to the physical location of the data. Instead of processing ever-increasing amounts of data locally, the applications are transferred to where the data resides. But how to discover these applications? How to understand what data an application can be applied to? How to chain applications? How to combine applications with already deployed services that provide data and data processing capabilities? All these aspects are now in focus of OGC Testbed-15.
Discovery has been addressed in OGC for more than two decades. Several OGC and ISO specifications have been developed, such as ISO19115 Geographic Information: Metadata with its XML serializations and extensions defined in ISO19139 and ISO19139-2. Though proven to be powerful, recent developments prefer approaches that are based on OpenSearch formats and JSON encodings.
Let’s explore the current situation: we have a conceptual model for EO products and service discovery that is defined in OGC 11-035r1, the EO Product Collection, Service and Sensor Discovery using the CS-W ebRIM Catalogue. This specification is based on the previously mentioned ISO standards 19115 and 19139/-2, and serves as basis for modern metadata encodings defined in OGC 17-084, the GeoJSON(-LD) metadata encoding for EO collections. Figure 1 illustrates this composition of metadata models and encodings. OGC 17-084 re-uses GeoJSON and OWS Context properties but is designed towards ease of use. It minimizes redesign of properties by re-using properties from several existing namespaces, including Data Catalog Vocabulary (dcat), Friends of a Friend (foaf), Location Core Vocabulary (locn), PROV Data Model (prov), Resource Description Format (rdf), Simple Knowledge Organization System (skos), vCard Ontology (vcard), and several others.
Figure 1: Composition of modern metadata encodings (left) and OpenSearch response models (right)
The metadata side is complemented with OpenSearch response models as illustrated in figure 1. OGC 17-047, the OGC OpenSearch-EO GeoJSON(-LD) Response Encoding Standard, complements the OGC OpenSearch Extension for Earth Observation, OGC 13-026r8, which recommends the use of spatio-temporal filters defined in OGC 10-032r8, the OGC OpenSearch Geo and Time Extensions; and provides additional parameters to further constrain searches. The OGC OpenSearch Extension for Earth Observation uses the default response encoding Atom/XML. With GeoJSON and JSON-LD, OGC 17-047 provides alternative encodings. Using JSON-LD instead of GeoJSON allows to define each property explicitly as a URI, and thus increases the level of interoperability.
Testbed-15 will now explore first the capabilities of OGC 17-084 to express EO collection metadata, and OGC 17-047, to encode OpenSearch responses in GeoJSON(-LD). OpenSearch responses represent search results in containers with response entries as resources that may include hyperlinks. These allow further exploration of search result details by executing further searches, which allows multi-step discovery processes. In addition, Testbed-15 will experiment with faceted search as defined by OASIS. Applications will be handled as dcat:Data Services types. The challenge is to model the additional deployment information for each application. Other elements, such as access constraints and result access paths, are similar to already deployed applications that are made available in the form of Web services.
On the catalog side, substantial modifications to existing OGC Catalog Service - Web instances are foreseen. Any app-store depends on a (transactional) catalog that allows the registration of new apps, services, and deployment & execution environments. Testbed-15 will develop a Web-API based on the OpenAPI specification that gives both human users as well as machines full control over the registered items.
Further information on the current progress of Testbed-15 is available on the Testbed-15 webpage. While the deadline for responses to the Call for Participation (CFP) has passed, offers of in-kind contributions will still be considered. Anyone interested in shaping the direction of future OGC Initiatives, such as the upcoming Testbed-16, is urged to contact email@example.com or submit an idea to OGC’s Innovation Program Ideas GitHub Repository.