Development of MetaPortal Prototype and Communication ... - CiteSeerX

Development of MetaPortal Prototype and Communication Interface for Czech national environment Bronislava Horáková 1, Jan Růžička 2, Roman Ožana3 1

Institute of geoinformatics, HGF, VSB - TUO, 17. listopadu 15, 708 33, Ostrava - Poruba, Czech Republic [email protected] 2 Institute of geoinformatics, HGF, VSB - TUO, 17. listopadu 15, 708 33, Ostrava - Poruba, Czech Republic [email protected] 3 Institute of geoinformatics, HGF, VSB - TUO, 17. listopadu 15, 708 33, Ostrava - Poruba, Czech Republic [email protected] Abstrakt. Klíčová slova: Abstract. The paper describes experiences with GeoNetwork opensource as a possible tool for building metaportal prototype under conditions of the Czech republic environment. The project is developed under project UNSDI that is focused on building geoinformation infrastructure for UN and cooperating organisations. The main part of the paper is focused on CSW 2.0 implementation in the GeoNetwork opensource tool, because We believe that this specification will be the most suitable communication interface. The paper describes system architecture and functionality. At the end of the paper are summarized results of system testing. Keywords: GeoNetwork, CSW, Catalogue, Metadata, Catalog Services, Web Services, ISO 19115, ISO 19139, Dublin Core, Open source, SDI, Spatial Data Infrastructure, Jeeves, Java, UNSDI, FAO.

1

Project UNSDI

The objective of the United Nations Geographic Working Group (UNGIWG) is to build a United Nations Spatial Data Infrastructure (UNSDI) with the purpose of enhancing geospatial data and information sharing and exchange between UN agencies and programs as well as national and regional SDI´s and to promote and achieve sustainable development and food security. UNSDI is expected to support: • Data access and sharing through a decentralized coordination framework • Interoperability and standardization of tools • Place-based management • Portability

• Build once, use many times • Continuity and sustainability The Czech Republic was adopted as a member this global Initiative. The Czech Coordination Office (CCO) for the United Nations Spatial Data Infrastructure (UNSDI) was established on the basis of a kick-off meeting for Czech participation in the United Nations Geographic Working Group (UNGIWG)-UNSDI initiative on the 18th of May 2006 in Brandys nad Labem. The CCO is supported by the Czech Centrum for Science and Society and its goal is to coordinate Czech activities for the establishment of the UNSDI and coordinate Czech national activities with the UNGIWG Membership, the UN Agencies and programmes, and other international and national bodies. More detailed information about UNGIWG-UNSDI can be found on www.ungiwg.org. The basic technical facility that enables UNSDI building is GeoNetwork Opensource. 1.1

Participation of the Institute of Geoinformatics

Institute of Geoinformatics of VSB-Technical University of Ostrava is one of selected organizations that are taking part in this project. Our Institute participates primarily by development of technical facility that is to improve the accessibility of a wide variety of data, together with the associated information, from multidisciplinary sources, organized and documented in a standard and consistent way. According to this intention we have started GeoNetwork Opensource investigation and examination of International and Open Standards for services and protocols (primarily ISO/TC211, OGC) as initial preparatory phase to research and development communication interface amongst GeoNetwork and other nodes (Clearinghouses, Catalog databases, etc.). We attended a special workshop, organized by FAO in Roma this year, which was focused on GeoNetwork opensource. The investigation and the testing were started in September and the first test results are described in this article.

2 2.1

GeoNetwork opensource Common Specification

GeoNetwork opensource is a catalog application useful to manage spatially referenced resources that has been developed to connect spatial information communities and their data. It offers a modern architecture, which is at the same time powerful and low cost, based on principles of Free and Open Source Software (FOSS) and International and Open Standards for services and protocols (ISO/TC211, OGC). GeoNetwork is a web based Geographic Metadata Catalog System developed by FAO-UN (Food and Agriculture Organization of The United Nations), WFP-UN (World Food Programme) and UNEP (United Nations Environment Programme). The three agencies have combined their research and mapping expertise to develop the

GeoNetwork opensource as a common strategy to effectively share their spatial databases including digital maps, satellite images and related statistics. In 2001 FAO set up FAO-GeoNetwork (www.fao.org/geonetwork) as a facility that provides various services, such as a global library for geospatial data; a metadata catalogue; a system for searching, editing and publishing geospatial information; as well as information on how to integrate geospatial data from various sources on the Internet. The WFP-VAM branch (Vulnerability Analysis & Mapping) joined FAO in the further development of GeoNetwork through formulation of additional requirements and through co-funding. In consequence of this activity was GeoNetwork version 1. Early 2004 the UNEP joined FAO and WFP in the development and subsequently they ended GeoNetwork version 2 (in 2005). The current software (version 2.1) is also under active development of OCHA (United Nations Office for the Coordination of Humanitarian Affairs). Furthermore, WHO, CGIAR and the Global Change Information and Research Centre (GCIRC) of China are working on GeoNetwork opensource implementations as their spatial information management capacity. Other users are UNHCR, CGIAR, ESA, GMFS, FEWSNET, FGDC or individual projects in Spain, France, Czech Republic, UK, Australia, South Africa and others. GeoNetwork: • Improves access to and integrated use of spatial data and information; • Supports decision making; • Promotes multidisciplinary approaches to sustainable development; • Enhances understanding of the benefits of geographic information. GeoNetwork provides four capabilities: • Global library for geospatial data; • Metadata catalog describing geospatial data; • System for searching, editing and publishing geospatial information; • Service that allows integration of data from various sources. Functionality of GeoNetwork: • Searching of spatial data resources; • Finding services related to these resources; • Downloading of spatial data; • Online dynamic viewing through OGC compliant services; • Online Printing; • Feedback mechanism to data owners; • Management module for data and metadata; • User authentication on search (not required); • User authentication on metadata and data management services; • Metadata template system; • Search on remote metadata databases (FAO, WFP, UNEP etc…). 2.2

Technical Specification

The GeoNetwork opensource architecture is largely compatible with the Geospatial Portal Reference Architecture (Figure 1), which is the Open Geospatial Consortium

(OGC) Guide to implement a standardized geospatial portal, and is made available as an opensource project on the SourceForge.net site [4, 5].

Figure nr.1. The Geospatial Portal Reference Architecture © OGC Geospatial Portal Reference Architecture – DRAFT OGC 04-039

The Geospatial Portal Reference Architecture is a major step forward to EGovernment, National Spatial Data Infrastructures, enterprises and Information Communities. It enables geoprocessing interoperability that facilitate to exchange heterogeneous geographic information content and share a wide variety of geospatial services over the WWW. The Geospatial Portal Reference Architecture documents a “core” set of interoperability agreements that provide instructions for bridging the gaps between different organizations and communities that have heretofore shared geospatial information only with great difficulty. The Geospatial Portal Reference Architecture is founded on the tenants of a Service Oriented Architecture (SOA). The Geospatial Portal Reference Architecture specifies four service classes that are needed to procure a comprehensive geospatial portal implementation and it identifies the OpenGIS Interoperability Standards that are applicable to the services. The four service classes are Portal Services, Catalog Service, Portrayal Services and Data Services. GeoNetwork opensource implements both the Portal component and the Catalog database of a Spatial Data Infrastructure (SDI) defined in the OGC Reference Architecture. It provides tools for managing and publishing metadata on spatial data

