Document History
| Version Number | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | January 2011 | TSAMDWG | Initial publication. |
| 1.1.0 | November 2012 | TSAMDWG | Revisions based on practical use of the IHO GI Registry. |
| 2.0.0 | May 2022 | S-100WG | Complete redrafting due to implementation of a new, restructured version of the IHO GI Registry and revision of S-100 Part 2 (S-100 Edition 5.0.0). |
1 Overview
1.1 Introduction and History
Edition 1.0.0
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 19100 series of geographic standards — thereby making the use of hydrographic and other geographic data more interoperable than previously done using the IHO S-57 data transfer standard.
S-100 is underpinned by a Registry and component Registers based on ISO 19135 — Procedures for registration of items of geographic information. The IHO owns and manages the IHO Geospatial Information (GI) Registry.
This document describes the roles, responsibilities and procedures for operating and managing the IHO GI Registry and its component Registers.
Edition 1.1.0
As a result of the practical use of the IHO GI Registry by the Registry Manager and other organisations outside the IHO that are using S-100, a number of revisions were introduced in edition 1.1.0. 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 was also extended from 30 days to 60 days in order to allow stakeholders, as represented by the Domain Control Bodies, more time for consideration.
Edition 2.0.0
In December 2020 a new version of the IHO GI Registry (Version 3.1) became operational. Along with further revisions due to continued practical use of the Registry, this version of the Registry includes a substantive change to the structure of the Registry, its interface and management processes in order to better enable the management of registered items within a multi-Domain environment. In order to achieve this, the former Feature Concept Dictionary Register has been split into two new Registers — the Concept Register and the Data Dictionary Register. The Concept Register is the repository for effectively “stateless” concepts that may then be assigned type and bindings to other concepts within the Data Dictionary Register in order to satisfy Domain requirements for Product Specifications.
1.2 Normative References
The following referenced documents are required for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including amendments) applies.
[1] S-100 edition 1.0.0: IHO Universal Hydrographic Data Model, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-100/S-100_Version_1.0.0.pdf).
[2] ISO 19103: Geographic information — Conceptual schema language, International Organization for Standardization (https://www.iso.org/standard/83454.html).
[3] ISO 19110: Geographic information — Methodology for feature cataloguing, International Organization for Standardization (https://www.iso.org/standard/57303.html).
[4] ISO 19115: Geographic information — Metadata, International Organization for Standardization (https://www.iso.org/standard/26020.html).
[5] ISO 19117: Geographic information — Portrayal, International Organization for Standardization (https://www.iso.org/standard/46226.html).
[6] ISO 19131: Geographic information — Data product specifications, International Organization for Standardization (https://www.iso.org/standard/85092.html).
[7] ISO 19135:2005: Geographic information — Procedures for item registration, International Organization for Standardization (https://www.iso.org/standard/32553.html).
[8] ISO 19126:2009: Geographic information — Feature concept dictionaries and registers, International Organization for Standardization (https://www.iso.org/standard/44875.html).
1.3 Terms, Definitions and Abbreviations
1.3.1 Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
Clarification
A non-substantive change to a register item.
[ISO 19135:2005]Control Body
Group of technical experts that makes decisions regarding the content of a Register.
In UML “a classifier that describes a range of values that instances of the classifier may hold.”
[ISO 19135:2005; ISO 19103, modified — adapted from ISO/IEC 19501]Data Product Specification
Detailed description of a dataset or dataset series together with additional information that will enable it to be created, supplied to and used by another party.
[ISO 19131]Note 1 to entry: A data product specification provides a description of Hydrographic and Marine-Related Concepts and a specification for mapping the universe of discourse to a dataset. It may be used for production, sales, end-use or other purposes.
Dataset
Identifiable collection of data.
[ISO 19115]Feature Catalogue
A catalogue containing definitions and descriptions of the feature types, feature attributes, and feature associations occurring in one or more sets of geographic data.
[ISO 19110]Metadata
Data about data.
[ISO 19115]Portrayal
Presentation of information to humans.
[ISO 19117]Portrayal Catalogue
Collection of defined portrayalsfor a Feature Catalogue.
Register
Set of files containing identifiers assigned to items with descriptions of the associated items.
[ISO 19135:2005]Note 1 to entry: Descriptions may consist of many types of information, including names, definitions and codes.
Register Manager
Organization to which management of a Register has been delegated by the Register Owner.
[ISO 19135:2005]Note 1 to entry: In the case of an IHO Register, the Register Manager performs the functions of the registration authority specified in the IHO Directives.
Register Owner
Organization that establishes a register.
[ISO 19135:2005]Registration
Assignment of a permanent, unique (in the Register), and unambiguous identifier to an item.
[ISO 19135:2005]Registry
Information system on which a Register is maintained.
[ISO 19135:2005]Retirement
Declaration that a register item is no longer suitable for use in the production of new data.
[ISO 19135:2005]Note 1 to entry: The status of the retired item changes from ‘valid’ to ‘retired’. A retired item is kept in the Register to support the interpretation of data produced before its retirement.
Submitting Organization
Organization authorised by a Register Owner to propose changes to the content of a Register.
[ISO 19135:2005]Supersession
Replacement of a Register item by one or more new items.
[ISO 19135:2005]Note 1 to entry: The status of the replaced item changes from ‘valid’ to ‘superseded.’ A superseded item is kept in the Register to support the interpretation of data produced before its supersession.
Type
Stereotype of class that is used to specify a domain of instances (objects) together with the operations applicable to the objects.
[ISO 19135:2005]Note 1 to entry: A type may have attributes and associations.
1.3.2 Abbreviated terms
DCB
Domain Control Body
ECB
Executive Control Body
GI
Geospatial Information
IALA
International Association of Lighthouse Authorities
IHO
International Hydrographic Organization
2 Structure of the Registry and Registers
2.1 Registry
The IHO Geospatial Information (GI) Registry shall be hosted on an IHO server.
2.2 Registers
A Register is simply a managed list. It is easier to maintain than a fixed document, because new items can be added as needed to the Register; and existing items in the Register can be clarified, superseded or retired. Each Register item has one or more dates associated with it that indicate when changes in its status occurred. This means that a Product Specification, defined at a given date, may reference an item in the Register at that specific point in time. The IHO GI Registry consists of six Registers:
Concept Register;
Data Dictionary Register;
Portrayal Register;
Metadata Register;
Product Specification Register; and
Producer Code Register.
Figure 2-1 — Relationship between the Registry and the Registers
A Concept Register specifies unique, independent sets of primary resources of basic information that may be used to describe geographic, hydrographic, and metadata information. These concepts as registered in the Concept Register may then be used within the Data Dictionary Register to develop a Feature Catalogue. Unlike a Data Dictionary Register, a Concept Register does not make associations; or define type or bindings of concepts to other concepts. From this perspective, registered items within the Concept Register are essentially “stateless”, which allows for flexibility of the use of the concepts for suitable data modelling to satisfy the requirements of Product Specifications.
The Concept Register specifies hydrographic core conceptual information (name, definition, camel case, etc.) corresponding to the concept; and these concepts can then be utilized within the Data Dictionary Register to satisfy the requirements of data models to be implemented in S-100 based Product Specifications.
The Data Dictionary Register specifies independent sets of definitions of features, attributes, enumerated values, and information types that may be used to describe geographic, hydrographic, and metadata information. The Data Dictionary Register may be used to assign an item defined in the Concept Register a type (for example feature, attribute and enumerate value); and define recommended associations and attribute/feature bindings to facilitate the development of Feature Catalogues. Items in the Concept Register can only be registered once against each type in the Data Dictionary Register in order to support interoperability.
The Portrayal Register specifies independent sets of definitions of point symbols, pattern symbols, complex line styles, and colour symbols; as well as symbol definitions, colour definitions, portrayal parameters and portrayal management concepts such as viewing groups. In addition, the Portrayal Register may be subdivided into different Domains. The Portrayal Register may be used to develop the Portrayal Catalogue. Unlike the Portrayal Catalogue, a Portrayal Register does not define the portrayal rules or bind the portrayal to a feature.
The Concept, Data Dictionary, Portrayal and Metadata1 Registers are, in effect, managed lists or dictionaries of items. Selections from these four 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.
The Producer Code Register2 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 Producer Code Register incorporates the up to date list of ENC Producer Codes that are 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 (www.openecdis.org). These downloadable files provide the most up to date records of ENC data producers. IHO Publication S-62 — now titled List of Data Producer Codes is an on-demand copy of the contents of the Producer Code Register; and can be downloaded directly from the IHO GI Registry.
A machine readable XML version of the IHO Producer Codes will be available for use in systems when the operational version of 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 authorized by the parent State; and
All other Producer Codes.
2.2.1 S-100 Test Bed
The S-100 Test Bed is a system to support the development of new Product Specifications based on the S-100 framework. Within the Test Bed, S-100 stakeholders and recognized organizations can create a new Product Specification and share their on-going project’s results, such as new draft versions of the Product Specification document; catalogue XML files; test datasets; and scenario’s for validation. Only S-100 based Product Specifications that pass the whole Test Bed process can be transferred to the Product Specification Register as an active specification.
2.3 Domains
Within the Data Dictionary, 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 Concept Register contains the core conceptual items that may be used within the Data Dictionary Register. As such, the Concept Register is essentially “domainless”. However, the Concept Register does have a Domain Control Body, which is comprised of the representatives of each of the Domains within the Data Dictionary Register.
The Data Dictionary Register encompasses Hydrographic-related domains such as nautical charts, nautical publications, inland ENC, port ENC, water levels and currents, and marine information overlays (MIO); as well as marine-related Domains for other international organizations such as the World Meteorological Organization (for sea ice and weather), IALA (aids to navigation), and the International Electrotechnical Commission. Other maritime data Domains may be included over time as the Registry expands and is used more widely.
Figure 2-2 — Domains within Registers
2.3.1 Establishment of Domains
Any recognized organization can propose a new Domain. A Register Manager may also propose a new Domain depending on the requirements of a Register, its existing users or an awareness of any potential new users or new requirements.
The body responsible for the approval of the establishment of new Domains in a Register is the IHO Hydrographic Services and Standards Committee (HSSC). The following information shall be provided to the HSSC via the Register Manager for proposals for any new Domains:
a short description of the proposing organization or body (name, role, etc.);
an official point of contact, including email 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 and provide representation to the Register Domain Control Body.
An application form for proposing a new Domain shall be available on the IHO 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).
3 Roles and Responsibilities for the Management of the Registry and Registers
3.1 Registry
3.1.1 Registry Owner
The IHO GI Registry is owned by the IHO.
3.1.2 Registry Manager
The IHO GI Registry Manager shall be appointed by the IHO. The function may be fulfilled using IHO Secretariat 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, clarified, superseded, or retired; and
maintaining a daily backup routine of the Registry database.
3.1.3 Register Owner
The IHO is the owner of all Registers in the IHO GI Registry.
3.1.4 Register Manager
The Register Manager(s) shall be appointed by the IHO. This function may be fulfilled using IHO Secretariat staff; contracted personnel; or volunteers, depending on the resources available.
A Register Manager is responsible for the administration of a Register. This includes:
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:
proposals received and the decisions taken;
any new enrolments of representatives of Submitting Organizations; and
all other matters of interest and relevance to the Executive Control Body or the HSSC.
3.2 Availability of Information in Registers
Register Manager(s) shall ensure that information about valid, clarified, 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 Register user community.
3.3 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.
3.4 Registry Control Bodies
The Concept Register, Data Dictionary Register, Portrayal Register and 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 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.
3.4.1 The Domain Control Body
The Domain Control Body (DCB) is a group of technical experts appointed by a Register Owner to decide on the acceptability of proposals for changes to the content of a Register. The group shall comprise experts in related fields that constitute the contents of the Register. The Domain Control Body (DCB) shall consist of a representative of each of the Domains recognized in each Register type.
NOTE For the Concept Register, the Domain Control Body consists of a representative of each of the Domains in the Data Dictionary Register (see Clause 2.3).
The Domain Control Body for the Concept Register shall also include a representative of the IHO Hydrographic Dictionary Working Group (HDWG) and the IHO Data Quality Working Group (DQWG).
3.4.1.1 Domain Control Body Responsibilities
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 through the approval process in the IHO GI Registry interface (NOTE; Nil returns will be taken as acceptance of the proposal).
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 (but may not be restricted to):
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.
3.4.2 Executive Control Body
The Executive Control Body (ECB) monitors and advises the Register Manager(s); and acts as arbiters for any decisions or disputes in the Register process. The Executive Control Body (ECB) shall consist of a representative of each of the Domains recognized in each Register type.
NOTE For the Concept Register, the Executive Control Body consists of a representative of each of the Domains in the Data Dictionary Register (see Clause 2.3). In the event that a resolution cannot be achieved, the ECB may request a decision from the HSSC.
The ECB shall 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.
The ECB shall 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.
3.5 Submitting Organizations
Submitting Organizations propose changes and additions to the contents of Registers.
Submitting Organizations shall 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.
3.5.1 Representatives of Submitting Organizations
The representatives of Submitting Organizations are essentially the designated representative of their recognized stakeholder group that contributes to the contents of a Register. There shall normally be only one member of the Submitting Organization nominated to be the Submitting Organization representative, however the group may nominate two representatives if considered necessary. Approval of Submitting Organization representative(s) is at the discretion of the Register Executive Control Body.
Representatives of Submitting Organizations are responsible for:
acting as the spokesperson for their Submitting Organization;
developing proposals in consultation with other members in their Submitting Organization. How this is organized is at the discretion of the Submitting Organization;
forwarding proposals to the relevant Register Manager through the approval process in the IHO GI Registry interface; and
communicating to and coordinating any response from the Submitting Organization in the event that a proposal is rejected.
3.5.2 Eligibility
An automatic on-line registration form to enrol as a representative of a Submitting Organization shall be available on the IHO 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.
e-mail address.
Unique ID (login).
Secure password.
Justification for being recognized as a Submitting Organization representative.
List of Domains to which the Submitting Organization representative wishes to actively participate.
More than one representative may enrol on behalf of each Submitting Organization, however this is discouraged (see Clause 3.5.1).
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 of all suspect enrolments for adjudication.
Submitting Organization representatives may be de-registered if they become inactive.
3.5.3 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 representative(s) of each Submitting Organization.
3.6 Register User
A Register User is any person or organization requiring access to and use of the contents of a Register.
4 Administration of Registers
4.1 Proposals
Submitting Organization representatives may submit proposals for new items; or for clarification, supersession, or retirement of valid registered items. Proposals are to be submitted using the mechanisms provided in the Registry web interface for the relevant Register.
4.1.1 Addition of Registered Items
An Addition is the insertion into a Register of a new item that describes a concept not adequately described by a valid item already in the Register.
4.1.2 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 may be clarified are definition, other references, and remarks.
4.1.3 Supersession of Registered Items
A Supersession of an item means any proposal that would result in a substantive semantic change to an existing valid item, such as a change to the name of an item or its camelCase identifier; or a change in the portrayal of an item in the Portrayal Register. 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 must include the date at which it was superseded, and a reference to the items that superseded it.
4.1.4 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.
4.2 Proposal Process — Concept, Data Dictionary, Portrayal and Metadata Registers
Submitting Organizations shall manage the development of proposals for entries or amendments to the Concept, Data Dictionary, Portrayal and Metadata Registers from within their respective Working Groups, communities or organizations.
The process for submitting proposals for the registration of items in the Concept, Data Dictionary and Portrayal Registers is illustrated in Figures 4-1 and 4-2 below.
Figure 4-1 — Processing of Proposals — Concept Register
Figure 4-2 — Processing of Proposals — Data Dictionary, Portrayal and Metadata Registers
4.2.1 Submission Process
The Submitting Organization representative shall:
receive proposals for the registration of items from proposers within their respective Working Groups, communities or organizations;
ensure that all proposals are logical and complete and are consistent with other registered items within the Register; and
submit proposals to the appropriate Register through the submission process in the IHO GI Registry interface.
The Register Manager shall:
receive proposals from Submitting Organizations representatives;
review proposals for completeness;
return proposals to the Submitting Organization representative if incomplete or inconsistent; and
update the item management record, with the proposalStatus set to ‘notYetDetermined’.
The Register Manager shall use the following criteria to determine if a proposal is complete:
the proposal is from a recognized Submitting Organization representative;
the proposed item falls within the scope of the Register or domain; and
a registered item (or similar) to the proposed item does not already exist.
If the decision of the Register Manager is positive, the proposal shall be forwarded to the Register Domain Control Body for approval. If the decision of the Register Manager is negative, the proposal shall be returned to the Submitting Organization representative for rework or cancellation as required.
4.2.2 Approval Process
The process for determining the acceptability of proposals is illustrated in Figures 4-1 and 4-2 above. 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:
if the proposal is for clarification or retirement of a Register item, set the itemStatus of the item to ‘processing’; and forward the proposal to the Register Domain Control Body; or
if the proposal is for registration of a new item or supersession of an existing Register item:
assign an itemIdentifier to the new or superseding item,
set the itemStatus of the item to ‘processing’; and
inform the Register Domain Control Body of the new proposal within five working days.
The Register Domain Control Body can decide to:
accept the proposal without change;
accept the proposal subject to changes negotiated with the Submitting Organization; or
not accept the proposal.
Criteria for not accepting a proposal include (but may not be restricted to):
the specification of the item is incomplete or incomprehensible;
an identical or very similar item already exists in the Register or in another Register of the Registry;
the proposed item does not belong to an item class included in the Register;
the proposed item does not fall within the scope of the Register; or
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 through the approval process in the IHO GI Registry interface. Nil returns will be taken as acceptance of the proposal.
The Register Manager shall:
serve as the point of contact if there is a need for negotiations between a Submitting Organization and the Register Domain Control Body regarding any changes required to a proposal that may be specified by the Domain Control Body as a condition of acceptance; and
inform the Submitting Organization representative of the results of processing the proposal.
If the decision of the Register Domain Control Body is positive, the Register Manager shall, in accordance with policies for the Register:
complete the proposal management record with proposalStatus set to ‘accepted’, and dateAccepted to the date of the Domain Control Body’s decision;
make approved changes to the content of the Register item; and
set the Register item itemStatus to ‘valid’, ‘clarified’, ‘superseded’, or ‘retired’, as appropriate.
If the decision of the Register Domain Control Body is negative, the Register Manager shall:
update the proposal management record by setting proposalStatus to ‘rejected’, and dateAmended to the date of the Domain Control Body’s decision;
inform the Submitting Organization of the 60 working day deadline for appealing the decision of the Domain Control Body; and
make the results of the approval process available to all interested parties.
Submitting Organization representatives shall:
negotiate with the Register 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
make known to the proposer and within their respective Submitting Organization communities or organizations the decisions taken on proposals by the Domain Control Body as transmitted to them by the Register Manager.
4.2.3 Withdrawal of Proposals
Submitting Organizations may decide to withdraw a proposal, using the withdrawal process in the IHO GI Registry interface, at any time during the approval process.
The Register Manager shall then:
change the proposal management proposalStatus from ‘notYetDetermined’ to ‘withdrawn’;
change the proposal management value for dateAmended to the current date; and
keep track of the proposal and report the withdrawal in the next periodic report.
4.2.4 Appeals
A Submitting Organization representative may appeal to the Register Executive Control Body if it disagrees with the decision of the Register Domain Control Body to reject a proposal for addition, clarification, supersession or retirement of an item 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 appeal process is included in the overall proposal process as shown in Figures 4-1 and 4-2 above.
The Submitting Organization shall:
determine if the decision regarding a proposal for registration is acceptable; and
if not, submit an appeal to the Register Manager through the appeal process in the IHO GI Registry interface.
The Register Manager shall:
if an appeal is submitted:
change the proposal management proposalStatus of the item to ‘appeal’; and
forward the appeal to the Executive Control Body; or
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 ‘rejected’; and change the dateAmended to the current date.
The Register Executive Control Body shall:
process the appeal in conformance with its established procedures;
decide whether to accept or reject the appeal; and
communicate the decision to the Register Manager.
The Register Manager shall:
update the proposal management record fields proposalStatus and dateAmended;
update the Register item itemStatus; and
provide the results of the decision to the Register Domain Control Body and to the Submitting Organization representative.
The Submitting Organization shall:
make the results of the appeal known within their Submitting Organization Working Group, community or organization.
4.3 Proposal Process — Data Dictionary Register
After ensuring all required items for inclusion in an S-100 based Product Specification have been included in the Concept Register, Product Specification developers can further develop these concepts to align with their Product Specification Application Schema within the Data Dictionary Register. This includes assignment of type and feature/attribute binding of concepts as required within discrete Domains. When used in the Data Dictionary Register, a concept continues to maintain a direct relationship to its “core” item in the Concept Register; such that it is updated automatically when the core concept has been modified. The Data Dictionary Register has a different submission process to the Concept, Portrayal and Metadata Registers; and this is illustrated in Figure 4-2.
4.3.1 Submission Process
Submitting Organization representatives shall:
receive proposals for the registration of items from proposers within their respective Submitting Organization Working Groups, communities or organizations;
ensure that all proposals are logical and complete and are consistent with other features, attributes and enumerated values; and
submit proposals to the appropriate Domain within the Register through the proposal process in the IHO GI Registry interface.
The Register Manager shall ensure the following:
if the proposal is for clarification or retirement of a Register item, forward the proposal to the Register Domain Control Body; or
if the proposal is for registration of a new item or supersession of an existing Register item:
assign an itemIdentifier to the new or superseding item,
set the itemStatus of the item to ‘processing’; and
inform the Register Domain Control Body of the new proposal within five working days.
4.3.2 Approval Process
The Domain Control Body may decide to:
accept the proposal without change;
accept the proposal subject to changes negotiated with the Submitting Organization representative; or
not accept the proposal.
Criteria for not accepting a proposal include:
the specification of the item is incomplete or incomprehensible;
an identical or very similar item already exists in the Register;
the proposed item does not belong to an item class included in the Register;
the proposed item does not fall within the scope of the Register; or
the justification for the proposal is inadequate.
Each Register Domain Control Body member shall inform the Register Manager of their Working Group / organization’s decision, and the rationale for that decision, within 30 days of receipt of the proposal through the approval process in the IHO GI Registry interface. Nil returns will be taken as acceptance of the proposal.
The Register Manager shall:
serve as the point of contact if there is a need for negotiations between the Submitting Organization representative and the Register Domain Control Body regarding any changes required to a proposal that may be specified by the Domain Control Body as a condition of acceptance; and
inform the Submitting Organization representative of the results of processing the proposal.
If the decision of the Register Domain Control Body is positive, the Register Manager shall, in accordance with policies for the Register:
complete the proposal management record with proposalStatus set to ‘accepted’, and dateAccepted to the date of the Domain Control Body’s decision;
make approved changes to the content of the Register item; and
set the Register item itemStatus to ‘valid’, ‘superseded’, ‘modified’ or ‘retired’, as appropriate.
If the decision of the Register Domain Control Body is negative:
update the proposal management record by setting proposalStatus to ‘rejected’, and dateAmended to the date of the Domain Control Body’s decision;
inform the Submitting Organization representative of the 60 working day deadline for appealing the decision of the Domain Control Body; and
make the results of the approval process available to all interested parties.
Submitting Organization representatives shall:
negotiate with the Register 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
make known to the proposer and within their respective Submitting Organization communities or organizations the decisions taken on proposals by the Register Domain Control Body as transmitted to them by the Register Manager.
4.3.3 Withdrawal of Proposals
Submitting Organization representatives may decide to withdraw a proposal, using the withdrawal process in the IHO GI Registry interface, at any time during the approval process.
The Register Manager shall then:
change the proposal management proposalStatus from ‘notYetDetermined’ to ‘withdrawn’;
change the proposal management value for dateAmended to the current date; and
keep track of the proposal and report the withdrawal in the next periodic report.
4.4 Proposal Process — Product Specification Register
Representatives of organizations may submit submissions for the addition of new Product Specifications in the Product Specification 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 IHO GI Registry web interface.
4.4.1 Acceptance Criteria
4.4.1.1 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.
4.4.1.2 Other Product Specifications
Product Specifications that have been developed by other competent organizations may be recorded or referenced in the Register provided that:
they use S-100 as the underlying framework standard (organizations are encouraged to populate Feature Catalogues, either using existing entities registered in the IHO GI Registry or proposing new ones to the Registry where appropriate);
any identification number or the 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
the content description is described in plain language.
4.4.2 Submission Process
The Working Group, community or organization making a submission shall ensure that the new Product Specification:
is complete; and
is made available to the Register Manager.
The Register Manager shall:
receive the submission from the Working Group, community or organization;
review the Product Specification for completeness;
return the submission to the Working Group, community or organization if incomplete; and
update the item management record, with the proposalStatus set to ‘notYetDetermined’.
The Register Manager shall use the following criteria to determine if a submission is complete:
it falls within the scope of the Register; or
a registered item (or similar) to the proposed does not already exist.
4.4.3 Approval Process
The Register Manager shall ensure that all aspects of the submission have been satisfied and all components of the Product Specification have been supplied.
The Register Manager shall:
create a new Register item for the Product Specification; and
inform the Working Group, community or organization that the Product Specification has been included as an item in the Register.
4.5 Proposal Process — Producer Code Register
Representatives of organizations that require a data Producer Code shall submit applications for a Producer Code, via an email to the Register Manager, using a link available in the IHO GI Registry web interface.
The Producer Code Register is used as the source for IHO Publication S-62 — List of IHO Data Producer Codes.
4.5.1 Eligibility Criteria
4.5.1.1 Government Authorities
Data Producer Codes allocated to Governments, authorized Hydrographic Offices or other relevant government institutions will be recorded in the Register. Distinction is made in the Register between IHO Member State authorities and non-IHO Member State authorities.
Data producers allocated with a Government Authority Producer Code are considered to be the producers of “official” ENC datasets.
4.5.1.2 Other Producing Authorities
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.
Data producers allocated with an Other Producing Agency Producer Code are considered to be the producers of “non-official” S-57 datasets.
4.5.2 Submission of Applications
The organization making the application shall ensure that all applications are complete.
The Register Manager shall:
receive applications from applicants;
review applications for suitability and completeness; and
return applications to the applicant if incomplete.
4.5.3 Approval Process
The Register Manager shall ensure that:
a suitable entry does not already exist in the Register, and if not;
allocate a Producer Code and assign it to a category (Member State, Other State or Other); and
inform the applicant within 10 working days.
The Register Manager shall:
serve as the point of contact if there is a need for negotiations with an applicant regarding any changes required to an application.
4.5.4 Appeals
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 applicant shall submit its appeal to the Register Manager.
The Register Manager shall:
forward the appeal to the Executive Control Body or HSSC as appropriate, and
inform the appellant of the decision.