info:sid/localhost:CollectionOaiCat:CustomizationNotes info:sid/localhost:CollectionOaiCat CollectionOaiCat http://alcme.oclc.org:80/wikid/search/WikiDb.localhost CustomizationNotes display OAICat Documentation userAssigned mailto:jyoung@oclc.org no info:sid/localhost:CollectionSimpleSchemas:wiki info:sid/localhost:CollectionExternalSchemas:xhtml info:sid/localhost:CollectionExternalSchemas:xhtml 1.1 1 5yvzzn 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionOaiCat:CustomizationNotes anonymous CollectionOaiCat 2006/07/05/11 inf_3asid_2flocalhost_3aCollectionOaiCat_3aCustomizationNotes_5f20060705111903375 text/xml CollectionOaiCat:CustomizationNotes 2005-08-12 2006-07-05 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionOaiCat:CustomizationNotes" cql.any = huh? 1 1 xml default 2006-07-05 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2006/07/05/11/inf_3asid_2flocalhost_3aCollectionOaiCat_3aCustomizationNotes_5f20060705111903375 = Customization Notes = * See /EclipseSysdeo for notes about customizing OAICat using the Sysdeo plugin for Eclipse. * See /MultipleDatabases for notes about using a single OAICat webapp with multiple databases. Although the OAICat demo war file comes configured with a simple file-based data collection, OAICat was really designed to work with a data collection in its existing form. Configuration is generally achieved by changing entries in the $TOMCAT_HOME/webapps/oaicat/WEB-INF/oaicat.properties file. Three abstract Java classes exist to facilitate this goal: 1. ORG.oclc.oai.server.catalog.Abstract''''''Catalog (corresponds to the Abstract''''''Catalog.oaiCatalogClassName entry in the oaicat.properties file) 2. ORG.oclc.oai.server.catalog.Record''''''Factory (corresponds to the Abstract''''''Catalog.recordFactoryClassName entry in the oaicat.properties file) 3. ORG.oclc.oai.server.crosswalk.Crosswalk (corresponds to one or more Crosswalks.xxxx entries in the oaicat.properties file) == AbstractCatalog == The Abstract''''''Catalog class exists to abstract the type of database engine used to access the collection. The class that implements Abstract''''''Catalog is responsible for invoking database API calls for each OAI verb to obtain native records used to fulfill an OAI verb request. Several example implementations are included in the distribution, but user-defined classes can be created and used as well. * FileSystemOaiCatalog - Records are stored in individual XML files in the system's directory structure. * NewFileSystemOaiCatalog - Records are stored in individual XML files in the system's directory structure (suitable for repositories that need to support OAI sets) * XmlFileOaiCatalog - Records are stored in a single XML file on disk. * JdbcOaiCatalog - Records are stored in a JDBC-accessible relational database. ** http://pubserv.oclc.org/oaicat/jars/docs/jdbc.html * JdbcLimitedOaiCatalog - can be used in place of JDBCOAICatalog if the SQL "Limited" qualifier is supported. * SruOaiCatalog - Records are stored in an SRU-accessible search service. In principle, the Abstract''''''Catalog implementation class should not make any assumptions about the native record schema. It should treat records from start to finish as generic Java Objects so that the class can be reused for a variety of native record types. This may not make sense for a relational database, but imagine a database engine capable of storing and retrieving records in MARC XML, MARC Communications, MODS, METS, etc. depending on the situation (e.g. SRU). Semantic understanding of the native record schema should be left up to the Record''''''Factory and Crosswalk classes discussed below. That way, Abstract''''''Catalogs, Record''''''Factories, and Crosswalks can be mixed and matched in the oaicat.properties file without changing the code. == RecordFactory == The Record''''''Factory abstract class exists to facilitate the generation of an OAI record header from a native record Object. This implies, of course, that the native record Object must somehow contain an identifier, datestamp, and optional setSpecs. The core of OAICat makes no assumptions about the native record structure, which explains the need for this class to fulfill the OAI record header requirement. Several Record''''''Factory implementation classes are included in the distribution, but user-created classes can be used as well. * File''''''Record''''''Factory - the OAI identifier is derived from the filename of the record as found in the system's directory structure. The OAI datestamp is taken from the file's datestamp. Set''''''Specs are not supported by this implementation. * XMLFileRecordFactory - assumes the records are all stored in a single XML file, pre-formatted as an OAI record response. * JDBCRecordFactory - assumes the identifier, datestamp, and setSpecs are contained in SQL columns named according to entries in the oaicat.properties file. == Crosswalk == Each metadataFormat to be provided by the OAI repository must be configured in the oaicat.properties file by specifying a Crosswalk implementation class for each. These classes are responsible for transforming the native record Object into an XML record that will be inserted into the record's metadata element in the response. As in the cases above, a number of implementations are included in the distribution, but user-created classes can be used as well. * File''''''Map2oai_dc - The native record Object, in this case, is a Map containing information about the record and it's location on the file system. If no stylesheet is specified, the record found on disk is returned unmolested. If a stylesheet is configured, the record is transformed before being returned.

Customization Notes

Although the OAICat demo war file comes configured with a simple file-based data collection, OAICat was really designed to work with a data collection in its existing form. Configuration is generally achieved by changing entries in the $TOMCAT_HOME/webapps/oaicat/WEB-INF/oaicat.properties file. Three abstract Java classes exist to facilitate this goal:
  1. ORG.oclc.oai.server.catalog.AbstractCatalog (corresponds to the AbstractCatalog.oaiCatalogClassName entry in the oaicat.properties file)
  2. ORG.oclc.oai.server.catalog.RecordFactory (corresponds to the AbstractCatalog.recordFactoryClassName entry in the oaicat.properties file)
  3. ORG.oclc.oai.server.crosswalk.Crosswalk (corresponds to one or more Crosswalks.xxxx entries in the oaicat.properties file)

AbstractCatalog

The AbstractCatalog class exists to abstract the type of database engine used to access the collection. The class that implements AbstractCatalog is responsible for invoking database API calls for each OAI verb to obtain native records used to fulfill an OAI verb request. Several example implementations are included in the distribution, but user-defined classes can be created and used as well.

In principle, the AbstractCatalog implementation class should not make any assumptions about the native record schema. It should treat records from start to finish as generic Java Objects so that the class can be reused for a variety of native record types. This may not make sense for a relational database, but imagine a database engine capable of storing and retrieving records in MARC XML, MARC Communications, MODS, METS, etc. depending on the situation (e.g. SRU).

Semantic understanding of the native record schema should be left up to the RecordFactory and Crosswalk classes discussed below. That way, AbstractCatalogs, RecordFactories, and Crosswalks can be mixed and matched in the oaicat.properties file without changing the code.

RecordFactory

The RecordFactory abstract class exists to facilitate the generation of an OAI record header from a native record Object. This implies, of course, that the native record Object must somehow contain an identifier, datestamp, and optional setSpecs.

The core of OAICat makes no assumptions about the native record structure, which explains the need for this class to fulfill the OAI record header requirement. Several RecordFactory implementation classes are included in the distribution, but user-created classes can be used as well.

Crosswalk

Each metadataFormat to be provided by the OAI repository must be configured in the oaicat.properties file by specifying a Crosswalk implementation class for each. These classes are responsible for transforming the native record Object into an XML record that will be inserted into the record's metadata element in the response. As in the cases above, a number of implementations are included in the distribution, but user-created classes can be used as well.