and related services. GeoNetwork opensource allows a distributed search providing access to a huge volume of metadata that come from different Clearinghouses and also provides a web-based interactive map viewer that allows people to composite maps picking layers from distributed servers on the internet. GeoNetwork opensource, like the OGC Reference Architecture, employs [1]: • Portal Services that provide the access to the geospatial information as well as the management and administration of the portal and users. A set of rules allows Authentication and Access Control that regulate, through controlled privileges, the access to reserved information and services. In addition, the Portal Platform offers an Advanced Metadata Editor Module that is able to create and edit ISO compliant metadata records for geographic data using the Standard ISO 19115. The map viewer, part of the portal services, is provided by InterMap, another joint FAO-WFP opensource project [10]. InterMap is an internet mapping application that allows the user to combine interactive maps from distributed Internet Map Servers in a browser. InterMap supports OpenGIS WMS and ESRI-ArcIMS and can be fully integrated with the GeoNetwork Metadata portal. • Catalog Services that allow the collection, registration and maintenance of descriptive information about the data stored in the database. The Catalog Services implements a Metadata Clearinghouse that includes a facility to retrieve all the information on the spatial data made available by other Clearinghouses. GeoNetwork opensource can access other databases and vice versa, taking into account security settings on metadata and data. • Data Services components that are being implemented by GeoNetwork opensource to complete the OpenGIS Framework of the Reference Architecture. This particular class of services provides access to spatial content in repositories and databases and allows data processing through defined common encoding and interfaces. Furthermore the Data Services can be distributed across the internet thus they don’t need to be resident on the operational portal. • GeoNetwork opensource does not directly provide the Map Portrayal, the fourth component of the OGC Reference Architecture, which makes possible the visualization on the internet of geospatial information. However, several open source projects exist which implements the Map Portrayal component that can be integrated with the GeoNetwork opensource package; for instance Deegree, MapServer and GeoServer. GeoNetwork opensource version 1 has been available with an embedded Deegree server, providing all components of the OGC Reference Architecture as an integrated package. This effort has been improved recently joining the OpenSDI group, which has the purpose of aiding the integration of different OCG Reference Architecture components; the GeoNetwork opensource team is working closely with that group to support seamless integration of GeoNetwork opensource with these and other projects implementing OGC standards. Requirements • Development of XML/XSL based web application • Platform independent • Runs on JDBC compliant databases

• Freely available • Separation of presentation (pages) and business logic (services) • Reusability • Standard technologies • Multiple access modes (HTML, XML) • Multiple data sources • Controlled team working environment Solutions • Standard technologies o Java language o Servlet environment for web services (Tomcat & Jetty) o XML/JDOM data representation o XSL for presentation o JDBC for SQL database access o Multi platform Search engine • Uses Lucene to index metadata • Unified search through stylesheets • Scalable over big metadata sets • Remote search using Z39.50 (GEO profile) and OGC Catalogue Services for the Web Catalog interfaces • Develop a user interface to administer harvesting • Close collaboration with OGC, FGDC, UK (EDINA), JRC, ESA in implementing CSW 2.0 • Provide GeoNetwork opensource as an OGC CSW 2.0 reference implementation • Implement Open Archive Initiative interface (OAI) Open Spatial Data Infrastructure (OpenSDI) • Integrate map server administration & metadata management • Use GeoNetwork to store or provide o Metadata for Service Configuration (WMS, WFS, WCS, SLD etc) o Data, Feature and related resources level metadata • Open Source Geospatial Foundation (OSGEO) can be key here • Provide online spatial data editing • Metadata closely integrated with GeoNetwork opensource • Provide offline spatial data and metadata editing • Synchronize when back online • Provide efficient extraction of data • Support Efficient data transfer protocols What is new in GeoNetwork opensource v2 [24] • Increase in metadata storage capacity; • Support for multiple metadata standards (e.g. ISO19115, FGDC, DC); • Better validation of metadata; • Standalone, desktop version;

• • • •

Full OGC Catalog v2.0 support (in v2.1); ISO 19139 compliant metadata; Metadata synchronization; Community website: o Documentation center:
FAQ, Exercises, Manuals; o Software center; o Mailing lists for Users & Developers. The software is released under the GPL [6] license and can be used and modified free of charge. 2.3

GeoNetwork opensource DVD

