Command-Line Options

The following table describes the command-line options available:

Execute Harvest Tool

The Harvest Tool operates with a policy file to register product metadata. Details on how to create this policy file can be found in the Harvest Policy File section.

This section demonstrates some of the ways that the tool can be executed:

• Registering Products From a Single Target
• Registering Products From Multiple Targets
• Registering Products From Targets Specified In The Policy File
• Registering Products To A Secured Registry Instance

Registering Products From a Single Target

The following command demonstrates how to register products to a non-secured registry instance from a target product label, product.xml, using the policy file, policy.xml, where the output is going to standard out:

% harvest product.xml -c policy.xml
        

The following command demonstrates how to register products to a non-secured registry instance from a target directory, $HOME/pds4Directory, where only files that end with a .xml file extension, will be processed:

% harvest $HOME/pds4Directory -e "*.xml" -c policy.xml
        

Registering Products From Multiple Targets

The following command demonstrates how to register products to a non-secured registry instance from two target product labels, product1.xml and product2.xml, using the policy file, policy.xml. The output will go to a log file, log-file.txt:

% harvest product1.xml, product2.xml -c policy.xml -l log-file.txt 
        

Registering Products From Targets Specified In The Policy File

Targets can either be specified on the command-line or in in the policy file. Any targets specified on the command-line will overwrite any targets specified in the policy file. The following command demonstrates registering products based on targets specified in the policy file, policy.xml:

% harvest -c policy.xml
        

Registering Products To A Secured Registry Instance

The following command demonstrates how to register products to a secured registry instance from a target product label, product.xml, using the policy file, policy.xml:

% harvest product.xml -c policy.xml -u {username} -p {password} \
  -k {keystorePassword}
        

In each scenario above, the target product(s) were the equivalent of observational or document products. The data model also consists of bundle and collection products, which in turn reference other products. When the Harvest Tool encounters one of these products, it traverses the inventory associated with that product and registers each product referenced as well as the target product.

Persistence Mode

The Harvest Tool can be run in persistence mode through an XML-RPC accessible web service called a daemon. Under this scenario, the Harvest Tool wakes up periodically, inspects a target directory or directories, and registers the latest products. This section details how to set this up.

In order to run the tool through the daemon, the command-line option flags -P and -w need to be used. This tells the Harvest Tool the port number to use and how long to sleep in between crawls, respectively. When the daemon is running, it can be accessed through the following url: http://localhost:{port number}/xmlrpc. The following command demonstrates launching the Harvest Tool through the daemon on port 9001, where it will wait 120 seconds in between crawls:

% harvest -c policy.xml -u {username} -p {password} \
  -k {keystorePassword} -l log.txt -P 9001 -w 120
        

After running the above command, the daemon will be accessible at http://localhost:9001/xmlrpc.

In order to stop the daemon from running, a daemon controller is needed. The bin/ directory of the Harvest Tool release package contains a shell script, harvest-ctrl, and a batch file, harvest-ctrl.bat, which are used to gracefully shut down the daemon service on a UNIX-like and Windows system, respectively. In addition, they can provide a few additional statistics about the crawling.

The following table describes the command-line options available for harvest-ctrl:

The following table describes the operation names available to pass with the --operation command-line option:

The following examples demonstrate how to run harvest-ctrl using a few of the different operations. For demonstration purposes, assume that the daemon service is located at the following url: http://localhost:9001/xmlrpc.

Determine the Status of the Daemon Service

The following command is used to find out if the daemon service is still running:

% harvest-ctrl --url http://localhost:9001/xmlrpc --operation --isRunning
        

Shutdown the Daemon Service

The following command demonstrates shutting down the daemon service:

% harvest-ctrl --url http://localhost:9001/xmlrpc --operation --stop
        

PDS4 Data Product Registration

The following is an example of a policy file to perform registration of PDS4 data products:

<?xml version="1.0" encoding="UTF-8"?>
<policy>
  <bundles>
    <file>/home/pds4/context-bundle/bundle.xml</file>
  </bundles>

  <collections>
    <file>/home/pds4/insthost/collection_instrument_host.xml</file>
  </collections>

  <directories>
    <path>/home/dph_examples_513B/dph_example_products</path>
    <filePattern>*.xml</filePattern>
  </directories>

  <validation>
    <enabled>true</enabled>
  </validation>

  <storageIngestion>
    <serverUrl>http://localhost:9000</baseUrl>
  </storageIngestion>

  <accessUrls>
    <baseUrl>http://pds.nasa.gov/pds4</baseUrl>
    <baseUrl>file://pds/pds4/</baseUrl>
  </accessUrls>

  <candidates>
    <namespace prefix="dph" uri="http://pds.nasa.gov/schema/pds4/dph/v01"/>
    <productMetadata objectType="Product_Observational">
      <xPath>//Identification_Area/information_model_version</xPath>
      <xPath>//Identification_Area/Modification_History/\
      Modification_Detail/modification_date</xPath>
      <xPath slotName="modification_version_id">\
      //Identification_Area/Modification_History/Modification_Detail/version_id</xPath>
      <xPath slotName="modification_description">\
      //Identification_Area/Modification_History/Modification_Detail/description</xPath>
      <xPath>//Observation_Area/Time_Coordinates/start_date_time</xPath>
      <xPath>//Observation_Area/Time_Coordinates/stop_date_time</xPath>
      <xPath>//Observation_Area/Time_Coordinates/local_mean_solar_time</xPath>
      <xPath>//Observation_Area/Time_Coordinates/local_true_solar_time</xPath>
      <xPath slotName="investigation_area_name">\
      //Observation_Area/Investigation_Area/name</xPath>
      <xPath slotName="investigation_area_type">\
      //Observation_Area/Investigation_Area/type</xPath>
      <xPath slotName="target_identification_name">\
      //Observation_Area/Target_Identification/name</xPath>
      <xPath slotName="target_identification_type">\
      //Observation_Area/Target_Identification/type</xPath>
      <xPath slotName="target_identification_description">\
      //Observation_Area/Target_Identification/description</xPath>
      <xPath>//Observation_Area/Mission_Area/dph:spacecraft_clock_start_count</xPath>
      <xPath>//Observation_Area/Mission_Area/dph:spacecraft_clock_stop_count</xPath>
    </productMetadata>

    <productMetadata objectType="Product_Document">
      <xPath>//Identification_Area/information_model_version</xPath>
      <xPath>//Identification_Area/Modification_History/\
      Modification_Detail/modification_date</xPath>
      <xPath slotName="modification_version_id">\
      //Identification_Area/Modification_History/Modification_Detail/version_id</xPath>
      <xPath slotName="modification_description">\
      //Identification_Area/Modification_History/Modification_Detail/description</xPath>
      <xPath>//Document_Desc/doi</xPath>
      <xPath>//Document_Desc/author_list</xPath>
      <xPath>//Document_Desc/acknowledgement_text</xPath>
      <xPath slotName="document_description">//Document_Desc/description</xPath>
      <xPath>//Document_Desc/publication_date</xPath>
    </productMetadata>
  </candidates>  
</policy>
       

The policy file is made up of the following complex type elements: bundles, collections, directories, validation, storageIngestion, accessUrls, candidates, and productMetadata.

bundles

Specify this element to tell the Harvest Tool to register and crawl a bundle file. The following table describes the elements that are allowed:

In the example above, the Harvest Tool will register the bundle file named /home/pds4/context-bundle/bundle.xml. It will then crawl the bundle file, looking for collection files to register and process.

collections

Specify this element to tell the Harvest Tool to register and crawl a collection file. Crawling only occurs when the collection file is a primary collection. This is indicated by a value of true in the is_primary_collection element tag within the collection.

The following table describes the elements that are allowed:

In the example above, the Harvest Tool will register the collection file named /home/pds4/insthost/collection_instrument_host.xml. It will then crawl the file, looking for products to register if it is a primary collection.

