Operational Procedures for the Organization and Management of the S-100 Geospatial Information Registry

Transcription

1 INTERNATIONAL HYDROGRAPHIC ORGANIZATION Operational Procedures for the Organization and Management of the S-100 Geospatial Information Registry Edition November 2012 IHO Publication S-99 Published by the International Hydrographic Bureau MONACO 1

2 Copyright International Hydrographic Organization 2012 This work is copyright. Apart from any use permitted in accordance with the Berne Convention for the Protection of Literary and Artistic Works (1886), and except in the circumstances described below, no part may be translated, reproduced by any process, adapted, communicated or commercially exploited without prior written permission from the International Hydrographic Bureau (IHB). Copyright in some of the material in this publication may be owned by another party and permission for the translation and/or reproduction of that material must be obtained from the owner. This document or partial material from this document may be translated, reproduced or distributed for general information, on no more than a cost recovery basis. Copies may not be sold or distributed for profit or gain without prior written agreement of the IHB and any other copyright holders. In the event that this document or partial material from this document is reproduced, translated or distributed under the terms described above, the following statements are to be included: Material from IHO publication *reference to extract: Title, Edition+ is reproduced with the permission of the International Hydrographic Bureau (IHB) (Permission No./ ) acting for the International Hydrographic Organization (IHO), which does not accept responsibility for the correctness of the material as reproduced: in case of doubt, the IHO s authentic text shall prevail. The incorporation of material sourced from IHO shall not be construed as constituting an endorsement by IHO of this product. This *document/publication+ is a translation of IHO *document/publication+ [name]. The IHO has not checked this translation and therefore takes no responsibility for its accuracy. In case of doubt the source version of [name] in *language+ should be consulted. The IHO Logo or other identifiers shall not be used in any derived product without prior written permission from the IHB. 2

3 Table of Contents 1 Introduction and History Structure of the Registry and Registers Domains Roles and Responsibilities for the Management of the Registry and Registers Registry Owner Registry Manager Register Owner Register Manager The Domain Control Body Executive Control Body Representatives of Submitting Organizations Eligibility List of Submitting Organizations Administration of the Feature Concept, Portrayal and Metadata Registers Addition of registered Items Clarification of Registered Items Supersession of Registered Items Retirement of Registered Items Administration of the Product Specification Code Register Administration of the Producer Code Register

4 1 Introduction and History Edition In January 2010 the International Hydrographic Organization (IHO) adopted S-100, a framework geospatial standard for hydrographic and related data. S-100 is aligned with the ISO series of geographic standards thereby making the use of hydrographic and other geographic data more interoperable than previously using the IHO S-57 data transfer standard. S-100 is underpinned by a Registry and component Registers based on ISO Procedures for registration of items of geographic information. The IHO owns and manages the Registry. This document describes the roles, responsibilities and procedures for operating and managing the S-100 Geospatial Information Registry and its component Registers. Edition As a result of the practical use of the S-100 Registry by the Registry Manager and other organisations outside the IHO that are using S-100, a number of revisions have been introduced in edition These revisions concern conceptual rather than substantive changes to the notion of domains and the previous theoretical subdivision of the Registry into main and supplementary registers. The time limit on consideration of proposals has also been extended from 30 days to 60 days in order to allow stakeholders, as represented by the Domain Control Bodies, more time for consideration. 4

5 2 Structure of the Registry and Registers Registry The S-100Geospatial Information (GI) Registry shall be hosted on an IHB server. Registers The Registry consists of five types of Registers: Feature Concept Register Portrayal Register (not yet established estimated May 2013) Metadata Register (not yet established estimated December 2013) Product Specifications Register (not yet established estimated October 2012) Data Producer Code Register Figure 1 Relationship between the Registry and the Registers 5