In October 2006 an updated GeoNetwork opensource DVD was announced, including the maintenance release GeoNetwork opensource version 2.0.3 and many other Free and Open Source Software for Geographic Information Systems (GeoFOSS). On this DVD can be found all the necessary software to install GeoNetwork opensource and its embedded web map viewer InterMap opensource. User can choose to install GeoNetwork as a stand-alone application on desktop PC or do a more comprehensive installation suitable to run GeoNetwork on a server. Based on these applications can be build a Spatial Data Infrastructure or they can also be used individually. The content the DVD is now directly accessible at the following address: http://tecproda01.fao.org/geofoss_dvd/.

Figure nr. 2. GeoFOSS (Free and Open Source Software for Geographic Information Systems) © Stefano Giaccio, Jeroen Ticheler, FAO, FOSS4G workshop 12 September 2006

3 3.1

Summarized results of GeoNetwork v 2.1.0 alpha testing Functionality

We have tested version 2.1.0 alpha – build from CVS 16.10.2006 - and have found a lot of interesting functions. The system is available via WWW browser for human users and via communication protocols for machine users (e.g. services). Users can play one of five different roles and user can be a member of unbounded number of groups. The roles are: Anonymous, Guest, Editor, Advanced Editor and Administrator. Anonymous does not need to login and can search in metadata, Guest must login and can search in hidden metadata as well, Editor can edit owned metadata, Advanced Editor can edit metadata for the whole group, Administrator can do almost everything. System functions: • Search metadata in local database.

• • • • • • • • • • • • • • • • • • 3.2

Search metadata in connected nodes based on Z39.50 protocol [15]. That functionality should be replaced by harvesting method from CSW 2.0 specification [8]. Show metadata (basic view, advanced view, XML view). Download geodata. Preview data (static, dynamic (via WMS [13])). Insert new metadata. Update existing metadata. Delete metadata. Import metadata from XML [29] file. Do batch import of XML files from local folder. Add (delete) user and group. Set access permissions for users (groups) for some operations such as data download, metadata view, edit, delete. Is accessible via ISO 23950 (Z39.50). Is accessible via CSW 2.0. Download metadata via Harvesting method from CSW 2.0. Show list of last updated metadata. Provide list of last updated metadata according to RSS and GeoRSS. Provide metadata according to internal specification portal, that is use to implement. There is a desktop client for testing communication according to CSW 2.0. Standards

The system is based on a set of standards that are crucial for NGII. The most well known are: • ISO 19115 [12], ISO 19139 are used for geodata description. • Dublin Core (ISO 15836) [14] is used for geodata description. • Z 39.50 (ISO 23950) is used for searching in connected remote catalogues. • CSW 2.0 allows external users to search in catalogue; this standard is described in more detail later. • Web Map Service (ISO 19128) is used for geodata preview; it is implemented in integrated map server InterMap. • HTTP [26] is used for request / response exchange in many interfaces. • SOAP [27] implementation for CSW 2.0 is now under development. Nowadays the pure HTTP protocol is used. • XML is a base for every configuration, metadata storage, and language customization and user environment configuration. • XSL [30] is used for many purposes, begins with user environment and ends with metadata transformation between different standards. • Interface JDBC [25] is used for data access in relational database. MySQL, McKoi, Oracle and PostgreSQL were tested • I18N [28] is used for localisation implementation.

3.3

Technology

The whole system is based on Java language. The system consists of set of Java servlets, which are based on Jeeves technology (described below). A system runs in a Java servlet container. For testing purposes is built in container Jetty and for final run is recommended container Apache Tomcat. Services configuration, templates for metadata and terms for user environment are based on set of XML documents. User environment is a set of templates in XSL. Metadata editing and visualisation is based on XSL as well. “Jeeves stands for Jeeves is an Easy Engine for Very Effective Systems and the name says it all. Using Jeeves it is possible to publish simple systems on the Internet without any Java knowledge and with little effort.” [17] The Jeeves feature list is remarkably short [17]: • Database access: Jeeves provides simple select, insert and update methods that can be used for no-frills database access; • Logging: Basic logging is provided for access and errors; • Session management: Session management, beside what is provided by the servlet engine being used, is provided; • Multilingual support: Through simple URL coding, multiple languages can be supported. Furthermore, Jeeves allows for a default language to be used if not specified by the user browser; • Service chaining: Usually, the purpose of a service is to produce an output page. In some cases, though, a service needs to be called once a prerequisite service has been successfully executed (e.g. an authentication service). Jeeves supports a simple service chaining mechanism; • Commit/rollback management: Jeeves manages commit and rollback automatically. When a service returns normally, a commit is issued to the database session. If an exception is thrown, Jeeves sends a rollback. • • • • • • • •

