|Sub-Group Lead||Staff Facilitator||Topic|
|Jack Pellicci||Mark Reichardt||Vision, Mission, Values|
|Stan Tillman||Carl Reed||Standards Diversity|
|Stan Tillman||Carl Reed||Standards Life Cycle And Harmonization|
|Stan Tillman||Carl Reed||External Submissions|
|Stan Tillman||Carl Reed||SWG Creation|
|Sam Bacharach||Bart De Lathouwer||Quality versus Quantity|
|Geoff Zeiss||Nadine Alameh||Integrate Programs|
|Geoff Zeiss||Nadine Alameh||Improve Communication|
|Frank Sukyens||Mark Reichardt||Active Direction|
|David Lemon||George Percival||OAB|
|Update Vision Statement|| Recommend replacing the OGC Vision statement (http://www.opengeospatial.org/ogc/vision):
“Realization of the full societal, economic and scientific benefits of integrating electronic location resources into commercial and institutional processes worldwide.”
with the Vision statement developed as part of the OGC 2005 strategic planning activity advanced by the OGC Board of Directors:
*“A world in which everyone benefits from the use of geospatial information and supporting technologies”*
This latter statement simplifies the message intended for a vision, and reflects not only the vision of the consortium as an organization, but its members as well.
|Establilsh Core Value Statement|| As a complement to the OGC Vision and Mission, recommend that OGC adopt the following set of Core Values that articulate the durable and underpinning guiding principles of the Consortium.
Conduct operations in an honest, transparent and ethical manner
Strive to achieve the highest quality innovative processes, geospatial standards and supporting services.
Work cohesively with members, partners and the global geospatial community
Empower members, partners and staff to provide the global community with the most relevant and effective geospatial standards and supporting services.
Effectively manage and maximize the return on investment provided by members and partners
|Update Mission Statement|| Recommend replacing the current OGC mission statement featured on the OGC public website (http://www.opengeospatial.org/ogc/vision):
“To serve as a global forum for the collaboration of developers and users of spatial data products and services, and to advance the development of international standards for geospatial interoperability.”
with the following revised Mission statement, which places primary emphasis on standards and related services, establishes the necessary linkage of standards with the enabling OGC process, and removes potential confusion by mixing of terms (e.g. “spatial”, “geospatial”):
*“To advance the development and use of international standards and supporting services that promote geospatial interoperability. To accomplish this mission, OGC serves as the global forum for the collaboration of geospatial data / solution providers and users.”*
|Update Strategic Goals|| Recommend update to OGC Strategic goal 2 to emphasize standards and interoperability focus on both infrastructure and end use - as identified in the TopicUpdateVision discussion:
Goal 1 - Provide free and openly available standards to the market that are of tangible value to Members and have measurable benefits for users.
Goal 2 - Lead worldwide in the creation and establishment of standards that enable global infrastructures for delivery and integration of geospatial content and services into business and civic processes.
Goal 3 - Facilitate the adoption of open, spatially enabled reference architectures in enterprise environments worldwide.
Goal 4 - Advance standards to support formation of new and innovative markets and applications for geospatial technologies.
Goal 5 - Accelerate market assimilation of interoperability research through collaborative consortium processes.
Discussed and suggested 2 recommendations for dealing with embracing diversity through different APIs.
|Early Evaluation of new domain's usefulness and applicability to OGC||
Recommend that a process be put in place to determine of the value a new domain brings to the OGC.
This should ensure that this domain serves OGC as a whole as opposed to a small group attempting to advance their cause.
It should also provide a detailed understanding of the groups purpose - perhaps through a "charter-like" document. This could then be used to promote marketing communications.
|Early Evaluation of new domain's uniqueness||
Recommend an early evaluation to determine whether the efforts of the new domain overlap other DWGs and would it be more appropriate to merge that domain with an already existing DWG
This would reduce the overall overhead of maintaining multiple groups.
|Early Evaluation of new overlapping functionality and its benefit to OGC||
The OGC should establish a rigorous review process that occurs at the beginning of a new standard to ensure that value (improves innovation, strong user base, etc.) is added to the standards baseline
In the case of overlapping functionality, this review should evaluate the value of adding a different API by identifying the new use case that it solves.
The key here is to evaluate the benefits/costs of a new standard before a lot of effort is devoted with a SWG process.
|Regular evaluation of standards use and uptake||
Recommend a regular evaluation of a standards’ effectiveness through use and/or uptake to determine whether they should be deprecated or retired.
In the case of overlapping functionalities, this would aid in determining if one API was preferred in the market over another.
|1 Engage the community||Each Interoperability Program should engage the community (internal and external to OGC) during the planning phases of each initiative|
|2 Increase awareness||At every TC meeting an Interoperability Program update should be provided to the membership to increase awareness of planned and ongoing activities as well as policies and procedures|
Discussed and recommended that proposals be formally presented to the TC and voted on by the TC
|Acceptance of External Standards||Generally accepted that External Submissions should be allowed to come into OGC. But anything coming to OGC from outside (either by existing members or potential members), should go through an “early” evaluation process to test the validity of adding it to the OGC baseline.|
|Early criteria measurement of potential External Submissions|| Establish a set of criteria that can be applied to the initial evaluation of an external proposal. Some of these might involve the following (but are not limited to):
a. Resources available?
b. Is the submitting group willing to actually work with the OGC and abide by the OGC <nop>PnP?
c. Willing to transfer IPR/copyright to OGC?
d. Willing to allow some level of changes to the specification?
e. How does accepting the proposal benefit OGC?
f. How does accepting the proposal hurt OGC?
|Early TC Approval of potential External Submissions||
Modify the process of submitting proposals to address issues & concerns at the beginning of the process. The submission should begin with draft package to the TC that includes:
This recommendation is meant to allow proposals to be reviewed and well advertised at the beginning of the process so the SWG can focus on the technical aspects - any political and non-technical issues should be addressed before the end of the process.
It was pointed out that this activity would be good for internal standards as well.
Discussed and suggested 2 recommended approaches for harmonizing externally
|Internal Harmonization as the first priority||
Recommend that OGC strongly encourage internal harmonization of OGC standards wherever possible and practical.
This recommendation is meant push organizations to look first at harmonizing (through document modifications)as the first option.
|Detailed documentation for standards where harmonization is not achievable||
If internal harmonization is not achievable, the rationale, benefits, impacts and harmonization approaches related to overlapping or divergent standards should be fully documented inside the standard.
This documentation should be detailed enough to provide a communication tool to help in communicating how a standard diverges and why it needs to do so.
|Harmonization through external communication||In order to promote harmonization in various domains, OGC should communicate to those domains and other communities of interest regarding the utilization of OGC standards and concepts.|
|Routine harmonization through regular standards maintenance||Through maintenance of OGC standards, OGC should work to incorporate external harmonization actions where possible and practical.|
|Improve support to Standards development process||
Standards development benefits significantly from defined processes, milestones and associated templates and artifacts in order to create consistent quality standards.
Provide engineers/architects with self assessment toolset for a standard/ checklist (simple / top 10 items / best practices)
Testing the standard in multiple organizations and environments using PlugFest -like initiatives (including all options).
Dedicated OGC-staff that monitors quality: consistent, well written (incl. grammar, spelling, syntax)
|Review existing standards for quality||
Use checkist and assesment tool to review existing standards for quality and record suggestins for improvement in considerant of future updates.
Where warranted, based on review, initiate an RFC.
Prioritize review based on popularity
|Develop concise overviews for each Standard for managers, architects and programmers||
Concise and Consistent Overviews should be written for each standard.
1 pager with the standard does / overview, purpose of the standard for decision makers
provide overview / big picture (architect)
technical folks (architect/programmers) on implementation of the standard
every std has scope and technology
|Consistent editorial review||
Consistent editorial review of standards for: clear writing, consistent structure, consistent terminology, implementability, testability.
|Additional OGC Staff for Standards Program 'DocLead'||
Additional OGC staff time is needed for several aspects of standards creation and maintenance (documentation, editing, harmonization, conformance to guidelines, ...). Specific recommendations for separate aspects are formulated separately, but most rely on addtional time and effort of OGC Staff.
Each SWG would now have access to professional editor support to edit, correct, improve draft specifications and to make them comply to the documentation and modularity guidelines.
|Publish standards in HTML||
Standards should be available in HTML format.
Existing standards should be converted based on priority (implementations, age, ...)
|Revise standards document format, template, and guidelines||
A new format and template should be defined for standards documents (and other documents).
The format should facilitate conversion to a format/style/layout that conforms to W3C web accessibility guidelines. This enables members/governments to provide the documents according to their accessibility regulations.
Template and tooling should support extraction of information such a glossary, definitions across standards. That way a global glossary may be created and made available on-line.
SWGs may decide to host their ongoing work on repositories such as GITHUB. However, guidelines should state requirement of access to the documents from secure environments (e.g. easy import/export to allow access from sites blocking github) - NB. this requirement seems better suited for the SWG topics.
|Continue revision of Mod Spec||The Mod Spec has improved modularity and consistency in the specifications. However, some aspects in the mod spec could be simplified and improved.|
|Provide better infrastructure to log and maintain change requests|| Change requests should be logged in an issue tracking system to allow easier identification, maintenance, member access, etc.
The infrastructure should be set up and hosted by OGC and preferably not rely on external systems (github, ...).
Access rights should include OGC members (at least), potentially others.
|Provide an exemplary standard specification||
Once the mod spec and doc format/guidelines would be updated, it is recommended to take one standard specification (ongoing/new/existing) and spend extra effort to make it the perfect example of a specification following the new guidelines.
The mod spec itself might be a candidate, as it is a specification, is being rewritten, and should be an example of what it imposes to other standards.
|Combine all documents, templates and guidelines for standard specs in one place|| There should be a SWG starter package which includes all the latest guidelines and templates.
Now the mod spec is in a different place than the doc template. The templates are located in the 'pending document' section, which may not be obvious for new SWG contributors.
|Create concrete plan for OGC NA service|| The OGC Naming Authority (NA) is a service provided by OGC. The current version was realized mainly by member resources.
It is expected that the importance of the NA will grow, and other organizations such as the WMO are moving in that direction as well.
The NA is a critical service for OGC and should be well maintained and evolved. OGC Staff should lead this and be able to allocate resources for the evolution and maintenance.
A first step is to create requirements and a plan for the next generation of the NA.
|Maintenance and harmonization of OWS Common and similar supporting standards/documents for which member resources are scarce.|| OWS Common underpins several W*S specifications. While W*S standards are evolving by membership involvement, this is less so for OWS Common, yet it should form the base of the evolving W*S standards as well.
OWS Common evolution and maintenance should be driven by OGC Staff. Harmonization with new version of W*S, application in these W*S standards should be driven by staff, possibly aided by the membership.
A process for such evolutions should be defined and documented.
Other common standards (SWE Common) or underpinning documents and standards should receive the same 'OGC maintained' status. Such a status must be assigned carefully to ensure OGC Staff can handle the workload.
Note: Ideally the mod spec should naturally integrate with having common parts in different specifications.
|Web page detailing ongoing staff activities||
During Ideas4OGC discussions, it became clear that a lot of things are already being investigated and worked on by OGC Staff.
A oral report is being given to the planning committee at regular times. It may be useful to report/publish the main topics and results to the TC.
|Develop "one pagers"||Develop a set of accessible, concise summaries of OGC rules, policies and procedures targetted on OGC "newbies" and people who are "newbies" with respect to a particular OGC area such as standards (SWGs), interoperability (IP) or vertical industries (DWGs).|
|Commend OAB members||Members of the OAB are to be commended and thanked for their contributions to the OGC and the OAB.|
|Communicate OAB roles to members||
It is evident that the membership don't clearly understand the role of the OAB within the OGC governance structure. As a result, assumptions are made. In addition, if one tries to find the OAB on the OGC website, it is not easy to find, not well described in terms of its role and powers and its relationship to the other parts of the OGC governance structure. Efforts should be taken to communicate the role of the OAB to the OGC membership. The functions of the OAB as defined in the Bylaws and OAB P&P should be highlighted to the members. Explain what the OAB reviews in terms of new standards, what topics they advise on and which items they take decisions on. It could appear that this is blury in terms of what is advice, approval or decision coming out of the OAB (e.g. review of standards documents, advising OGC staff on issues, and making decisions that affect the TC, (P&P voting procedures). What about its role with respect to architecture? Also, the role of the OAB is quite significant to the standards process and the members of the OAB do quite a lot of work and contributions which is not well communicated.
- Explain to members the process to provide input to the OAB
|Review Bylaws and OAB P&P||
This review has not been thorough enough to be able to recommend changes to the OGC By-Laws as they relate to the OAB or the OAB Policies and Procedures themselves. However, enough evidence has been gathered to determine that both the By-Laws and OAB Polocies and Proecures need to undergo a thorough review and possibly updating.
Reasons for undertaking this review include:
The scope for this review should include:
|Employ OGC Staff Editor||
Following from the previous recommendation, it is clear that a great deal of time for OAB members is taken reviewing the structure of submitted documents. This is not a good use of OAB members time.
It is recommended that OGC employ a staff editor whose primary role will be to ensure documents submitted to the OAB for review meet OGC requirements for structure.
|Prioritize OAB routine workload||As an extremely broadly tasked and busy group the OAB needs to reassess and prioritize its duties. Presently the OAB provides guidance for maintaining the OGC Reference Model, provides roadmaps for standards, monitors current technology trends and identifies technology gaps, reviews and makes recommendations on RFC submissions, reviews and makes recommendations on any developing work items, recommends relationships with other standards bodies, makes recommendations for guidance related to the life cycle management of the OGC baseline, assumed the role of the OGC Review Board and assists in conflict resolution and appeals, provides a sounding board for the TCC, and provides advice on other OGC process as well as technical and architecture topics.|