directories

Specify this element to tell the Harvest Tool where to crawl for data products. The following table describes the elements that are allowed:

In the example above, the Harvest tool will crawl the directory location, /home/user/pds4/geo/product_files, looking for files that have a .xml file extension. The default is to touch all files in the directory if the filePattern element is omitted from the policy file.

validation

Specify this element to tell the Harvest Tool to validate a data product before registering it. If the data product does not pass the validation step, the data product will not be registered. The following table describes the elements that are allowed:

By default, if the validation element is not specified in the policy file, validation is turned on.

storageIngestion

Specify this element to tell the Harvest Tool to ingest data products to the PDS Storage Service. The following table describes the elements that are allowed:

In the example above, the Harvest Tool will ingest data products to the PDS Storage Service at http://localhost:9000. When a data product is ingested to the PDS Storage, it returns a product id which is a reference to the ingested product. This id is placed as a slot in the registry under the slot name storageServiceProductId.

accessUrls

Specify this element to provide links to the physical data products. The links will be placed in the registry as slots under the slot name accessUrl. The following table describes the elements that are allowed:

The provided base urls will be prepended to the path of the registered data product. As an example, if a data product is located in /data/product/label.xml, using the base urls from the policy example above, the following access urls will be formed: http://pds.nasa.gov/pds4/data/product/label.xml and file://pds4/data/product/label.xml.

candidates

Specify this element to tell the Harvest Tool what product types to register and what metadata to extract from a data product. This is a required element in the policy file. The following table describes the elements that are allowed:

By default, the Harvest Tool defines the default namespace to be the PDS namespace. To override this default, specify the default attribute in the namespace element and give it a value of true. The following sets the dph namespace to be the default namespace in Harvest:

<candidates>
  <namespace prefix="dph" uri="http://pds.nasa.gov/schema/pds4/dph/v01" default="true"/>
          ...
       

Namespaces need to be defined in the Harvest policy file only if the metadata to be extracted exists in a namespace other than the PDS namespace. In the example above, a namespace with the prefix dph and uri http://pds.nasa.gov/schema/pds4/dph/v01 has been defined. This means that any xPath expressions defined in the policy file will be able to use the dph prefix to be able to extract metadata that are within the dph namespace. xPaths will be explained in greater detail in the productMetadata section.

productMetadata

Specify this element to tell the Harvest Tool what metadata to register. It requires an attribute called objectType that tells the Harvest Tool what product types to register. The following table describes the elements that are allowed:

In the example above, the policy file tells the Harvest Tool to look for and register the Product_Observational and Product_Document object types.

Also in the example is a set of xPath elements found under each productMetadata element. This defines what metadata to extract from the different products. XPath is a query language that uses path expressions to select nodes in an XML document. These path expressions look very much like expressions in a traditional computer file system. In its simplest form, prepending a // before a name will find the element no matter where it is in the XML file.

The following XPath expression will find the start_date_time element within the default namespace, no matter where this element is located in the file:

//start_date_time
       

The following XPath expression will find the spacecraft_clock_start_count element within the dph namespace, no matter where this element is located in the file:

//dph:spacecraft_clock_start_count
       

The following XPath expression will find all information_model_version elements that are children of Identification_Area within the default namespace:

//Identification_Area/information_model_version
       

The following XPath expression will find all name elements that are children of Target_Identification and that have a value of MARS:

//Target_Identification/name[text()="MARS"]
       

For a more detailed explanation on XPath, go to your favorite search engine and type XPath tutorial.

The slotName attribute within the xPath element allows the renaming of metadata element names when they are registered as slots in the registry. By default, the slot name is set to the element name that results from an xpath expression. For example, for the xpath expression, //Target_Identification/name, the slot name will be set to name.

The following demonstrates setting the policy file to find any name elements that are children of Target_Identification and setting the slot name to target_identification_name:

<xPath slotName="target_identification_name">//Target_Identification/name</xPath>       
       

PDS3 Product Registration

