Common Object Model Container SWG

Chair(s):

Colaiacomo, Lucio (European Union Satellite Centre)

Group Charter:

Download Charter document

Group Description:

1. Common Object Model Container

 

 

 

The Name of this SWG shall be the “Common Object Model Container.”

 

2.Purpose of this Standards Working Group

 

 

 

We are reaching in OGC an important operational level for data and services interoperability. The momentum we have enables us to think about the possibility to rid ourselves of different data encodings and specific server specifications. A user should be able to publish data and retrieve it independently from its nature and format.

We all use different data (encodings) and we need to publish these in services or have them available in many different environments. There are encoding types (imagery, video, Audio, OS, …) that oblige us to have specific software and platforms to be used, reducing the flux of information and creating bottlenecks in its usage. There is a need for accessing the “information” no matter the service type (map, feature, coverage, etc.) or environment. We need the information derived by services to be directly re-usable. We need “services as information.” The idea is that we have different objects (like files or messages, etc.) that normally are passive and manipulated by high level algorithms. We need active objects with their own behavior and state. Objects that can be streamed with a mechanism to react and consider the status and the object’s behavior. This should be done in either asynchronous or synchronous mode and by creating a data and service layer model based on previous experience at OGC and in other contexts.

The basis for accessing data should be any communication technology in which symmetrical client/server communication is foreseen but we should consider future connectionless systems and eventually multicast mode. So a digital container wrapping any type of data.

For the above reasons, we need a high level of abstraction which is architecture and operative system independent.

We should define a high hierarchical model based on context containers and is partitioned into domains which are separate hierarchies built upon “objects” and containers.

Domains can be connected through “portals/servers” and all hosts should have at least one domain. These domains should be built on the real objects that belong to the hosts. When any two objects connect, they will exchange hierarchies.

We will consider having event driven systems and the interactions between objects done through “messages”, with a message management system that can update the messages if they lose scope. For example, mpeg4 messages could be sent directly to the receiving object and optionally queued for later delivery, based on an asynchronous transfer mode protocol.

2.1. Basic Concept

The proposed idea for the COMC is to leverage two existing OGC standards to build the container as a combination of:

  • OWS CONTEXT
  • Coverage Implementation Schema (CIS) (formerly GMLCOV) 

Considering the above assumption, the possible benefits are:

  • Encoding independency
  • OGC W*S independency

 

2.2. The Common Object Model Container

The term “Container” should be referred to the fact that the metadata are included in a common format that encapsulate all the information required to define the data.

This because it is necessary (mainly in streaming of data ) to have a constant reference between metadata and data to be able at any moment in time of the streaming to retrieve the corresponding metadata and the other information associated. Considering also the object status.

Once these objects are published in a service the specific encoding (video, imagery, vector feature,..) should be irrelevant for the user, that said the concept of a WOS web object service would be more relevant for a generic user. 

The work of all the WxS payloads have to be analyzed in order to extract all the common elements to support and inform this SWG.

If we merge the capabilities of CIS with OWS Context, we obtain a descriptor that is independent (besides the link with the specific imagery) from the encoding of the imagery itself.

Consider the case of a xml box inside a jp2 file. Following gmljp2 specifications, the box can be referenced in an external file with a simple href link. We now have a xml container that is always structured the same way independently from the specific imagery format. This gives us a structure of files (imagery, vector, pdf, video, etc..) that have a unique link (UUID) with the metadata and the OWS Context. 

 

3. Scope of Work

This SWG should develop a new Common Object Model Container standard integrating the existing standards OWS Context, WCS, GMLJP2, SensorML and perhaps others. By relying on existing standards, COMC should be more readily adopted by the market.

The work will include:

-       Identify portions of OWS Context and CIS necessary to build COMC

-       Define common data model

-       Define service layer component /layer model

-      Develop draft standard for interim public review

-      Develop candidate standard for formal OGC review and approval.

-      Identify use cases and define tests

 

3.1. Statement of relationship of planned work to the current OGC standards baseline

GMLJP2

OWS Common

OWS Context

SensorML

WCS

CDB

geopackage

 

3.2. Specific Contribution of Existing Work as a Starting Point

 

The SWG is based on previously developed Standards and Testbeds:

Coverage Implementation Schema (CIS) (formerly GMLCOV)

GMLJP2

OWS context

WCS

CDB

Geopackage

OWS Common in all the aspects already defined for what concerns operation requests, data structures and encoding.