INSPIRE Registry - Architecture

Transcription

1 EUROPEAN COMMISSION JOINT RESEARCH CENTRE Institute for Environment and Sustainability Spatial Data Infrastructures Unit INSPIRE Registry Architecture Title Creator INSPIRE Registry - Architecture Angelo Quaglia Revision date 20/07/2010 Subject (keyword) Status Publisher Description Contributor Rights Language INSPIRE Registry, feature concept dictionary, glossary, architecture draft European Commission, JRC-Institute for Environment and Sustainability-SDI Unit, Ispra This document is aimed at explaining the implementation choices made for the development of the INSPIRE Registry. Angelo Quaglia, Ioannis Kanellopoulos Restricted EN

2 Version history: Version Date Modified by Comments number A.Q. First Draft A.Q. Incorporated comments from IK. Added paragraphs about Definition source and description source, Placeholders. Modified deployment diagram /04/10 IK Various edits /07/10 AQ, IK General Edits

3 Table of contents 1 Purpose of this document Introduction Requirements Need for registries and registers Register Items Roles in the management of a registry and its registers Registry Manager (ISO 19135) Register Owner (ISO 19135) Register Manager (ISO 19135) Submitting Organization (ISO 19135) Control Body (ISO 19135) Register User (ISO 19135) INSPIRE Registry Data upload Audit information Service interface ISO model and the repository structure Multilingualism Architecture Repository Structure INSPIRE Registry users, user types and roles The register manager role Named users Named users and associated roles INSPIRE registry system components Other aspects Upload of the initial content of the registers from external files Implementation Non implemented ISO features Features implemented differently to ISO Labels (Clarification -> Modification) The association Specification source is not used Extensions to ISO Multiple addition proposals for the same item name and item class Placeholders Definition source and description source Technology Database tier Web tier Web application User authentication Deployment diagram Sample Screenshots Home page Initial page of the Feature Concept Dictionary register Register items page Register Item detail page Import of proposal from an external file... 20

4 9 Bibliography... 21