Library JZKit is used for building Z39.50 portal, server and client. Library Xalan is used for processing XML documents according to XSLT templates. Library Xerces is used for parsing XML documents in SAX style. Library Log4Jruntime is used for runtime logging of java binary repositories. Engine Apache Lucene is a high-performance, full-featured text search engine library. Tool Apache Ant is used for compiling GeoNetwork from sources. Library CQL-java is used for parsing and building queries. There are more technologies that are used in GeoNetwork and comlete list is available after installation of the system.

3.4

Localisation

System localisation is available via editing set of XML documents that are in UNICODE (UTF-8) encoding. We have prepared a first localisation to the Czech language, you can try it at http://gis.vsb.cz:8080/geonetwork2/ Implementation of administrative areas (units) is available via XML, but it was not tested yet. Implementation of national (branch) template was tested, but not in detail. For this task is necessary XML and XSL implementation. Other tests were not provided.

4

CSW Testing

CSW (Catalogue services for Web) is prepared by OGC (Open Geospatial Consortium). Actual version of CSW is 2.0.1. The prior public version of this specification was 1.1.1 (created in year 2002) Catalogue Services version 2.0 supersedes and deprecates version 1.1.1. The Catalogue 2.0 Specification is currently in revision to correct a number of known errors. atalogue services are the key technology for locating; managing and maintaining distributed geo-resources (i.e. geospatial data, applications and services). All relevant documents are downloaded from OGC [18]. 4.1

CSW idea

CSW specification well defines interface and operations of catalogue services, but is not limited to, supports query languages, allows search by terms, allows response/result sets, etc. This point is of major importance with respect to interoperability between different catalogue service instances. CSW specification is in a fact only standard that covers management of metadata [19]. 4.2

Interoperability support

The overall goal of CSW is to improve interoperability between systems. CSW define a minimal set of query-able properties (CSW 2.0 core query-able properties), those properties enable cross-catalogue discovery. The same queries can be executed against any catalogue service without modification [19]. Each catalogue implementation must support predicate language CQL (Common Query Language) and Filter. Responses of catalogues and requests of clients are encoded in XML. Responses have a same profile. Base response profile provides a basic set of information objects that has to be supported by each catalogue instance (OGC Core elements).

4.3

Core queryable properties

Subject, Title, Abstract, Format, Identifier and Type are Dublin Core Metadata Elements (ISO15836: 2003). Another elements are AnyText, Association, CRS (Coordinate Reference System), Envelope and Modified. 4.4

OGC CORE response elements

Following table includes list of OGC Core elements. OGC Core is based on Dublin Core elements profile [18]. Table nr 1. List of OGC Core elements based on Dublin Core elements.

Dublin Core metadata element name

Term used in OGC queryables

dc:title

Title

dc:creator dc:subject

Subject

dct:abstract

Abstract

dc:publisher

dc:contributor

dc:date

Modified

dc:type

Type

dc:format

Format

dc:identifier

Identifier

dc:source

Source

Description (“Resource” means the thing being described in the metadata) A name given to the resource. Also known as “Name”. An entity primarily responsible for making the content of the resource. A topic of the content of the resource. This is a place where a Topic Category or other taxonomy could be applied. An account of the content of the resource. This is also known as the “Abstract” in other aspects of OGC, FGDC, and ISO metadata. An entity responsible for making the resource available. This would equate to the Distributor in ISO and FGDC metadata. An entity responsible for making contributions to the content of the resource. A date of a creation or update event of the metadata resource. The nature or genre of the content of the resource. The physical or digital manifestation of the resource. An unambiguous reference to the resource within a given context. A reference to a resource from which the present resource is derived.

