ebXML RegRep SWG
ebXML RegRep SWG
Purpose of this Standards Working Group
The purpose of the OGC ebXML RegRep SWG is to develop an OGC standard defining an extension to OASIS ebXML RegRep supporting registration, management and retrieval of geospatial and related non-geospatial information items based on well-defined registration processes, such as defined in, but not restricted to ISO 19135.
In order to be able to broaden the usage of geodata by bringing its metadata into non-geo communities, the mission of this SWG is to ensure interoperability between geospatial and non-geospatial registries,. To achieve this, geo-specific registry services shall provide the same service interface and use the same meta-model as non-geo-specific registry services. For this reason, the SWG will geo-enable the existing registry service specification ebXML RepRep instead of developing an OGC specific service specification. Experiences made when geo-enabling the existing standard will be fed back to the OASIS.
Scope of Work
The overall justification for creating an OGC registry service standard which is interoperable with non-geospatial registries is the integration of SDIs into general IT infrastructures with the overall goal to broaden and ease the usage of the geo data in a variety of contexts. In order to reach this goal, we need to support a workflow where geospatial and non-geospatial data can be searched within one single application. As we will not be able to convince other communities like the health care, the financial or the intelligence community to implement geo specific registry services and clients, it is necessary for geospatial community to geo-enable existing registry services.
A user will then be able to search for any type of resource by means of the elements of the core service information model provided in a non-geospatial search application. In case the user identifies something of interest, he is also shown a link to a dedicated search application, providing resource specific search parameters and operators. In case of geo data this could be a geo portal.
The OGC registry service standard shall support the registration and management of information items according to specific, well-defined registration processes, in order to assure the integrity of the content of the registry and the repository. An example of such a registration process is specified in ISO 19135. The OGC registry service shall be able to act as implementation standard for this abstract standard and fully support it. At the same time the OGC registry service shall not be limited to this specific registration process but also support other registration processes, e.g. based on ISO 11179-6. For this reason, the registry service shall support the establishment of registers by means of processes described in a standardized process description language such as BPEL.
The following requirements shall be supported by the OGC registry specification:
The registry service information model shall be a geo-enabled extension of OASIS ebRIM.
The registry service interface shall be shall be a geo-enabled extension of OASIS ebRS.
The registry service shall support the registration, management and retrieval of geospatial and non-geospatial information items.
The registry service shall support a spatial query syntax.
The registry service shall insure the integrity of the content of the registry and the repository.
The registry service shall support pluggable authentication services.
The registry service shall support the assignment of roles to users.
The registry service shall support authorization based on user roles.
The registry service shall support registration processes encoded in standardized process description languages, e.g. BPEL, by notifying user groups and assigning values to data elements in case of certain events.
The registry service interface shall support ISO 19135 compliant registers and registration processes, if these are defined in the process description instance.
The registry service shall support the validation of different types of repository content based on XML schemas.
The registry service shall support versioning of registered items.
The registry service shall support audit trail.
The registry service shall support incremental updates of remote registries by means of subscription.
The registry service shall support the classification of registered items by means of extensible classification schemas.
The registry service shall support the establishment of associations between registered artifacts.
The registry service shall provide functionality to prohibit the establishment of certain types of association between certain types of registered artifacts.
The registry service should support a semantic search capability based on an ontology model.
OGC Catalogue Services provide similar capabilities, but are restricted to the geo community and hence are not interoperable with non-geospatial registries. CSW-ISO can be used to manage ISO 19115 and ISO 19119 compliant metadata. Although this is the state-of-the-art approach for discovering geospatial resources, such as geospatial datasets, dataset series and services, it does not provide all information elements needed to discover the resources, e.g. if users cannot include elements from a feature catalogue and a feature and data dictionaries during the search use case, it is not possible to find out the actual structure and semantics of the features and their attributes, especially when codes are used. To overcome this problem, it would be necessary to define additional service interfaces or provide a CSW-ebRIM supporting the management of these additional information items. Although CSW-ebRIM provides good capabilities when it comes to the management of different types of geospatial metadata, it does neither support interoperability with non-geospatial registries, nor registration processes similar to ISO 19135, audit trail and versioning of registered items. OASIS ebXML RegRep already supports most of the required functionality and since it has initially been developed outside the geospatial community and is already implemented in several other communities, it provides a much better starting point for further development than the OGC Catalogue standard.
Several requirements listed above are not specific to the geo community, but are general IT requirements. The SWG will not specify such functionality, but refer to existing standards wherever possible. These requirements are listed as well, because they should provide the basis for choosing the version of ebXML serving as the base standard. If any general IT functionality has to be specified, because the base standard or other existing IT standards do not yet provide it, it shall be brought back to OASIS or the responsible standardization organization.
Although the OGC extension of ebXML RegRep will be fully dependent on the OASIS ebXML specification, it should become an OGC standard, in order to be able keep the geo-specific extension aligned with upcoming versions of OASIS ebXML RegRep. Providing the extension as a standard instead of a best practice document goes also hand in hand with the description of OGC given in a number of OGC documents, such as press releases, namely that the "OpenGIS® Standards support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT", since ebXML is mainstream IT. This approach also allows the OGC extension of ebXML RegRep to serve as baseline for Registry Services as defined in the OGC Reference Model (OGC 03-040), where at the moment no baseline is defined. An update of the Abstract Specification will be needed, because the notion of registry services is not yet defined there, although such services are already mentioned in Topic 12: The OpenGIS Service Architecture.
What is out of scope?
Only those change requests and comments submitted through the formal process as identified in the Policy and Procedures will be addressed. Any items suggested through emails, vocal discussions, etc will be outside of the scope of this SWG until formally submitted.
The registry service specification will not directly support content or domain specific extensions such as portrayal rules and symbols, feature and data dictionaries, features, coverages, observations etc. Such extensions are expected to be defined by more specialized extension packages.
Specific Contribution of Existing Work as a Starting Point
The OASIS ebXML RegRep specification will serve as the basis for the geo specific extension. The version of ebXML RegRep to be used will be determined as one of the first actions of the SWG, based on the requirements listed above as well as the status of the latest version of ebXML.
The OGC CSW-ebRIM Registry Service - Part 2: Basic extension package (07-144r2) will serve as a basis for the registry service information model and only be extended where the requirements presuppose it.
The DGIWG will provide the description of the ISO 19135 registration process as well as a DGIWG specific extension to ISO 19135, both encoded in BPEL, as examples for well-defined registration processes.
How is it to be Determined when the Work of the SWG has been Completed?
The ebXML RegRep SWG members have voted during the TC in Athens that the SWG will be permanent.
Description of deliverables
The deliverable of the ebXML RegRep SWG is an OGC specification defining a geo-extension for ebXML RegRep supporting the requirements and use cases mentioned above.
The SWG will start its work in a face-to-face meeting held on 2 Dec 2008 in Valencia in the context of the OGC TP meeting. Thereafter teleconferences will be held every second week and physical meetings during the OGC meetings. The target date for release of the candidate standard for public review is 2 March 2009. The anticipated date for consolidation of comments is 2 March 2009. The editing of the document based on the comments is expected to be done until 10 August 2009 and the anticipated date for making a recommendation to the Membership is the OGC meeting in September 2009.
The above schedule is meant to serve as a guideline to the SWG in order to determine completion milestones. However, based on the actual Change Requests, completion dates may be adjusted to accommodate critical updates to the documents. Although all change requests will be addressed, some may be postponed due to the need to more quickly produce a document containing higher priority requests.
IPR Policy for this SWG
Those involved in the design, development, implementation, or use of elements listed above in "Scope of the Work". This includes search and catalogue service providers, prospective users of search and catalogue services, information architects and bibliographic, metadata, and content provider, as well as organizations interested in registries and authoritative catalogues.
Other informative information about the work of this SWG
a. Similar or applicable standards work (OGC and elsewhere).
The following standards and projects may be relevant to the SWG's planned work, although none currently provide the functionality anticipated by this committee's deliverables:
The OASIS ebXML RegRep provides similar functionally, but since it is not yet geo-enabled, it will serve as base specification for the proposed geo-enabled OGC Registry Service Specification.
The OGC Catalogue Service Specification and its profiles provide similar functionality, but since none of these specifications supports all requirements and since it is not interoperable with non-geospatial registries, they are not usable in the context of integrating the SDI into general data infrastructures.
The SWG intends to seek and if possible maintain liaison with each of the working groups maintaining the above works.
b. Details of the first meeting
The first meeting of the ebXML RegRep SWG will be held as face-to-face meeting in the context of the OGC TP meeting in Valencia on 2 December 2008. Teleconference facilitates will be provided and call-in information will be provided to the SWG's e-mail list and on the portal calendar in advance of the meeting.
c. Projected on-going meeting schedule
The work of the SWG will be carried out primarily by email and conference calls, possibly every two weeks, with face-to-face meetings perhaps at each of the OGC TC meetings.
d. Supporters of the Proposal
The following people support this proposal and are committed to the Charter and projected meeting schedule.
Panagiotis A. Vrentanos
Lydia Gietler, KMS