6 The Feature Concept, Portrayal and Metadata Registers are, in effect, managed lists or dictionaries of items. Selections from these three Registers are used to define Feature and Portrayal Catalogues used in individual Product Specifications. The Product Specification Register is a list of S-100 based Product Specifications created by recognized organizations describing meta information about the content, purpose, version, location and availability of those Product Specifications. It also includes IHO S-57 Product Specifications that were previously developed. The Data Producer Code Register is the authoritative list of the codes which can, if required, be stipulated in Product Specifications to identify the producers of a particular data product; for example, Hydrographic Offices for ENC producer codes. The Data Producer Code Register incorporates the ENC producer codes previously listed in IHO Publication S-62 ENC Producer Codes, together with the S-57 data producer codes that were listed on the Open ECDIS forum website ( These downloadable files provide the most up to date records in the registry. IHO Publication S-62 - now titled List of Data Producer Codes is now an on-demand copy of the contents of the data producer code register and is available directly from the GI Registry and from the publications page on the IHO website. A machine readable XML version of the codes will be available for use in systems when the S-101 ENC Product Specification is published by the IHO. The Data Producer Code Register is sub divided as follows: Producer Codes allocated to State authorities for use in products authorised by the parent State All other Producer Codes 2.1 Domains Within the Feature Concept, the Portrayal and the Metadata Registers each entry is assigned to a recognised domain. The purpose of designating domains and a related Domain Control Body is to ensure that the key stakeholders (as represented by the domains) are consulted in any subsequent proposals to adjust items contained in a Register. The Feature Concept Dictionary Register presently encompasses domains for nautical charts, nautical publications, inland ENC, sea ice coverage, and marine information overlays (MIO). Other maritime data domains will be included over time as the Registry expands and is used more widely. Figure 2 Domains within Registers 6

7 2.1.1 Establishment of Domains Any recognized organization can propose a new domain. A Register Manager may also propose a new domain depending on the needs of a Register, its existing users or an awareness of any potential new users or new requirements. The following information shall be provided to the HSSC for proposals for any new domains: a short description of the proposing organization (name, role, etc.), an official point of contact, including and other relevant contact details, the proposed name of the new domain, a clear statement of the intended scope of the proposed domain, a justification for the proposal, and a confirmation of willingness of the proposing organization or body to act as Domain Owner in the Domain Control Body. An application form for proposing a new domain shall be available on the S-100 GI Registry website. The Register Manager shall be responsible for processing applications. The Executive Control Body shall review and endorse any proposals and the HSSC shall decide on proposals for new domains on behalf of the Registry Owner (IHO). 7

8 3 Roles and Responsibilities for the Management of the Registry and Registers Registry Registry Owner The S-100 GI Registry is owned by the IHO Registry Manager The S-100 GI Registry Manager shall be appointed by the IHB. The function may be fulfilled using IHB staff, contracted personnel or volunteers, depending on resources available. The Registry Manager is responsible for the day-to-day operation of the Registry. This includes: providing Registry access for the Register Manager(s), Control Bodies, Submitting Organizations and Register Users; ensuring that information about items in the Registers is accessible for users including those items that are valid, superseded, or retired; and maintaining a daily backup routine of the database Register Owner The IHO is the owner of all Registers in the S-100 GI Registry Register Manager The Register Manager(s) shall be appointed by the IHB. This function may be fulfilled using IHB staff, contracted personnel or volunteers, depending on the resources available. A Register Manager is responsible for the administration of a Register. includes: This sustaining the necessary coordination between Submitting Organizations, Control Bodies and the Registry Manager; inspecting and processing the various application forms; maintaining items within the Register; maintaining and publishing a list of Submitting Organizations; and providing periodic reports at intervals no greater than 12 months to the Executive Control Body and to the HSSC. Each report shall take account of all notable events since the last report, including: o o o proposals received and the decisions taken, any new enrolments of representatives of Submitting Organizations, and all other matters of interest and relevance to the ECB or HSSC. Availability of Information in Registers Register Manager(s) shall ensure that information about valid, superseded, or retired items in the Registers is readily available to users. The method for providing this information may depend upon the requirements of the members of the user community. 8

9 Security and Integrity of the Registry Register Manager(s) shall ensure that, for each Register being managed: all aspects of the registration process are handled in accordance with good business practice; the content of the Register is accurate; and only authorized persons can make changes to the contents of a Register. Registry Manager(s) shall ensure the security and integrity of the Registry using IT best practices. Registry Control Bodies The Feature Concept Register, the Portrayal Register and the Metadata Register shall each be overseen by two control bodies, a Domain Control Body (DCB) that will assess and endorse proposals and an Executive Control Body (ECB) that will oversee the operation of the Registers and adjudicate any disputes. DCB and ECB oversight is not required for the Product Specification Register nor the Producer Agency Code Register because they are both, in effect, non-discretionary lists of entries requiring little or no decision making or vetting. The DCB and ECB will conduct all its work by correspondence, using automated registry facilities, such as automatic alert generation and on-line review facilities, wherever possible The Domain Control Body The Domain Control Body (DCB) shall consist of a representative of each of the domains recognized in each Register type Domain Control Body Members Domain Control Body members are responsible for: acting as the spokesperson for their domain, canvassing other members in their domain for an opinion on the acceptability of any new proposal. How this is organized is at the discretion of the Domain Owners, and forwarding a decision to the Register Manager within 60 days. The overriding purpose of the DCB is to assess the suitability of every new proposal submitted to a Register. Any rejection of a proposal by a member of the DCB must be fully justified. Criteria for not accepting a proposal includes: the specification of the item is incomplete or incomprehensible, an identical or very similar item already exists in the Register or in another Register in the Registry, the proposed item does not belong to an item class included in a Register, the proposed item does not fall within the scope of a Register, or the justification for the proposal is inadequate Executive Control Body The Executive Control Body (ECB) shall consist of a representative of each of the Domains. 9

10 The ECB will monitor and advise the Register Manager(s) and act as arbiters for any decisions or disputes in the Register process. In the event that a resolution cannot be achieved, the ECB may ask for the decision of the HSSC. The ECB will monitor enrolment requests from representatives of Submitting Organizations to confirm the appropriateness of the participation of a Submitting Organization and its representative in the registry. The ECB may de-register a representative of a Submitting Organization if they are considered inappropriate or unrepresentative. In the event that a dispute arises, the ECB may ask for the decision of the HSSC. The ECB will conduct annual reviews of the participation rate of representatives of Submitting Organizations in order to confirm their eligibility to remain enrolled. Periods of inactivity greater than 18 months may be regarded as inactive. Submitting Organizations Submitting Organizations propose changes and additions to the contents of Registers. Submitting Organizations will normally represent a recognized body or stakeholder group (such as from government, industry, academia, and relevant user groups). Registered submitting organizations may submit proposals for consideration under any domain in a register. Stakeholders and any other interested parties who do not wish to enrol should submit proposals through an existing Submitting Organization Representatives of Submitting Organizations Representatives of Submitting Organizations are responsible for: acting as the spokesperson for their Submitting Organization, developing proposals with other members in their Submitting Organization. How this is organized is at the discretion of the Submitting Organization, and Eligibility forwarding proposals to the relevant Register Manager. An automatic on-line registration form to enrol as a representative of a Submitting Organization shall be available on the S-100 GI Registry website. Applications shall provide at least the following information: Organization to which the applicant is associated or is representing Given name of representative Family name of representative Mailing address address Preferred password Justification for being recognized as a Submitting Organization List of registries to which the Submitting Organization wishes to actively participate More than one representative may enrol on behalf of each Submitting Organization. 10

11 The Register Manager shall inspect all incoming enrolments to ensure that they are legitimate and meet the aims and requirements of the Registry. The Register Manager shall alert the ECB for all suspect enrolments. Submitting Organizations may be de-registered if they become inactive List of Submitting Organizations The Register Manager(s) shall maintain and publish a list of all recognized Submitting Organizations that may submit proposals for changes to the registry. Each list shall include the name and contact information for the representatives of each Submitting Organization. Register User A Register User is any person or organization requiring to access and to use the contents of a Register. 11

12 4 Administration of the Feature Concept, Portrayal and Metadata Registers Introduction Submitting Organizations may submit proposals for new items, or for clarification, supersession, or retirement of registered items. Proposals are to be submitted using the mechanisms provided in the Registry web interface Addition of registered Items An Addition is the insertion into a Register of an item that describes a concept not adequately described by an item already in the Register Clarification of Registered Items A Clarification corrects errors in spelling, punctuation, grammar or improvements to content or wording. A clarification shall not cause any substantive semantic change to a registered item. The three characteristics that can be clarified are definition, other references, and remarks Supersession of Registered Items A Supersession of an item means any proposal that would result in a substantive semantic change to an existing item. Supersession shall be accomplished by including one or more new items in the appropriate Register with new identifiers and a more recent date. The original item shall remain in the Register but shall include the date at which it was superseded, and a reference to the items that superseded it Retirement of Registered Items A Retirement shall be effected by leaving an item in the Register, but by marking it as retired, and including the date of retirement. Development of Proposals Submitting Organizations shall manage the development of proposals for entries or amendments to the Feature Concept, Portrayal and Metadata Registers from within their respective Working Groups, communities or organizations. Submission of Proposals The process for submitting proposals for the registration of items in the Feature Concept, Portrayal and Metadata Registers is illustrated in Figure 3. Submitting organizations shall: a) receive proposals for the registration of items from proposers within their respective Working Groups, communities or organizations; b) ensure that all proposals are logical and complete and are consistent with other features, attributes and enumerated values; and c) submit proposals to the appropriate Register and domain. A Register Manager shall: a) receive proposals from Submitting Organizations, b) review proposals for completeness, c) return proposals to the Submitting Organization if incomplete, and d) update the item management record, with the status set to pending. A Register Manager shall use the following criteria to determine if a proposal is complete: a) the proposal is from a recognized Submitting Organization, 12

