OGC Goals

Active Direction

Certain topics are central to the work of the OGC and yet do not receive sufficent attention from the voluntary collaboration. This includes things like:
  • maintenance of The Specification Model document.
  • maintenance of the OGC Naming Authority registries and resolvers.
  • work on common standards widely shared across the OGC such as the OGC Web Services Common specification.
  • research on possible approaches towards REST (and RESTful) designs for OGC web services.

It has been suggested that the OGC Leadership (President, Board of Directors, TC Chair, OGC Architecture Board) could priortize such work either by promoting its development in OGC Testbeds, by assigning staff to contribute to the work, or by using OGC funds to pay contractors to complete the work.
  • PRO - This would ensure that shared, common work is actually completed.
  • CON - This would take OGC resources.
  • MIX - This would shift towards a more hands on approach with the OGC Leadership actively promoting a certain direction for OGC work efforts.

While I understand the current position of OGC to not intervene with the contents of specifications (and I do see its merits), in my experience it is detrimental to direction and coherence: it is detrimental that core standards like OWS Common are not receiving proper attention just because volunteers consider it a "boring" topic (my interpretation); it is leading to incoherence because SWGs, in their despair wink tend to find individual ad-hoc solutions. IMHO it is indispensable that OGC actively pursues its stated common platform, by whatever means (and I admit I do not know of a perfect implementation of such a policy). -- Peter Baumann

-- PeterBaumann - 30 Jun 2013
 

Specification Focus

The OGC has been asked if it has a position on the adoption of new standards that overlap or diverge with the existing OGC standard base. At the Boulder 2011 meetings, the OGC Board, PC, and OAB had discussions on this issue. However, there was no guidance provided and no OGC member discussion. A more clear set of guidance would be appreciated.

Should the OGC accept work on new standards without topic restriction, possibly duplicating existing standards, or should the OGC attempt to develop a coherent set of standards?

An overlap is good, actually: it allows implementers and users to make choices based on secondary criteria, in addition to just functional considerations. Example: the coverage datastructure has been split off the Web Coverage Service, thereby allowing to serve them via WFS (!), WCS, SOS, WPS, and the like. This fosters interoperability. OTOH, divergence IMHO should not be accepted by OGC (yes, I am opting for a strong and intervening governance here), because it counteracts a core mission of OGC; namely that of interoperability. For example, services must rely on OWS Common and data must relate themselves to GML (I do not say that GML should be the commonly used format, I see it more as an automatically verifiable conceptual model here - see WCS for an example how this can be done without a need for actually serving out coverages in GML).

-- PeterBaumann - 30 Jun 2013
 

Specification Market

Should the OGC review the 'market' for proposed standards before accepting the formation of a standards working group (SWG)?

It should be(come) a matter of good practice for spec proposition (including SWG charters) to provide a "state of the art / market" section justifying the need for a new spec, and likewise to convince that the spec writers are aware of existing technologies and will not invent incompatible wheels.

-- PeterBaumann - 30 Jun 2013
 

Specification Innovation

The OGC specifications must obviously evolve to support emergent technologies and shifts in markets. The issue of how this shifts can be promoted and how that promotion takes into account existing standards must be resolved. The OGC has a set of mature standards that have been braodly implemented, have been mandated in numerous legal contexts, and which provide, despite their flaws, a much higher level of interoperability than prior to the work of the OGC. However, there may be numerous market forces (business, technical, human, and cultural) that may be driving requirements for lighter, more agile standards that may conflict with the existing OGC baseline. The OGC members have always been highly innocative and creative. How does the OGC accommodate the installed base using the current OGC/ISO baseline with the requirements of the mobile internet, Internet of Things, AR, and so forth?

There are related questions and issues related to the OGC having standards that have some level of overlapping capability:
  • Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
  • If there is overlapping functionality on one or more OGC standards, we need to consider the cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
  • Can the OGC membership reach any consensus that harmonization and innovation are accepted principles / goals of the consortium?
  • How will OGC address externally submitted spatial / location standards that are widely (globally) used and overlap or conflict with the existing OGC baseline?
  • Who would maintain the externally developed specifications that then become OGC standards, and what are the IPR implications of such a setup?
  • How might the OGC development process be modified to encourage documentation as the last phase of the process, with heavy emphasis on experimentation, testing, validation up front?

These questions relate to an agile process and to the experience gained from the OGC testbed process.

How should the OGC adapt to the rise of mobile devices which has greatly changed the landscape for mass market spatial data infrastuctures?

I do not see that agility and innovation (both being immensely necessary in this fast-paced domain) necessarily contradict interoperabilty and harmonization. I do see, however, that there is a genuine role for OGC (staff) to ensure this. OAB actually is meant for this, but could improve on fulfilling this role. To put it short, OAB should facilitate, upon spec submission by SWG (at the latest) an open, synchronized assessment process. This is done in a relatively lax way today, and with sometimes extremely time-consiming back-and forth discussion over months and (yes!) sometimes even years. My record is 2 years. Already in 2011 I have proposed that upon spec submission there is a f2f or at least telecon meeting where all stakeholders are engaged: spec writers; OAB; OGC-NA; editors of possibly overlapping specs; OGC staff facilitating; other potentially interested stakeholders (so a public announcement should be made for this session). Unfortunately, this has never happened, although OGC staff confirmed the potential of benefits for timeliness and quality of spec adoption.

-- PeterBaumann - 30 Jun 2013
 
Topic revision: r4 - 30 Jul 2013, AdrianCuster
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback