info:sid/localhost:CollectionOaiCat:FrequentlyAskedQuestions info:sid/localhost:CollectionOaiCat

CollectionOaiCat

http://alcme.oclc.org:80/wikid/search/WikiDb.localhost

FrequentlyAskedQuestions

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 nkf7ee 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionOaiCat:FrequentlyAskedQuestions anonymous CollectionOaiCat 2006/03/29/09 inf_3asid_2flocalhost_3aCollectionOaiCat_3aFrequentlyAskedQuestions_5f20060329094005318 text/xml CollectionOaiCat:FrequentlyAskedQuestions 2005-08-15 2006-03-29 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionOaiCat:FrequentlyAskedQuestions" cql.any = huh? 1 1 xml default 2006-03-29 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2006/03/29/09/inf_3asid_2flocalhost_3aCollectionOaiCat_3aFrequentlyAskedQuestions_5f20060329094005318 = OAICat FAQ = == I installed the demo, but I get a ServletException (HTTP status 500) when I perform a request and there is a NullPointerException in the logs == The demo is configured to use relative paths to files that it needs in order to run. One solution is to invoke the startup script with $TOMCAT_HOME as the default directory (i.e. 'cd $TOMCAT_HOME; bin/startup.sh). If this isn't practical for some reason, change the webapps/oaicat/WEB-INF/web.xml and oaicat.properties files to use absolute paths in place of relative paths. == Generally speaking, how can I make my data available via OAI? == Many OAI tools are available. The list at http://www.openarchives.org/tools/tools.html would be a good place to start looking. Also consider the OAI Static Repository solution: http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm''''''. == I'm here to learn more about OAICat. What makes it special? == OAICat can be used as a stand-alone service, but its primary distinction, when compared to most other tools on the list, is that it can be integrated into existing systems. It achieves this by abstracting three key facets that can differ across systems: * the API used to access the data (e.g. JDBC or SRU) * the native record format (e.g. MARC, Dublin Core, METS) * the metadataFormats that should be made available for harvesting Example implementations of each facet are included in the distribution. If they prove to be unsuitable for a particular situation, users can substitute their own implementations for any or all of these facets. == Can you be more specific? == No. :-) Well..., maybe. Take a look at this: CustomizationNotes. The abstractions listed above are key to what makes OAICat useful for so many different scenarios. OTOH, abstraction can make it hard to wrap our minds around a problem. Until this wiki gets populated, your best bet is to contact me with details about your situation (http://www.oclc.org/research/staff/young.htm''''''). If an answer exists, I can point you to it. If not, I'll either write the general stuff up in the wiki, or else respond directly for peculiar situations. == I have 9000 records. Should I use the XmlFileOaiCatalog or FileSystemOaiCatalog implementation? == I'm guessing that either implementation can handle 9000 records. The bigger question, in my mind, is how do you plan to maintain this collection? In particular, you don't want the identifiers and datestamps changing willy-nilly when updates happen. The FileSystemOaiCatalog and XmlFileOaiCatalog are essentially toy implementations included for use with relatively static collections. XmlFileOaiCatalog in particular, might even be considered obsolete in favor of the OAI Static Repository specification: http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm''''''. Keep in mind that the real strength of OAICat is that it was designed to work with data in its natural state. If possible, we should consider where your data comes from and how we can work with it there. This might be simpler than creating procedures to duplicate the data and keep it in sync with its source. Stop and think, why are you looking at this page in the first place if not to support duplication and synchronization of data? == How do I edit records in my OAI repository? == OAICat is an output-only web service. As mentioned several times now, its primary design is directed towards integration with another system, which should take care of this for you. If you are determined to use OAICat as a standalone service (e.g. FileSystemOaiCatalog or XmlFileOaiCatalog), then do like I do and use your favorite text or XML editor to update the files on disk. == You expect me to edit my records with a text editor? That's insane! == It sounds like you need a full-fledged digital repository, not a mere OAI-PMH implementation like OAICat. Although the official list of OAI tools linked above makes little distinction, many of them are much ''much'' more than mere OAI data provider implementations. Look again to find one with the right mix of features. == What if I don't want to support the oai_dc metadataFormat? == For the sake of interoperability, the OAI-PMH specification requires that compliant repositories support oai_dc. If you don't care about interoperability, though, don't worry about being 100% compliant. Non-compliant repositories abound and last time I checked their creators were still allowed to roam free. == How do you think we might best deal with multiple kinds of data harvested and served? Separate repository instances? == * "Items" in an OAI repository can often be harvested in a variety of metadata formats ("records"). When you harvest, do you grab just one format, or multiple formats? * If you harvest from multiple sites in a common metadata format, there is no harm in throwing them together into a pile and then crosswalking them to other formats on the way out. This is the simplest solution. * If you grab multiple formats (whether from a single repository or from multiple), one solution would be to merge the various records for each item into a super record and store ''that'' in your database. When someone harvests this item, the AbstractCatalog implementation class could grab the master record and hand it off to the Crosswalks implementation class to strip out the desired record. You might even enhance your Crosswalks implementation class to fill in some gaps by transforming one of the records that ''is'' present to produce a format that is lacking. In this solution, there is no harm it throwing together records from various harvested sources. This solution is uncomfortably fancy, though, at which point separate repositories might be easier to do.