13 b) the proposed item falls within the scope of the Register or domain, and c) a registered item (or similar) to the proposed item does not already exist. The Register Manager shall then submit the proposal to the Domain Control Body in accordance with the following submission process. 13

14 Submission Process - Feature Concept, Portrayal and Metadata Registers Proposer Submitting Organization Register Manager Develop Proposal Forward to Submitting Organization Review Proposal Amend Proposal No Proposal Appropriate & Complete Yes Submit Proposal Review Proposal Inform Submitting Organization of Additional requirements No Proposal Complete Yes A Figure 3 Processing of Proposals 14

15 Approval Process The process for determining the acceptability of proposals is illustrated in Figure 4. The approval process shall normally be completed within a time period of 60 days. In the case of appeal this period shall be extended to 90 days. The Register Manager shall ensure the following: a) if the proposal is for clarification or retirement of a Register item, forward the proposal to the Domain Control Body; or b) if the proposal is for registration of a new item or supersession of an existing Register item: 1) assign an itemidentifier to the new or superseding item, 2) set the status of the item to notvalid'; and 3) inform the Domain Control Body of the new proposal within five working days. The Domain Control Body can decide to: a) accept the proposal without change, b) accept the proposal subject to changes negotiated with the Submitting Organization, or c) not accept the proposal. Criteria for not accepting a proposal include: a) the specification of the item is incomplete or incomprehensible, b) an identical or very similar item already exists in the Register or in another Register of this Registry, c) the proposed item does not belong to an item class included in this Register, d) the proposed item does not fall within the scope of an appropriate Register, or e) the justification for the proposal is inadequate. Each Domain Control Body member shall inform the Register Manager of their working group / organization s decision, and the rationale for that decision, within 60 days of receipt of the proposal. Nil returns will be taken as acceptance of the proposal. The Register Manager shall: a) serve as the point of contact if there is a need for negotiations between a Submitting Organization and a Domain Control Body regarding any changes required to a proposal that may be specified by the Control Body as a condition of acceptance; and b) inform the Submitting Organization of the results of processing a proposal. If the decision of the control body is positive, the Register Manager shall in accordance with policies for the Register: a) complete the proposal management record with status set to final, disposition set to accepted', and datedisposed to the date of the Domain Control Body s decision, 15