dc:language dc:relation dct:spatial

Relation, Source, Target Envelope, CRS

dc:rights

4.5

A language of the intellectual content of the resource. A reference to a related resource. The spatial extent or scope of the content of the resource. Information about rights held in and over the resource.

CQL predicate language

CQL query (predicate) language must be supported all catalogues. CQL supports Boolean queries, text matching operations, temporal data types, and geospatial operators. The query language syntax is based on the SQL WHERE clause in the SQL SELECT statement. CQL language is extensible, can be extended by adding new predicates, operations and datatypes [18]. 4.6

CQL XML Encoding

XML encoding of CQL language is Filter and is specified in Filter Encoding Implementation Specification, version 1.1.0. Filter is easily parse-able using available XML parsers and is easily translatable into a target predicate language such as a SQL where clause or an Xquery predicate. Filter example: DEPTH 30

Example query select all records with DEPTH attribute less then 30. 4.7

Operations in CSW

Catalogue service is a system that handles the discovery and publishing of metadata entries. Furthermore is able to harvest metadata records from other catalogue services. Application profile is based on OGC Web Services Common Specification. Mandatory operations, which must be supported by all catalogues, are: • OGC_Services.GetCapabilities • CSW Discavery.DiscribeRecord • CSW Discavery.GetRecords • CSW Discavery.GetRecordById Optional operations are: • CSW Discavery.GetDomain

• •

CSW Manage.Harvest CSW Manage.Transaction

Figure nr. 3. Basic schema of CSW operations

4.8

Communication with catalogue

Three basic communication protocols are: • HTTP • CORBA • Z39.50 HTTP/GET with KVP (key/value pair) encoding and SOAP with XML encoding are the mandatory protocol bindings, while HTTP/POST with XML encoding is optional. 4.9

Communication over HTTP protocol

For some operations the POST method is recommended. GetCapabilities and GetTecordById have recommended GET method. Only the GET and POST methods are employed in the HTTP binding. Table nr.2. Operations in CSW and recomanded HTTP methods

3

Request

HTTP method binding(s)

Data encoding(s)3, 4

GetCapabilities DescribeRecord GetDomain

GET (POST) POST (GET) POST (GET)

KVP (XML) XML (KVP) XML (KVP)

XML = application/xml using POST (with a charset parameter if necessary—UTF-8 is strongly recommended) 4 KVP = URL-encoded key/value pairs using GET or application/x- www-form-urlencoded using POST

GetRecords GetRecordById Harvest Transaction

POST (GET) GET (POST) POST POST

XML (KVP) KVP (XML) XML (KVP) XML

Figure nr. 4. Communication schema over HTTP protocol

5 5.1

Discovery operations GetCapabilities operation

The mandatory GetCapabilities operation allows CSW clients to retrieve a service description in a form of metadata from a server. The response to a GetCapabilities request shall be an XML document containing service metadata about the server.

This operation must respond with an XML document, example of this GetCapabilities file is in CSW specification. If the CSW server implements the filter predicate language, then the server must include a Filter_Capabilities section in the service metadata to describe which elements of the predicate language are supported [18]. Mandatory GetCapabilities request parameters are: 5.2

Implementation in GeoNetwork Open Source

XML encoded request send by POST method over HTTP protocol. 2.0.1 application/xml

KVP Encoded request send by GET method over HTTP protocol http://gis.vsb.cz:8080/geonetwork2/srv/cs/csw?request=GetCapabilities&Ac ceptVersions=2.0.1&service=CSW

