This document serves as a basic user's guide for the CAS-Curator project. The goal of the document is to allow users to check out, build, and install the base version of the CAS-Curator, as well as perform basic configuration tasks. For advanced topics, such as customizing the look and feel of the CAS-Curator for your project, please see our Advanced Guide.
The remainder of this guide is separated into the following sections:
File Manager Configuration
The CAS-Curator uses ancillary programs called metadata extractors to produce the metadata that it associates with products. More information about metadata extractors can be found in the Extractor Basics User's Guide.
Like the staging area, we first need to set up an area in the file system for metadata extractors. We will call this directory
In order to register the metadata extractor path with the CAS-Curator, we will need to add another parameter to the web application's context file. Add the following parameter:
We are going to make a metadata extractor that will extractor ID3 tag metadata, such as author, title, resource type, etc from mp3s. As a first step, we will create a directory for the new extractor. The name of this directory is important, because CAS-Curator will use the directory name to register the extractor. We will name this directory
While we could write a custom extractor in Java for the Cas-Curator, there are multiple existing software packages that read mp3 ID3 tags. For these situations, where an external, command-line extractor exists, we have developed the
ExternMetExtractor class in the CAS-Metadata project.
For this example, we are going to leverage an existing, open source mime-type detector with text and metadata parsing capabilities called Apache Tika. Tika parses a number of different common data formats, including a number of audio formats like mp3. I'll leave it to the reader of this guide to download and install Tika. We will assume that the latest release of the tika-app jar is in the
We have a little work to do to convert the output of Tika into a metadata file compatible with CAS-Curator. By default, Tika produces metadata in a "key: value" format as shown in the command-line session below:
With a little AWK magic, we can convert this output to the Cas-Metadata xml format:
Cool as a one line format translator is, we are actually going to have to do a little more work to create an extractor capable of producing metadata for CAS-Curator. A requirement for metadata extractors that are to be integrated with CAS-Curator is that they product three pieces of metadata:
We should note that this is NOT a general requirement of all metadata extractors, but a ramification of the current implementation of CAS-Curator. In order to product this extra metadata, we will develop a small Python script:
We'll assume that you have Python installed at
/usr/bin/python and you have named this script
mp3PythonExtractor.py and placed it in
/usr/local/extractors/mp3extractor. We'll need to make sure it is executable from the command-line:
Now that we have a metadata extractor that meets our requirements (it's callable from the command-line, it produces CAS-Metadata compatible XML, and it extracts ProductType, Filename, and FileLocation), the next step is to create an
ExternMetExtractor configuration file. This file will configure CAS-Metadata's
ExternMetExtractor to call the
mp3PythonExtractor.py script correctly.
There is more information about
ExternMetExtractor configuration available in CAS-Metadata's Extractor Basics User's Guide. For the purposes of this guide, we will assume that the reader is familiar with configuration of this extractor, so we will just present the configuration below (we assume that you name this file
The last step in configuring our mp3 metadata extractor is to provide a properties file for CAS-Curator so that it knows how to call the
ExternMetExtractor. Each extractor used by CAS-Curator needs a
config.properties file. This file sets two properties:
config.properties file (this name is important for CAS-Curator to pick up the cofiguration) in the
/usr/local/extractors/mp3extractor directory. This file should consist of the following parameters:
To recap, we first created a Python script that calls Apache Tika to extract metadata from mp3 files. Then we created a configuration file that configures CAS-Metadata's
ExternMetExtractor to call this python script. Finally, we created a properties file for the CAS-Curator to call the
ExternMetExtractor. To confirm the configuration of this extractor, we can long list the extractor directory:
Once you restart Tomcat, the change you have made to the context file will be used. The extractor area will now be set to
In the above screenshot, we see that, upon clicking on the mp3 file, metadata produced by the
mp3extractor is shown in the main right staging pane. Now staging and extraction are set up. In the next section, we will set up a CAS-Filemgr instance and show how CAS-Curator can be used to ingest products.
File Manager Configuration
The final step in our basic configuration of CAS-Curator is to configure a CAS-Filemgr instance into which we will ingest our mp3s. There is a lot of information on configuring the CAS-Filemgr in its User's Guide. We will assume familiarity with the CAS-Filemgr for the remainder of this guide.
In this guide, we will focus on the basic configuration necessary to tailor a vanilla build of the CAS-Filemgr for use with our CAS-Curator. We will assume that you have built the latest release of the CAS-Filemgr (v1.8.0 at the time of this writing) and installed it at:
The first step in configuring the CAS-Filemgr is to edit the filemgr.properties file in the etc directory. This file controls the basic configuration of the CAS-Filemgr, including its various extension points. For this example, we are going to run the CAS-Filemgr in a very basic configuration, with both its repository and validation layer controlled by XML configuration, a local data transfer factory, and a Lucene-based metadata catalog.
In order to create this configuration, we will change the following parameters in the
/usr/local/oodt/cas-filemgr/catalog. This parameter tells CAS-Filemgr where to create the Lucene index. The first time you start the CAS-Filemgr, make sure that this file does NOT exist. The CAS-Filemgr will take care of creating it and populating it with the appropriate files.
file:///usr/local/oodt/cas-filemgr/policy/mp3. The value needs to be a URL and we are pointing to a policy folder we will create.
file:///usr/local/oodt/cas-filemgr/policy/mp3. Like the last parameter we configured, this parameter should be a URL and point to the same policy folder.
With these changes, you are ready to run the basic configuration of the CAS-Filemgr. In order to make this install of CAS-Filemgr work with our CAS-Curator, however, we will also need to augment the basic policy for both the repository manager and validation layer.
First, we will create a policy directory for our mp3 curator. We can do this by moving the current policy files from the base
policy directory to a
Next, we will add a product type to our instance of the CAS-Filemgr. In order to do this, we will edit the
product-types.xml file in the
policy/mp3 directory. We will add the following as a child of the
<cas:producttypes> node (we purposefully elide any commentary on the details of this configuration and leave it to the reader):
Next, we will create a number of elements in the
elements.xml file. There will be an element node for each of the metadata elements we want to associate with MP3 products. We can do this be adding the following as children nodes of
After we have configured the new metadata elements, we will need to map these elements to our MP3 product. We do this by editing the
product-type-element-map.xml file in the
policy/mp3 directory to add the following as a child node to
A final configuration step will be to create the archive area for the CAS-Filemgr (You'll remember that we set the repository path for MP3 products in the
product-types.xml file). In order to do this, we will just make the directory:
We will now start the CAS-Filemgr instance. This instance will run on port 9000 by default. In order to start the Filemgr, we will issue the following commands:
Now that we have started the CAS-Filemgr, we will need to configure the CAS-Curator to use this Filemgr instance. In order to do this, we will add the following parameters to the CAS-Curator context file:
Once we restart Tomcat, the CAS-Curator will now recognize the policy and properties of the configured CAS-Filemgr instance and use this instance during the ingest process.
From the above image, you can see that the CAS-Filemgr configuration has been picked up by CAS-Curator. If you double-click on MP3 in the left filemgr main pane, you will see the product types that are contained in the mp3 policy:
GenericFile which was part of the default configuration, and MP3 which we added. Clicking on MP3, we bring up the ingest interface in the right filemgr main pane.
Once we drag the Bach-SuiteNo2.mp3 from the staging pane to the green box in the right filemgr main pane, we can then select a metadata extractor from the pulldown menu and click on the "Save as Ingestion Task." This will add the Ingest task to the bottom pane as illustrated in the above screenshot. In order to test file ingestion, we will click on the "Start" button.
As a final step, we will confirm that the mp3 file was archived. We can do this by listing the archive:
Worth noting is the fact that our configuration of the CAS-Filemgr included a selection of the
BasicVersioner as the MP3 product type versioner. This means that mp3s are placed at \archive_base\/\filename\/\filename\ during ingest.
We have now completed a base configuration of the CAS-Curator. In the Advanced Guide, we will cover topics like changing the look and feel of the Curator, and security configuration.