16 b) make approved changes to the content of the Register item, c) set the Register item status to valid', 'superseded', or 'retired', as appropriate. If the decision of the control body is negative: a) update the proposal management record by setting status to tentative', disposition to notaccepted', and datedisposed to the date of the Domain Control Body s decision, b) inform the Submitting Organization of the 60 working day deadline for appealing the decision of the Domain Control Body, and c) make the results of the approval process available to all interested parties. Submitting organizations shall: a) negotiate with the Domain Control Body through the Register Manager, regarding any changes to their proposals that are specified by the Domain Control Body as a condition of acceptance; and b) make known to the proposer and within their respective communities or organizations the decisions taken on proposals by the Domain Control Body as transmitted to them by the Register Manager. Withdrawal of Proposals Submitting organizations may decide to withdraw a proposal at any time during the approval process. The Register Manager shall then: a) change the proposal management status from pending to final', b) change the proposal management disposition to withdrawn and the value for datedisposed to the current date, and c) keep track of the proposal and report the withdrawal in the next periodic report. 16

17 Approval Process - Feature Concept, Portrayal and Metadata Registers Submitting Organization Register Manager Domain Control Body Resubmit Proposal See Figure 3 A Yes Clarification No Yes Resubmit No Retirement No Insert new item into register Yes Evaluate Proposal Withdraw Proposal Negotiate Change Yes Change Proposed? No No Process Complete Inform Update Status & Content Yes Accept Proposal Appeal Decision? Inform No Yes B Figure 4 Approval Process 17

18 Appeals A Submitting Organization may appeal to the Executive Control Body if it disagrees with the decision of a Domain Control Body to reject a proposal for addition, clarification, modification, retirement, or supersession of an item in a Register. An appeal shall contain at a minimum a description of the situation, a justification for the appeal, and a statement of the impact if the appeal is not successful. The appeal process is illustrated in Figure 5. The Registry Manager shall: a) determine if the decision regarding a proposal for registration is acceptable; and b) if not, submit an appeal to the Register Manager. The Register Manager shall: a) forward the appeal to the Executive Control Body; and b) if there is no appeal by the deadline for submitting an appeal, the Register Manager shall change the status of the proposal management record to final' and change the datedisposed to the current date. The Executive Control Body shall: a) process the appeal in conformance with its established procedures; b) decide whether to accept or reject the appeal; and c) communicate the decision to the Register Manager. The Register Manager shall: a) update the proposal management record fields disposition and datedisposed; b) update the Register item status; and c) provide the results of the decision to the Domain Control Body and to the Submitting Organization. The Submitting Organization shall: a) make the results of the appeal known within their Working Group, community or organization. 18