OAICat FAQ

I installed the demo, but I get a ServletException (HTTP status 500) when I perform a request and there is a NullPointerException in the logs

The demo is configured to use relative paths to files that it needs in order to run. One solution is to invoke the startup script with $TOMCAT_HOME as the default directory (i.e. 'cd $TOMCAT_HOME; bin/startup.sh). If this isn't practical for some reason, change the webapps/oaicat/WEB-INF/web.xml and oaicat.properties files to use absolute paths in place of relative paths.

Generally speaking, how can I make my data available via OAI?

Many OAI tools are available. The list at http://www.openarchives.org/tools/tools.html would be a good place to start looking. Also consider the OAI Static Repository solution: http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm.

I'm here to learn more about OAICat. What makes it special?

OAICat can be used as a stand-alone service, but its primary distinction, when compared to most other tools on the list, is that it can be integrated into existing systems. It achieves this by abstracting three key facets that can differ across systems:

the API used to access the data (e.g. JDBC or SRU)
the native record format (e.g. MARC, Dublin Core, METS)
the metadataFormats that should be made available for harvesting

Example implementations of each facet are included in the distribution. If they prove to be unsuitable for a particular situation, users can substitute their own implementations for any or all of these facets.

Can you be more specific?

No. :-) Well..., maybe. Take a look at this: CustomizationNotes. The abstractions listed above are key to what makes OAICat useful for so many different scenarios. OTOH, abstraction can make it hard to wrap our minds around a problem. Until this wiki gets populated, your best bet is to contact me with details about your situation (http://www.oclc.org/research/staff/young.htm). If an answer exists, I can point you to it. If not, I'll either write the general stuff up in the wiki, or else respond directly for peculiar situations.

I have 9000 records. Should I use the XmlFileOaiCatalog or FileSystemOaiCatalog implementation?

I'm guessing that either implementation can handle 9000 records. The bigger question, in my mind, is how do you plan to maintain this collection? In particular, you don't want the identifiers and datestamps changing willy-nilly when updates happen. The FileSystemOaiCatalog and XmlFileOaiCatalog are essentially toy implementations included for use with relatively static collections. XmlFileOaiCatalog in particular, might even be considered obsolete in favor of the OAI Static Repository specification: http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm.

Keep in mind that the real strength of OAICat is that it was designed to work with data in its natural state. If possible, we should consider where your data comes from and how we can work with it there. This might be simpler than creating procedures to duplicate the data and keep it in sync with its source. Stop and think, why are you looking at this page in the first place if not to support duplication and synchronization of data?

How do I edit records in my OAI repository?

OAICat is an output-only web service. As mentioned several times now, its primary design is directed towards integration with another system, which should take care of this for you. If you are determined to use OAICat as a standalone service (e.g. FileSystemOaiCatalog or XmlFileOaiCatalog), then do like I do and use your favorite text or XML editor to update the files on disk.

You expect me to edit my records with a text editor? That's insane!

It sounds like you need a full-fledged digital repository, not a mere OAI-PMH implementation like OAICat. Although the official list of OAI tools linked above makes little distinction, many of them are much much more than mere OAI data provider implementations. Look again to find one with the right mix of features.

What if I don't want to support the oai_dc metadataFormat?

For the sake of interoperability, the OAI-PMH specification requires that compliant repositories support oai_dc. If you don't care about interoperability, though, don't worry about being 100% compliant. Non-compliant repositories abound and last time I checked their creators were still allowed to roam free.

How do you think we might best deal with multiple kinds of data harvested and served? Separate repository instances?

"Items" in an OAI repository can often be harvested in a variety of metadata formats ("records"). When you harvest, do you grab just one format, or multiple formats?
If you harvest from multiple sites in a common metadata format, there is no harm in throwing them together into a pile and then crosswalking them to other formats on the way out. This is the simplest solution.
If you grab multiple formats (whether from a single repository or from multiple), one solution would be to merge the various records for each item into a super record and store that in your database. When someone harvests this item, the AbstractCatalog implementation class could grab the master record and hand it off to the Crosswalks implementation class to strip out the desired record. You might even enhance your Crosswalks implementation class to fill in some gaps by transforming one of the records that is present to produce a format that is lacking. In this solution, there is no harm it throwing together records from various harvested sources. This solution is uncomfortably fancy, though, at which point separate repositories might be easier to do.