- What is ottosmops/oai-pmh used for in a Laravel application?
- It adds an OAI-PMH 2.0 data-provider endpoint so harvesters can query your records using standard verbs such as Identify, ListRecords, ListMetadataFormats, and GetRecord. The package handles the protocol mechanics, including verbs, error responses, metadata formats, and resumption tokens, while you supply records through a small repository contract. It is designed to sit over an existing repository or digital-library query layer, not to manage assets itself.
- How do I install ottosmops/oai-pmh with Composer?
- Install the package with Composer and let Laravel package auto-discovery register the service provider. Publish the configuration, and publish the Blade views only if you need to change the default XML output, then bind your repository implementation into the container. The supported matrix is PHP 8.2 to 8.4 and Laravel 10 to 12, so confirm your app matches before installing. Pin the version in composer.json because 1.0.0 is the first stable release.
- Which OAI-PMH verbs does the package support?
- It provides full OAI-PMH 2.0 verb support, including Identify, ListMetadataFormats, ListSets, ListIdentifiers, ListRecords, and GetRecord, along with the protocol error responses. That means you do not have to implement verb dispatch, argument validation, or error codes yourself. You should still verify every verb and all eight error codes against the upstream XSD during integration testing.
- How do I connect my own records to the OAI-PMH endpoint?
- You implement the package's OaiRepositoryContract with get, getRecordForId, and getEarliestDatestamp, then bind that implementation in the Laravel container. The contract is deliberately narrow, so most of the work is adapting your existing models or queries to the expected return shapes. Check the exact signatures and return types against the README before designing the adapter, since getting them wrong causes hard-to-diagnose protocol errors.
- Can I expose Dublin Core and custom metadata formats?
- Yes. Metadata formats are configurable, so you can offer Dublin Core alongside additional schemas your harvesters expect. Each format needs a mapping from your records to the corresponding XML, and harvesters discover them through ListMetadataFormats. Decide early which formats are mandatory, because adding or changing formats later alters your public protocol surface.
- How do sets and set hierarchy work with ottosmops/oai-pmh?
- Sets and set hierarchy are among the protocol concerns the package owns, but you must map them onto your existing data model and expose them through your repository implementation. Sets usually correspond to collections, categories, or subject hierarchies, and they appear in ListSets and as filters on ListRecords and ListIdentifiers. Ambiguous set semantics are a common integration risk, so define the mapping and test filtering against real data.
- How do resumption tokens work for paginating large harvests?
- Resumption tokens let harvesters page through large ListRecords, ListIdentifiers, and ListSets results without timing out. The package handles token generation and continuation, but the ordering and pagination semantics required by the contract must be stable and deterministic on your side. Test cursor behaviour, token expiry, and TTL with a dataset at your expected maximum size, and load-test large harvests before rollout.
- How do I test and validate my OAI-PMH endpoint?
- The package ships an XSD-conformance suite, but that validates protocol responses, not your real repository data. Add integration tests covering every verb, all eight error codes, resumption tokens, and date granularity, then run the endpoint through an OAI validator such as the Repository Explorer. A short spike with a small representative dataset surfaces mapping problems before you commit to the integration.
- What are the datestamp and deleted-record requirements?
- OAI-PMH expects datestamps in UTC with a consistent granularity, and the package relies on your getEarliestDatestamp plus per-record datestamps to support incremental harvesting. Deleted records need a representation mode your repository can discover and expose, such as persistent, transient, or no deleted records. Incorrect timezones or inconsistent granularity are among the most common causes of failed harvests.
- Is ottosmops/oai-pmh production-ready, and what are the main risks?
- Version 1.0.0 is the first stable release, so maturity, release cadence, and the maintainer's security-response posture should be validated for your organisation. The main risks are integration-level: expensive ListRecords queries, unstable ordering for resumption tokens, and published Blade view overrides drifting from upstream. Pin the version, keep view overrides minimal, add monitoring, and roll out behind a feature flag with a rollback path.