19 Appeal Process - Feature Concept, Portrayal and Metadata Registers Submitting Organization Register Manager Executive Control body HSSC B Submit Appeal Forward Appeal Decide Appeal Appeal Rejected Update Status Appeal to HSSC Yes Decide Appeal No Figure 5 Appeal process 19

20 5 Administration of the Product Specification Code Register Proposals Representatives of organizations may submit proposals for the Addition of new Product Specifications in the Product Specifications Register or for the Clarification, Supersession, or Retirement of existing Product Specifications in the Register. Requests are to be submitted using the mechanisms provided in the Registry web interface. Acceptance Criteria IHO Product Specifications. Product Specifications that have been adopted by the IHO will be recorded or referenced in the Register. These Product Specifications will carry the identifying code S-1nn and will also have a plain language title. Other Product Specifications. Product Specifications that have been developed by other competent organizations can be recorded or referenced in the Register provided that: a) they use S-100 as the underlying standard (organizations are encouraged to populate Feature Catalogues, either using existing entities registered in the GI Registry or proposing new ones where appropriate); b) any identification number of a plain language title used does not infer that it is an IHO standard or that it has received any endorsement or approval of the IHO; and c) the content description is described in plain language. Submission of Proposals The organization making a submission shall ensure that all proposals: a) are complete, and b) a copy of the final version of the new Product Specification is made available to the Register Manager. The Register Manager shall: a) receive proposals from Submitting Organizations; b) review proposals for completeness; c) return proposals to the Submitting Organization if incomplete; and d) update the item management record, with the status set to pending. The Register Manager shall use the following criteria to determine if a proposal is complete: a) the proposed item does not fall within the scope of the Register; or b) a registered item (or similar) to the proposed item already exists. Approval Process The Register Manager shall ensure that the acceptance criteria have been satisfied The Register Manager shall: a) serve as the point of contact if there is a need for negotiations with a Submitting Organization regarding any changes required to a proposal; and b) inform the Submitting Organization of the results of each proposal. 20

21 If the proposal is accepted, the Register Manager shall in accordance with policies for the Register: a) include the relevant details in the contents of the Register, If a proposal is not accepted, the Register Manager shall: a) inform the Submitting Organization of the 60 working day deadline for appealing the decision of the Register Manager and b) make the results of the approval process available to all interested parties. Withdrawal of Proposals Submitting Organizations may decide to withdraw a proposal at any time during the approval process. The Register Manager shall then: Appeals a) change the proposal management disposition to withdrawn and the value for datedisposed to the current date, and b) keep track of the proposal and report the withdrawal in the next periodic report. A Registry Manager may appeal to the Executive Control Body (and ultimately the HSSC) if it disagrees with the decision of the Register Manager to reject a proposal for the inclusion of a Product Specification in the Register. An appeal shall contain at a minimum a description of the situation, a justification for the appeal, and a statement of the impact if the appeal is not successful. The Submitting Organization shall submit its appeal to the Register Manager. The Register Manager shall: a) forward the appeal to the Executive Control Body or HSSC as appropriate, and b) inform the appellant of the decision. 21

22 6 Administration of the Producer Code Register Introduction Representatives of organizations that require a data producer code shall submit applications for a Producer Code, using the mechanisms provided in the Registry web interface. Eligibility Criteria Government Authorities. Data producer codes allocated to Governments, authorized Hydrographic Offices or other relevant government institutions will be recorded in the Register. Other Product Specifications. Data producer codes allocated to all other competent organizations and entities will also be included in the Register and will be distinguished from those allocated to government authorities. Submission of Applications The Submitting Organization shall ensure that all applications are complete. The Register Manager shall: a) receive applications from Submitting Organizations, b) review applications for completeness, and c) return applications to the Submitting Organization if incomplete. Approval Process The Register Manager shall ensure that: a) a suitable entry does not already exist in the Register, and if not; b) allocate a Producer Code; and c) inform the applicant within 10 working days. The Register Manager shall: Appeals a) serve as the point of contact if there is a need for negotiations with an applicant regarding any changes required to an application. An applicant may appeal to the Executive Control Body (and ultimately the HSSC) if it disagrees with the decision of the Register Manager to reject an application. The Submitting Organization shall submit its appeal to the Register Manager. The Register Manager shall: a) forward the appeal to the Executive Control Body or HSSC as appropriate, and b) inform the appellant of the decision. 22