By default, the tool registers discovered PDS3 products under the Product_Proxy_PDS3 objectType in the registry. Additionally, the tool has to dynamically create certain metadata in order to support ingestion of PDS3 data products into the registry. The Harvesting of PDS3 Data Products section details how the Harvest Tool behaves when registering PDS3 data products. If viewing this document in PDF form, see the appendix for details.

The following is an example of a policy file to perform product registration of PDS3 data products:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Example of a Harvest policy configuration file that will do PDS3 data
    product registration  -->
<policy>
  <!-- Specify a single directory containing the PDS3 data products to
    register -->
  <pds3Directory>
    <path>/data/pds3/dataset</path>
    <filePattern>*.LBL</filePattern>
  </pds3Directory>
  <candidates>
    <!-- Harvest will register PDS3 data products under the objectType
      'Product_Proxy_PDS3' -->
    <pds3ProductMetadata>
        <!-- Prefix to add to the LID of a PDS3 product registration -->
        <lidPrefix>URN:JPL:PDS:ENGINEERING</lidPrefix>
        <!-- Associations to register with discovered PDS3 products -->
        <associations>
          <!-- Specify either a LID or LIDVID reference -->
          <association>
            <referenceType>has_Target</referenceType>
            <lidVidReference>URN:NASA:PDS:target.MARS::1.0</lidVidReference>
          </association>
          <association>
            <referenceType>has_Mission</referenceType>
            <lidReference>URN:NASA:PDS:mission.MER</lidReference>
          </association>
        </associations>
        <!-- Register any additional metadata. They will be registered as
          slots with their element names in lowercase form. Default is to
          register metadata defined in the identification area of the
          Product_Proxy_PDS3 schema. -->
        <ancillaryMetadata>
          <elementName>START_DATE_TIME</elementName>
          <elementName>STOP_DATE_TIME</elementName>
        </ancillaryMetadata>
        <includePaths>
          <path>/data/pds3/label</path>
        </includePaths>
    </pds3ProductMetadata>
  </candidates>
</policy>
      

This policy file is made up of the following complex type elements: pds3Directory, pds3ProductMetadata, association, ancillaryMetadata, includePaths.

pds3Directory

Specify this element to tell the Harvest Tool the directory location to crawl. The following table describes the elements that are allowed:

In the example above, the Harvest Tool will crawl for PDS3 data products starting at the location /data/pds3/dataset, looking for files with a .LBL file extension.

pds3ProductMetadata

Specify this element to tell the Harvest Tool what metadata to ingest into the registry when registering PDS3 data products. This element must be specified within the candidates tag as shown in the example. The following table describes the elements that are allowed:

In the example above, the logical identifiers of every discovered PDS3 data product will be prefixed with URN:JPL:PDS:ENGINEERING.

association

Specify this element to tell the Harvest Tool what associations belong to each discovered PDS3 data product. Specifying one or more association elements is allowed and they must be within the associations tag as shown in the example. The following table describes the elements that are allowed:

Note that lidVidReference and lidReference cannot be used together within the same association tag. Only one can be chosen.

In the example above, each discovered PDS3 product will have two associations: one with a LIDVID of URN:NASA:PDS:target.MARS::1.0 and association type of has_Target, and one with a LID of URN:NASA:PDS:mission.MER and association type of has_Mission.

ancillaryMetadata

Specify this element to tell the Harvest tool what additional metadata to register. The following table describes the elements that are allowed:

In the example above, the values from the following elements will be extracted from a PDS3 product label: START_DATE_TIME and STOP_DATE_TIME. If they are found in the label, they will be registered as slots in the registry, using their element names in lowercase form as the slot names. In this case, start_date_time and stop_date_time will be used as slot names in the registry.

includePaths

Specify this element to tell the Harvest tool the locations of where to find file references specified in a label. By default, the tool will look for the file reference in the location of the label file. The following table describes the elements that are allowed:

In the example above, the tool will look at the /data/pds3/label directory for file references if they cannot be found in the same location as the label file.