1. XML file from the filesystem on your machine. 2. MEF file from the filesystem on your machine 3. Copy/Paste XML
In order to use this facility, you have to be logged in as an editor. After the login step, go to the administration page and select the Metadata insert link.
Clicking the link will open the metadata import page. You will then have to specify a set of parameters. The following screenshot shows the parameters for importing an XML file.
We’ll describe the options you see on this page because they are common ways you can import metadata records in this interface.
• File Type- First option is to choose the type of metadata record you are loading. The two choices are:
• Metadata- use when loading a normal metadata record
• Template- use when loading a metadata record that will be used as a template to build new records in the editor.
GeoNetwork User Manual, Release 2.10.4-0
Figure 4.5:The XML file import options
• Import Action- This option group determines how to handle potential clashes between the UUID of the metadata record you are loading and the UUIDs of metadata records already present in the catalog. There are three actions and you can select one:
• No action on import - the UUID of the metadata record you are loading is left unchanged. If a metadata record with the same UUID is already present in the catalog, you will receive an error message.
• Overwrite metadata with same UUID- any existing metadata record in the catalog with the same UUID as the record you are loading will be replaced with the metadata record you are loading. • Generate UUID for inserted metadata - create new a UUID for the metadata records you are
loading.
• Stylesheet- Allows you to transform the metadata record using an XSLT stylesheet before load- ing the record. The drop down control is filled with the names of files taken from the IN- STALL_DIR/web/geonetwork/xsl/conversion/import folder. (Files can be added to this folder with- out restarting GeoNetwork). As an example, you could use this option to convert a metadata into schema that is supported by GeoNetwork.
• Validate- The metadata is validated against its schema before loading. If it is not valid it will not be loaded.
• Group- Use this option to select a user group to assign to the imported metadata.
• Category- Use this option to select a local category to assign to the imported metadata. Categories are local to the catalogue you are using and are intended to provide a simple way of searching groups of metadata records.
MEF file import
If you selectMEF filein theFile typeoption, only the Import actions option group is show. See above for more details. Note: a MEF file can contain more than one metadata record.
Figure 4.6:The MEF file import options
Copy/Paste XML
If you selectCopy/Pastein the Insert mode option, then a text box appears. You can copy the XML from another window and paste it into that text box. The options for loading that XML are the same as those for loading an XML file - see above.
4.3.2 Batch import
The batch import facility allows you to import a set of metadata records in the form of XML or MEF files. In order to use this facility, you have to be logged in as an administrator. After the login step, go to the administration page and select theBatch Importlink.
Clicking the link will open the batch import page. You will then have to specify a set of parameters. The following screenshot shows the parameters for batch import of a set of XML or MEF files.
• DirectoryThis is the full path on the server’s file system of the directory to scan. GeoNetwork will look for and try to import all XML or MEF files present into this directory. It is important to notice that this is the directory on theservermachine andnoton the client of the user that is doing the import.
• File Type- First option is to choose the type of metadata record you are loading. The two choices are:
• Metadata- use when loading a normal metadata record
• Template- use when loading a metadata record that will be used as a template to build new records in the editor.
• Import Action- This option group determines how to handle potential clashes between the UUID of the metadata record you are loading and the UUIDs of metadata records already present in the catalog. There are three actions and you can select one:
• No action on import - the UUID of the metadata record you are loading is left unchanged. If a metadata record with the same UUID is already present in the catalog, you will receive an error message.
• Overwrite metadata with same UUID- any existing metadata record in the catalog with the same UUID as the record you are loading will be replaced with the metadata record you are loading. • Generate UUID for inserted metadata - create new a UUID for the metadata records you are
loading.
GeoNetwork User Manual, Release 2.10.4-0
Figure 4.8:How to reach the batch import page
GeoNetwork User Manual, Release 2.10.4-0
Figure 4.9:The batch import options
• Stylesheet- Allows you to transform the metadata record using an XSLT stylesheet before load- ing the record. The drop down control is filled with the names of files taken from the IN- STALL_DIR/web/geonetwork/xsl/conversion/import folder. (Files can be added to this folder with- out restarting GeoNetwork). As an example, you could use this option to convert a metadata into schema that is supported by GeoNetwork.
• Validate- The metadata is validated against its schema before loading. If it is not valid it will not be loaded.
• Group- Use this option to select a user group to assign to the imported metadata.
• Category- Use this option to select a local category to assign to the imported metadata. Categories are local to the catalogue you are using and are intended to provide a simple way of searching groups of metadata records.
At the bottom of the page there are two buttons: • BackGoes back to the administration form. • UploadStarts the import process.
Notes on the batch import process
• When the import process ends, the total count of imported metadata will be shown
• The import is transactional: the metadata set will be fully imported or fully discarded (there are no partial imports)
• Files that start with ’.’ or that do not end with ’.xml’ or ‘.mef’ are ignored
config.xml.
The import-config.xml should be placed in the directory from which you will batch import (seeDirectory parameter above). It has a config root element with the following children:
1. categoryMapping [1]: this element specifies the mapping of directories to categories.
(a) mapping [0..n]: This element can appear 0 or more times and maps one directory name to a category name. It must have a “dir” attribute that indicates the directory and a “to” attribute that indicates the category name.
(b) default [1]: This element specifies a default mapping of categories for all directories that do not match the other mapping elements. The default element can only have one attribute called “to”.
2. schemaMapping [1]: this element specifies the mapping of directories to metadata schemas. (a) mapping [0..n]: This element can appear 0 or more times and maps one directory to the
schema name that must be used when importing. The provided schema must match the one used by the metadata contained into the specified directory, which must all have the same schema. It must have a “dir” attribute that indicates the directory and a “to” attribute that indicates the schema name.
(b) default [1]: default behaviour to use when all other mapping elements do not match. The default element can only have one attribute called “to”.
Here is an example of the import-config.xml file:
<config>
<categoryMapping>
<mapping dir="1" to="maps" /> <mapping dir="3" to="datasets" />
<mapping dir="6" to="interactiveResources" /> <mapping dir="30" to="photo" />
<default to="maps" /> </categoryMapping>
<schemaMapping>
<mapping dir="3" to="fgdc-std" /> <default to="dublin-core" /> </schemaMapping>
</config>
As described above, the import procedure starts by scanning the specified Directory. Apart from the import-config.xml file, this directory should only contain subdirectories - these are the category directo- ries referred to in the categoryMapping section of the import-config.xml file described above. Each of the category directories should only contain subdirectories - these are the schema directories referred to in the schemaMapping section of the import-config.xml file described above.
4.4 Export facilities
GeoNetwork has two different types of export function - both of which operate on selected sets of metadata from the search results. As such they are accessible from the “actions on selection” menu as shown in the following example:
The export functions: ZIP and CSV - highlighted
GeoNetwork User Manual, Release 2.10.4-0
4.4.1 Export as a ZIP archive
When a selected set of metadata records is exported as a ZIP archive, each metadata record is inserted in the ZIP archive as a directory containing the metadata, any data uploaded with the metadata record and the thumbnails. This type of ZIP archive is the MEF (Metadata Exchange Format) Version 2.0. You can find more details of MEF V2 in the GeoNetwork Developers Manual.
4.4.2 Export as a CSV file
When a selected set of metadata records is exported as a CSV/TXT file, the following process takes place for each metadata record:
• a brief summary of some of the elements from each selected meta- data record is generated by applying the brief template from the meta- data schema eg. for an iso19139 metadata record the brief template from
GEONETWORK_DATA_DIR/config/schema_plugins/iso19139/present/metadata-iso19139.xsl would be applied to the metadata record.
• the elements common to the brief summary elements for all metadata records are extracted (as they may differ according to the metadata schema)
• a title record with comma separated element names is created
• the content of each element is laid out in comma separated form. Where there is more than one child element in the brief element (eg. for geoBox), the content from each child element is separated using ‘###’.
An example of an ISO metadata record in CSV format is shown as follows:
"schema","uuid","id","title","geoBox","metadatacreationdate"
It is possible to override the brief summary of metadata elements by creating a special template in the presentation XSLT of the metadata schema. As an example of how to do this, we will override the brief summary for the iso19139 schema and replace it with just one element: gmd:title. To do this we create an XSLT template as follows:
<xsl:template match="gmd:MD_Metadata" mode="csv"> <xsl:param name="internalSep"/>
<metadata>
<!-- add in our field -->
<xsl:copy-of select="gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title"/> <!-- copy geonet:info element in - has special metadata eg schema name -->
<xsl:copy-of select="geonet:info"/> </metadata>
</xsl:template>
This template, when added toGEONETWORK_DATA_DIR/config/schema_plugins/iso19139/present/metadata-iso19139.xsl, will replace the brief summary (produced by the brief template) with just one element, gmd:title.
4.5 Status
Metadata records have a lifecycle that typically goes through one or more states. For example, when a record is created and edited by an ‘Editor’ user it is in the ‘Draft’ state. Whilst it is reviewed by a ‘Content Reviewer’ user it would typically be in a ‘Submitted’ state. If the record is found to be complete and correct by the ‘Content Reviewer’ it would be in the ‘Approved’ state and may be made available for casual search and harvest by assigning privileges to the GeoNetwork ‘All’ group. Eventually, the record may be superseded or replaced and the state would be ‘Retired’.
GeoNetwork has (an extensible) set of states that a metadata record can have:
• Unknown- this is the default state - nothing is known about the status of the metadata record • Draft- the record is under construction or being edited.
• Submitted- the record has been submitted for approval to a content review. • Approved- the content reviewer has reviewed and approved the metadata record • Rejected- the content reviewer has reviewed and rejected the metadata record • Retired- the record has been retired
Status can be assigned to metadata records individually or as a selected set.
Initiating status change for a single metadata record Initiating status change for a set of metadata records The interface for setting the status looks like the following: Changing the status of a set of metadata records
It is also possible to search for metadata records with a particular status using a search restriction in the ‘Advanced Search’ menu.
4.5.1 Status actions
The status values shown above are held in a database table called MetadataStatus. Extra states can be added to this table if required.
There are two status change action hooks (in Java) that can be used by sites to provide specific be- haviours:
1. statusChange- This action is called when status is changed by a user eg. when ‘Draft’ records are set to ‘Submitted’ and could be used for example to send notifications to other users affected by this change.
2. onEdit- This action is called when a record is edited and saved and could be used for example to reset records with an ‘Approved’ status to ‘Draft’ status. A default set of actions is provided. These can be customised or replaced by sites that wish to provide different or more extensive behaviour.
A default pair of metadata status change actions defined in Java is provided wit GeoNetwork - see the classorg.fao.geonet.services.metadata.DefaultStatusActions.java.
statusChange: This action is called when status is changed by a user. What happens depends on the status change taking place:
• when an ‘Editor’ changes the state on a metadata record(s) from ‘Draft’ or ‘Unknown’ to ‘Submitted’, the Content Reviewers from the groupOwner of the record are in- formed of the status change via email which looks like the following. They can log in and click on the link supplied in the email to access the submitted records. Here is an example email sent by this action:
Date: Tue, 13 Dec 2011 12:58:58 +1100 (EST)
From: Metadata Workflow <[email protected]>
Subject: Metadata records SUBMITTED by [email protected] (User One) on 2011-12-13T12:58:58 To: "[email protected]" <[email protected]>
Reply-to: User One <[email protected]>
Message-id: <1968852534.01323741538713.JavaMail.geonetwork@localgeonetwork.org.au> These records are complete. Please review.
Records are available from the following URL:
http://localgeonetwork.org.au/geonetwork/srv/en/main.search?_status=4&_statusChangeDate=2011-12-13T12:58:58
• when a ‘Content Reviewer’ changes the state on a metadata record(s) from ‘Submitted’ to ‘Accepted’ or ‘Rejected’, the owner of the metadata record is informed of the status change via email. The email received by the metadata record owner looks like the following. Again, the user can log in and use the link supplied in the email to access the approved/rejected records. Here is an example email sent by this action:
Date: Wed, 14 Dec 2011 12:28:01 +1100 (EST)
From: Metadata Workflow <[email protected]>
Subject: Metadata records APPROVED by [email protected] (Reviewer) on 2011-12-14T12:28:00 To: "User One" <[email protected]>
Message-ID: <1064170697.31323826081004.JavaMail.geonetwork@localgeonetwork.org.au> Reply-To: Reviewer <[email protected]>
GeoNetwork User Manual, Release 2.10.4-0
Records approved - please resubmit for approval when online resources attached Records are available from the following URL:
http://localgeonetwork.org.au/geonetwork/srv/en/main.search?_status=2&_statusChangeDate=2011-12-14T12:28:00
onEdit: This action is called when a record is edited and saved by a user. If the user did not indicate that the edit changes were a ‘Minor edit’ and the current status of the record is ‘Approved’, then the default action is to set the status to ‘Draft’ and remove the privileges for the GeoNetwork group ‘All’.
4.5.2 Changing the status actions
These actions can be replaced with different behaviours by:
1. writing Java code in the form of a new class that implements the interface defined in org.fao.geonet.services.metadata.!StatusActions.java and placing a compiled version of the class in the GeoNetwork class path
2. defining the name of the new class in the statusActionsClass configuration parameter in INSTALL_DIR/web/geonetwork/WEB-INF/config.xml
4.6 Versioning
There are many use cases where it is important to be able to track (over time): • changes to the metadata record
• changes to properties of the metadata record eg. privileges, categories, status
GeoNetwork uses a subversion repository to capture these changes and allow the user to examine the changes through the various visual interfaces to subversion repositories that already exist eg. viewvc. Apart from the advantage of ready to use tools for examining the changes, the subversion approach is efficient for XML files and simple to maintain.
The database remains the point of truth for GeoNetwork. That is, changes will be tracked in subversion, but all services will continue to extract the latest version of the metadata record from the database.
4.6.1 Selecting records to version
Not all records in GeoNetwork are tracked as the compute and systems admin cost of this tracking for every record, particularly in large catalogs, is too high. Instead only those records selected by the user in the local GeoNetwork instance will be tracked in the subversion repository.
Records can be selected for versioning individually or by doing a search and selecting a set of records. Starting versioning on a single record
Starting versioning on a selected set of records
GeoNetwork User Manual, Release 2.10.4-0
from the database and passed as a commit to the subversion repository, creating a new version in the repository. This process is automatic - at the moment the user cannot force a new version to be created,