CSW specification recommended use CSW string in services parameter, but GeoNetwork Open Source allows use URI of namespace (http://www.opengis.net/cat/csw) in this parameter. CSW

Content of element OutputFormat is ignored. Now only application/xml output format is supported. GN accepted CSW version is now only 2.0.1.

5.3

Operation GetRecords

The primary means of resource discovery in the general model are the two operations search and present. In the HTTP protocol binding these are combined in the form of the mandatory GetRecords operation, which does a search and a piggybacked present [18]. Mandatory GetRecords request parameters are: • Request (default value = GetRecords) • Service (default value = CSW) • Version (default value is 2.0.1) Main optional GetRecords request parameters are: • resultType • outputFormat • ElementName • sortBy • responseHandler • constrain (and ConstraintLanguage) The resultType parameter may have the value “hits”, “results”, or “validate”; the value determines whether the catalogue service returns just a summary of the result set, includes one or more records from the result set, or validates the request message and processes it asynchronously. GeoNetwork support all tree cases [18]. GeoNetwork supports CQL and Filter constrain languages. 5.4

Implementation in GeoNetwork Open Source

GeoNetwork encode metadata in two profiles OGC CORE and ISO19139. OGC CORE profile is mandatory profile. The request was send only by POST method over HTTP protocol during the testing [18]. XML request example, selected all records which AnyText attribute contains string map. http://www.nabito.net/diplomka/handler.php full full AnyText *map*

• • • • • • •

5.5

outputFormat is only application/xml ResponseHandler contains network location to which the response will be forwarded when operation has been completed, for asynchronour requests. GeoNetwork currently support only synchronous requests. SortBy element is supported in GN Both constrain languages (CQL and Filter 1.1.0) are supported Brief, Full and Summary response profile are supported (parameter ElementName) ResultType parameter (hits, results and validate) is supported Main response metadata profile OGC Core and ISO19139 are supported (parameter outputSchema) GetDomain operation

The optional GetDomain operation is used to obtain runtime information about the range of values of a metadata record element or request parameter. For example, a property or request parameter defined as a 16bit positive integer in a database may have a value space of 65535 distinct integers but the actual number of distinct values existing in the database may be much smaller [18].

This type of runtime information about the range of values of a property or request parameter is useful for generating user interfaces with meaningful pick lists or for generating query predicates that have a higher chance of actually identifying a result set [18]. 5.6

Implementation in GeoNetwork Open Source

GeoNetwork currently does not support this optional operation. 5.7

DescribeRecords operation

The mandatory DescribeRecord operation allows a client to discover elements of the information model supported by the target catalogue service. The operation allows full or partial description of the information [18]. Mandatory DescribeRecords request parameters are: • Request (default value = DescribeRecords) • Service (default value = CSW) • Version (default value = 2.0.1) • Namespace The DescribeRecord operation depends on namespace declarations in order to know exactly which types to describe. The NAMESPACE parameter is a list of namespace declarations of the form alias:namespace. 5.8

Implementation in GeoNetwork

GeoNetwork supports this operation. 5.9

GetRecordById operation

The mandatory GetRecordById request retrieves the default representation of catalogue records using their identifier. The GetRecordById operation is an implementation of the Present operation from the general model. This operation presumes that a previous query has been performed in order to obtain the identifiers that may be used with this operation. For example, records returned by a GetRecords operation may contain references to other records in the catalogue that may be retrieved using the GetRecordById operation. This operation is also a subset of the GetRecords operation, and is included as a convenient short form for retrieving and linking to records in a catalogue [18].

5.10 Implementation in GeoNetwork GeoNetwork currently supports this operation. Response profile is only OGC CORE. For our testing purposes we have changed source code of GeoNetwork Open Source in a manner that when records are stored according to ISO 19139, they are returned in their primary form instead of OGC CORE.

6

Edit operations in catalogue

The general model defines two operations in the Manager class that may be used to create or update records in the catalogue. They are the transaction operation and the harvestRecords operation. 6.1

Operation Transaction

The optional Transaction operation defines an interface for creating, modifying and deleting catalogue records. The specific payload being manipulated must be defined in a profile. For transaction operation request isn’t KVP encoding [18]. 6.2

Implementation in GeoNetwork

GeoNetwork currently does not support this optional operation. 6.3

Operation Harvest

The transaction operation may be used to "push" data into the catalogue. The first mode of operation is a synchronous mode in which the CSW receives a Harvest request from the client, processes it immediately, and sends the results to the client while the client waits. The second mode of operation is asynchronous in that the server receives a Harvest request from the client, and sends the client an immediate acknowledgement that the request has been successfully received. This operation may be performed only once or periodically depending on how the client invokes the operation [18]. 6.4

Implementation in GeoNetwork

GeoNetwork currently does not support this optional operation.

7

Conclusion

GeoNetwork opensource looks promising tool for building metadata catalogues. The main reason is progress in implementation of CSW standard. We believe in dynamic or harvesting communication between metadata sources in the Czech Republic based on CSW standard. Other benefit is open architecture of the system. System can be changed easily by XML and XSL documents. Our goal for the close future is establishing connection to other catalogues in the Czech republic for harvesting of metadata. After that we will prepare scenarios for harvesting management. In the last stage we will open metadata portal based on harvested metadata from many Czech sources. GeoNetwork opensource can be useful in building other metadata portals to be closer to users. In this stage of the project our team should play role of experts that can help with building national metadata portal. Our goal is to help in building geoinformation infrastructure for the Czech Republic.

References 1. Apache Foundation. Lucene. 2006. Available at: 2. CGIAR-CSI (Consultative Group for International Agriculture Research Consortium for Spatial Information). 2006. Available at: 3. FAO-UN. FAO-UN. 2006. Available at: 4. FAO-UN. GeoNetwork OpenSource. 2006. Available at: 5. GeoNetwork Opensource. 2006. Available at: 6. GNU General Public License. 2006. Available at: 7. Hamish, T. Z39.50 Java API. 2006. Available at: 8. ICIMOD-MENRIS (The International Centre for Integrated Mountain Development-Mountain Environment and Natural Resources´ Information Systems). 2006. Available at: 9. ICRISAT (International Crops Research Institute for The Semi-Arid Tropics). 2006. Available at: 10. Indexdata. ZING. 2006. Available at: 11. InterMap. 2006. Available at: 12. ISO/TC 211. ISO 19115. Secretariat, Geneva, Switzerland. 13. ISO/TC 211. ISO/DIS 19128. ISO/TC 211 Secretariat, Geneva, Switzerland, 2004, 83 s. Available at: 14. ISO/TC 46. ISO 15836. Secretariat, Geneva, Switzerland. 2003. Available at: 15. ISO/TC 46. ISO 23950. Secretariat, Geneva, Switzerland. 16. Knowledge Integration Ltd, JZKit. 2006. Available at: 17. Marsella, M. Jeeves Developer's Manual. Rel 1.0. 2005. 18. OGC. Catalogue Services. Catalogue Services Specification. 2005. Available at: 19. OGC. Catalogue Services. ISO19115/ISO19119 Application Profile for CSW. 2005. Available at: 20. OGC. Catalogue Services. 2005. Available at:

21. OGC. The OpenGIS Service Architecture. 2001. Available at: 22. SADC (Southern African Development Community). 2006. Available at: 23. SourceForge.net. 2006. Available at: 24. Spatial Data Management. GeoNetwork opensource: Geographic data sharing for everyone. FOSS4G workshop-Session 6-Slot 1. September 12, 2006. 25. SUN. JDBC. 2005. Available at: 26. W3C. HTTP. 1999. Available at: 27. W3C. SOAP. 2005. Available at: 28. W3C. W3C Internationalization (I18N) Activity. 2005. Available at: 29. W3C. XML. 2005. Available at: 30. W3C. XSL. 2005. Available at: 31. WFP, VAM SIE (Spatial Information Environment). 2006. Available at: 32. WFP-UN. WFP-UN. 2006. Available at: 33. World Health Organization. 2006. Available at: