SAM can be accessed using standard DAV libraries (see http://www.webdav.org/ for a listing). The SAM project has developed an updated version of the Jakarta Slide 2.0 webDAV library and command line interface that can be downloaded from the URL below. The command line interface has improved handling of XML namespaces and complex XML values. It also provides a site-to-site copy facility that can be useful as an administrative tool.
The samlib.jar file included in the SAM Client download can be used within third part applications to support webDAV operations. The API is documented on the Jakarta Slide website
The Collaboratory for Multiscale Chemical Science has developed a higher level API based on samlib.jar. More information on this API is available upon request.A default SAM server can be setup using only the Installation guide. However, many useful features of SAM require additional setup. The sections below outline several ways in which SAM can be customized for your environment and your data/metadata.
SAM 2.0 can be configured and customized by editing appropriate files and DAV resources (files stored with the SAM WebDAV repository itself and therefore available to a remote administrator). The following list is a quick reference guide. Additional information about these options are given below.
In addition to these files, which are read directly by SAM, there are several files that are loaded into the SAM repository during the first WebDAV/ELN call to the server. These files are distributed in the %TOMCAT%/webapps/sam/setup/ directory and are loaded from there to the root of the WebDAV namespace (e.g. to /config/* and /eln/*). After the initial call to SAM, these files can be accessed by users with the root role via WebDAV, or by using the web interfaces described below. These URLs for these configuration files are:
SAM Security options are described in the separate SAM Security Configuration document.
SAM 2.0 is configured by default to use the server file system as it's content store and to use XML-based files for storage of metadata, structure, and authorization and locking information. As described in the installation instructions, the location of the file store can be set with the store-base parameter in sam.xml.
SAM can be configured to use a database for content and will work with a "any" JDBC-compliant database. Configuring alternate data stores (e.g. MySQL) is accomplished via settings in Domain.xml. SAM inherits from Jakarta Slide the ability to use databases configured to use the standard Slide schema. Information about this mechanism can be found within Domain.xml and at the Slide website. SAM implements an additional mechanism that allow it to connect to a database with "arbitrary" schema, with the mapping between the database and WebDav content and properties dynamically defined using an XML configuration file. An early version of this mechanism is available in SAM 2.0 and documentation on how to configure the database mapping is in development.
A wide variety of parameters can be used to fine-tune SAM behavior with respect to WebDAV functionality. These parameters are documented within the configuration files and on the Jakarta Slide website.
To enable JMS notifications from SAM, you must install a JMS server and configure SAM to publish to it. SAM 2.0 requires OpenJMS. Download and installation information is available at the OpenJMS website. Configuration of SAM to use JMS is done through parameters in web.xml. Documentation for these parameters is given inline in the web.xml file. The minimal change required to enable JMS is to run your OpenJMS server using rmi and to change the SAM_JMS_MODE parameter in web.xml to be "rmi".
EXAMPLESAM provides a mechanism to extract metadata from submitted files, configured per file type, and to expose it as text or XML Webdav properties. This provides an opportunity to expose binary or ASCII information in XML, to translate information within files to standardized schema, and to make each piece of metadata independently accessible (Webdav properties can be individually retrieved without retrieving the content itself).
Generators are registered in the MetaGeneration.xml file using a simple XML syntax. A given file type can be optionally be assigned a Binary Format Description (BFD) language script to expose its binary or ASCII content as XML, an optional web service to process the data or BFD output, and a required XSLT script that defines WebDAV properties as a transformation of the initial XML content, BFD script output, or web service output as configured. The BFD website describes the BFD syntax. This site also provides example BFD scripts and web forms that demonstrate the BFD/XSLT processing that occurs within SAM. These forms can be used to test new BFD and XSLT scripts. The forms and servlets implementing them are distributed in SAM 2.0 - they can be enabled by uncommenting the servlet definitions and servlet-mappings in web.xml.
SAM provides a mechanism to define dynamic translations of stored data. SAM 2.0 supports a sequential application of BFD, web service, and XSLT transformations if they are specified. If specified, the web service is invoked after the (optional) BFD step and before the (optional) XSLT step. Translators are registered using the SamTranslators.xml file and examples in this file demonstrate the required syntax.
The translations available for a given file can be discovered by examining the hastranslations property. The file type of the translations, the translators used to create them, and the URL from which each translation can be retrieved are reported. Standard WebDav GET and COPY operations can be used to retrieve the translated content.
Since many different XML-based file types commonly use the .xml extension and would normally be assigned a text/xml MIME-type by web servers, developing metadata generators and translators is simplified if the various file types can be assigned individual MIME-types. SAM provides a mechanism to re-define the MIME-type of text/xml entries via the MimeDeterminiation.xsl script. This script is used to process the file content and generate as its output a DAV:getcontenttype property which is used within SAM as the assigned MIME type.
see Getting Started with the Electronic Laboratory Notebook
The pedigree graph property is an interim mechanism for simplifying discovery and display of data pedigree information. The CMCSPedigreeGraph.xml file defines which properties should be considered as pedigree links and the depth to which pedigree information should be reported. The output property is calculated dynamically when the property is requested via a DAV POROPFIND request. The format of the property is a GXL-encoded graph (labelled nodes connected by edges). Properties that are to be included in the pedigree information must follow a convention in which the name of the property is used as the edge label, and pedigree links are determined by parsing the XML value of the property and reporting the top level elements with xlink href and title elements. The exact behavior can be seen by configuring a translator for a given type and comparing the hastranslations property (which reports available translations) with the cmcspedigreegraph property when hastranslations is configured as one of the properties to be considered as pedigree.
SAM 2.0 implements a second pedigree property that reports the same information in RDF rather than GXL. This property also includes an RDF relationship between the reified translation relationship and the translator that created it.
In the %Base SAM URL%/config/transformers/ collection on the SAM server, there are a variety of example metadata generation and translation scripts. These will be updated, expanded and documented in a future SAM release. They are included to supplement the documentation above and may help in the development of scripts for additional data types.
Last updated: 9/03/04