5 1 Purpose of this document This document is aimed at explaining the implementation choices made for the development of the INSPIRE Registry. 2 Introduction According to ISO a register is set of files containing identifiers assigned to items with descriptions of the associated items, while a registry is an information system on which a register is maintained. Although a registry was originally the place where information was collected (in registers), the word registry has also come to mean the collection itself. Alternative definitions from the Internet: A register is a formal or official recording of items, names, or actions ( Register: a written record containing regular entries of items or details ( Registry: a place where a register is kept; an office of registration ( A number of resources describing the data, used for the description of the data with metadata or simply provide information on INSPIRE (e.g. glossary, feature catalogues, code lists etc) need to be maintained properly and be made available online in order to allow for a correct processing and interpretation of the data. [These resources are maintained in ISO conformant registers and have to have a clear and well-defined governance model]. The register contents are made available in form of a registry. All registers keep track of changes so that information created in the past can still be interpreted completely and correctly; i.e. superseded or retired register items will remain in the register. A key characteristic of a register is that every item in the register is associated with a unique, unambiguous and permanent identifier. The INSPIRE Data Specifications DT has identified at least the following resources that shall be maintained in registers: Feature concept dictionary: Dictionary establishing a set of feature-related concepts that may be used to describe geographic information. A common feature concept dictionary will be maintained for all INSPIRE application schemas and feature catalogues. Feature catalogue: Catalogue containing definitions and descriptions of the spatial object types, their attributes and associated components occurring in one or more data sets, together with any operations that may be applied. Application schema: Conceptual schema for data required by one or more applications. Part of a data specification and specified in UML. The Generic Conceptual Model and all INSPIRE application schemas are maintained in a consolidated UML model. Codelist: Dictionary describing the attribute value domains for selected property types in a feature catalogue / application schema. The value domain is not fixed in the feature catalogue / application schema, but is managed

6 separately. I.e. this establishes an extendable controlled vocabulary outside of the data specification itself. Coordinate reference systems and operations: Dictionary of coordinate reference systems, datums, coordinate systems and coordinate operations which are used in data sets. Units of measurements: Dictionary of units of measurement, which are used in data sets. Spatial object identifier namespaces: A mechanism is required to guarantee uniqueness of object identifiers across various content providers. Identifier namespaces need to be managed. INSPIRE Glossary: Register of general terms and definitions used in INSPIRE data specifications In addition to the above other registers may include: XMI files Styled layer descriptors INSPIRE Services: Providing the ability to register, discover, and manage an increasing number of INSPIRE services. The INSPIRE geoportal clients may consult the registry to obtain the necessary information to bind to each of the registered services. code lists and the lists for keywords proposed in the Metadata regulation. The following architectural aspects need to be taken into account. Security, Distribution, replication and synchronization of registries Multilingualism Interface (e.g. OGC CSW, ebrim, ISO 19135, UDDI,..) Consider SOAP & REST Current implementations 1 Glossary (req. from DT DS) Feature concept dictionary 3 Requirements This chapter summarizes the requirements for the INSPIRE Registry application. ISO is the standard chosen for the management of the information contained in the INSPIRE Registers. ISO gives the following definitions for Register and Registry: A register is a set of files containing identifiers assigned to items with descriptions of the associated items. A registry is the information system on which a register is maintained. 3.1 Need for registries and registers Catalogue services already offer the functionality to store and serve metadata about resources. 1

7 However, the current catalogue specifications do not define formal procedures for the modification of the stored information. The user has no means to ascertain, for example, when and by whom some information items have been removed from the catalogue. In addition, INSPIRE needs information other than metadata on resources to be made accessible to the INSPIRE Community for the proper operation of the infrastructure, like for example a glossary of terms Register Items Each register contains items of geographic information and geographic information services. Items are added through approval, by the Control Body, of addition proposals put forward by the Submitting Organizations of the register. ISO specifies a common structure for register items. Every item must have the following mandatory attributes: an identifier a name a definition an item class a status Other attributes, like description, are specified but are optional. Other attributes, like date of acceptance, are conditionally required. The item identifier is a positive integer that uniquely identifies the item in the containing register. The item class identifies a class of geographic information items specified in a technical standard. In the implementation described hereafter it also defines any additional attribute required for describing the items of that class. The item status (see section below) clearly identifies whether the item is valid at the time it is queried: valid means that it can be used in the production of new artefacts, i.e. datasets. The content of a register can change over time since there might be the need to: Introduce new items Retire existing items Replace (supersede) existing items with other items Clarify an existing item to correct the phrasing without changing its semantics The following paragraph gives more details about an item status Item status At any moment in its life the status of an item must be one of the following: Not valid Valid Superseded Retired As depicted in the diagram below, an item starts in the Not Valid status. This is when a Submitting Organization creates a proposal for a new item.

8 Figure 1 - Item Status transitions The item moves to the Valid status when its addition proposal is approved by the Control Body of the register. Note that an item might never acquire the Valid status either because the addition proposal is rejected by the Control Body or because the Submitting Organization withdraws the proposal. The item stays in the Valid status until if ever it is retired or superseded. Amendments ISO refers to retirements and supersessions as amendments. Once in status Retired or Superseded the item status cannot change anymore. Even though this is not stated explicitly in ISO 19135, it derives from the fact that amendment proposals, once approved, are permanent and that there cannot be more than one valid item in a register having the same name and the same item class. It is possible to reuse the same item name for the same item class but in this case a new item is created and assigned a different item identifier. 3.2 Roles in the management of a registry and its registers ISO specifies the following roles involved in the management and use of a registry and the registers it contains. The definitions are mainly taken from ISO Registry Manager (ISO 19135) The registry manager is the entity that maintains the registry service operational Register Owner (ISO 19135) The register owner is an organization that establishes a register and is responsible for the content of the register in terms of intellectual property, and management. The register owner can delegate the management of the register to a register manager.

9 3.2.3 Register Manager (ISO 19135) The register manager is responsible for maintaining the register. The register owner, if unable to play this role, can appoint a different organization Submitting Organization (ISO 19135) An organization authorized by the register owner to propose changes to the content of a register Control Body (ISO 19135) The control body of a register is a group of technical experts that makes decisions regarding the content of the register Register User (ISO 19135) A register user accesses a registry in order to use one or more of the registers held in that register. 3.3 INSPIRE Registry The INSPIRE Registry in this initial phase contains two registers: the INSPIRE Glossary and the INSPIRE Feature Concept Dictionary. This information comprises, for example, the definition of terms used in official documents (glossary), UML application schemata definitions and descriptions (Feature Concept Dictionary) and code lists. Currently the INSPIRE registry contains the Glossary and Feature Concept Dictionary registers which are part of the ongoing process of the INSPIRE Implementing Rules development and built upon the data specification development framework requirements and recommendations. The main goals of the current registers are: 1. To start building the INSPIRE Glossary and the INSPIRE Feature Concept Dictionary with the currently available information; 2. To allow their immediate use in the INSPIRE Implementing Rules and data specifications development. The INSPIRE registry is available for public view. Only valid, superseded and retired items are available for public view. Registered users however, involved in the INSPIRE Implementing Rules development, have access to additional functionality as well as to proposed and unaccepted terms. Requirements for other registers have not yet been clearly defined. Code lists and service descriptors are potential candidates. 3.4 Data upload The system shall allow loading of initial data from Microsoft Excel files. 3.5 Audit information The system shall keep track of when and by whom records are created or updated. Note that this requirement is not completely met by ISO specification. ISO does not mandate audit information at the system user level. 3.6 Service interface The html graphical user interface is required. The requirement for a service interface has not yet been clearly defined.

10 3.7 ISO model and the repository structure ISO mandates a number of attributes for each item stored in a register: identifier, definition, description, item class, etc. These attributes might have a simple domain, like character string for definition and description, or a complex one. An example of the latter is the item class. At some point the INSPIRE Registry might need to act also as a repository for artefacts (e.g. metadata documents, WSDL, UML files in XMI format, etc.). The need for hierarchical registers has currently not arisen. 3.8 Multilingualism Multilingualism shall be supported. Only English is currently supported. 4 Architecture This chapter contains a description of the design of a system that addresses the aforementioned requirements. 4.1 Repository Structure ISO states that the UML model described there is not intended to be implemented in software and data, but as a set of organizations and the interactions between them. The proposed model for the registry (Figure 2) is a tree structure (Figure 3) where the registry is the top node registers the children nodes of the registry and register items the children nodes of each register. Figure 2: Registry model The registry is the top-level node. Citations and Item classes are shared among the different registers.

11 Figure 3 - Tree structure of the registry repository 4.2 INSPIRE Registry users, user types and roles ISO defines only one type of user: the register user. The register user uses the register items. To use an item means to access its information through the registry. In this document the term user is used to identify any user of the system and not just a register user. In order to operate the registry, other user types need to be introduced. Based on these user types authorization policies are implemented and enforced. The policies identify which operations a user is allowed to perform. The implemented user types map to the ISO roles, with some differences. Figure 4 illustrates the roles needed to operate the registry and the registers The register manager role The user type with the most notable differences with respect to ISO is the one corresponding to the role of register manager. The register manager is the one in charge of applying the modifications to the register items according to the proposals put forward by the Submitting Organizations and approved by the Control Body. However, in order to automate tasks wherever possible, the system performs some of the actions that pertain to the register manager responsibilities. It is not possible for the register manager to perform the same operations manually. For example, when an addition proposal is accepted by the Control Body, the system: Changes the item status to Valid Stamps the current date into the dateaccepted attribute of the item Changes the proposal decision status to final and disposition to accepted Stamps the current date into the datedisposed attribute of the proposal As already stated, these actions are performed when an addition proposal is approved. Addition proposals can be approved by users who can act as the Control Body of the register. Note that these actions are performed even though the user cannot act as the Registry Manager. This is compliant with ISO which states

12 that the register manager shall perform the tasks listed above on approval of an addition proposal. The system also checks that proposals are complete and consistent with the current status of the register. Figure 4 - Use case diagram for user roles Named users In order to record audit information, named users are supported. Named users must login to the system in order to operate. They are intended to carry the details of a single person; however, nothing prevents the registry manager from creating shared users to be used by a team. In this case, of course, the audit information cannot serve the purpose of identifying a physical user Named users and associated roles Each user must be able to cover zero or more roles, i.e. must be able to impersonate, for example, the register manager and/or the control body.

13 A role might or might not be delegated (e.g.: the register manager exists only if appointed by the register owner). In order to satisfy the requirements the following approach has been chosen: Each ISO role, e.g. register manager, is associated with one organization, i.e. that organization is authorized to perform the operations related to that role. Specific roles (e.g. the Submitting Organization role and the Control Body role) can be associated with more than one organization, i.e. any user who can act on behalf of the specified organizations is authorized to perform the operations related to the roles. Each named user can have zero or more organizations associated to it. It means that the user can act on behalf of those organizations and can therefore perform the operations related to the corresponding roles. 5 INSPIRE registry system components The system comprises the following components: - A JSR-170 compliant repository, where the data is kept. - A Web Application that presents to the user a graphical interface to operate the register. - One or more modules that implement a service interface 6 Other aspects Upload of the initial content of the registers from external files The Registry Manager can import item proposals into any register by uploading files in Microsoft Excel format.

14 7 Implementation In this chapter the implementation choices are explained. 7.1 Non implemented ISO features The following features described in ISO have not been implemented: Hierarchical registers: No need has arisen for this feature from the requirements. Appeal: Appeal of a decision of the Control Body is not included in the requirements and has not been implemented. The decision status of a proposal goes immediately from pending to final 7.2 Features implemented differently to ISO Labels (Clarification -> Modification) The label associated to the operation called Clarification in ISO (i.e. syntactical changes to the definition and description of an item without any semantic impact), has been renamed to Modification The association Specification source is not used. Instead, definition Source and description Source are implemented (see section Extensions to ISO ). 7.3 Extensions to ISO The features described in this paragraph have been implemented but are not present in ISO They address specific needs that have arisen in INSPIRE Multiple addition proposals for the same item name and item class ISO does not clearly specify how multiple addition proposals for the same item name and same item class must be handled, even though the model allows them. The implementation described here allows creating multiple addition proposals for the same item name and item class, if the item status is not valid. The Control Body of the register sees the list of the proposals and must reject all proposals except the accepted one. If the item status is valid no addition proposal can be created. If the item status is retired or superseded and an addition proposal is submitted for the same item name and item class, a new item is created, i.e. a new item identifier is generated Placeholders The Thematic Working Groups put forward the need that an item name (inside an item class) might need to be reserved in a register even though a complete definition and description are not yet immediately available. The item must stay as not valid until a complete addition proposal is available. In order to address this need, the concept of Placeholder has been introduced, which is not described in ISO but at the same time is not in contrast with it. An addition proposal can be flagged as placeholder. An addition proposal flagged as placeholder cannot be approved. Hence, an item that has only one addition proposal and this proposal is a placeholder will never become valid.

15 For that item to become valid, a new addition proposal, not flagged as placeholder, must be submitted. The Control Body has to reject the placeholder addition proposal before being able to approve the new proposal and make the item valid Definition source and description source ISO defines an optional association Source that links a register item to a reference, i.e. a technical document from which the specification of an item has been taken. In INSPIRE there is the need to document separately the sources for the item definition and the item description. Hence, the optional association described in ISO is never used. Rather, two new optional associations have been introduced ( DefinitionSource and DescriptionSource in Figure 5 Additional associations). 7.4 Technology Figure 5 Additional associations Database tier The chosen back end is a content repository. A content repository is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more. Typical applications that use content repositories include content management, document management, and records management systems.

16 Apache Jackrabbit version is the reference implementation of the Content Repository for Java Technology API (JCR) version 1.0 which was specified by the Java Specification Request 170 (JSR 170). JCR Version 2.0 (JSR 283: Content Repository for Java Technology API Version 2.0) has been approved but no implementation exists, yet. Apache Jackrabbit: Supports versioning and subscription to events related to the modification of the information nodes. Stores information in the file system or in a database according to a configuration parameter. Java DB, Postgres, MySQL and Oracle are supported. Supports clustering. Is provided under the Apache 2.0 license Data model Apache Jackrabbit stores information in nodes. Nodes have a primary type which defines what information can be stored in them. Node types are hierarchical and support multiple-inheritance Web tier Technology The chosen technology is Sun Java J2EE 1.4 (Web Tier). The web tier is implemented using the Sun JDK version Framework The chosen web framework is Apache Struts version (with Tiles). The Struts Framework is provided under the Apache 2.0 license JSP Tag library In order to avoid direct html tagging, the library Struts-Layout 1.3 has been employed. Struts-Layout is NOT an Apache project but it is provided under the Apache 2.0 license. 7.5 Web application User authentication It is recommended that the registry be operated through https since there is currently no obfuscation of the password entered in the web forms Integration with Apache and HTTP Basic Authentication If HTTP Basic Authentication is setup for the location at which the Registry Application is served, the registry checks whether the authenticated user name exists also as a registry user. In this case the same user is considered authenticated for the registry, too. Also in this case https is recommended. 2 Apache Jackrabbit Project home page

17 7.6 Deployment diagram

18 8 Sample Screenshots 8.1 Home page 8.2 Initial page of the Feature Concept Dictionary register

19 8.3 Register items page

20 8.3.1 Register Item detail page 8.4 Import of proposal from an external file

21 9 Bibliography 1. AdV Registry Prototyp - Abschlussbericht zur Veröffentlichung, Clemens Portele (portele@interactive-instruments.de), Jens Fitzke (fitzke@lat-lon.de), ISO 19135: Geographic information Procedures for item registration 3. Apache Jackrabbit Project home page,