The Fedora HTTP API is partitioned into a core and optional modules. Optional modules are grouped in logical packages by use.
The core module comprises LDP with the Fedora 4 core ontology.Fedora 4 Baseline = LDP + Fedora 4 upper ontology + API for bytestreams
- LDP defines the CRUD HTTP behavior of RDF resources and non-RDF resources; the syntax of the core API.
- The ontology explains gives the semantics meaning of the RDF that may be transacted via LDP; the semantics of the core API.
- Other ontologies might may be brought into in play in a given repository, but that is module- or instance-specific behavior, not part of the Fedora core API specification.
- The same division between syntax and semantics will be observed through the API module specifications, not just in the core.
- It is an open question whether the API for non-RDF resources defined by LDP is sufficient to specify the behavior of a Fedora repository, or whether we will need to provide additional specification that is compatible with LDP but extends it. Currently, we do extend the non-RDF resource behavior of LDP in ways described below.
Optional suites might include:
- Fedora Workflows APIs
- API extensions and accompanying ontology extensions for operating repository-centric workflows
- Fedora Transactions API + ontology
- Fedora Versioning API + ontology
Fedora Locking API + ontology
- Fedora Fixity API + ontology
- Fedora Administration APIs
- API extensions for administering a repository
- Fedora Administrative Search APIFedora Backup/Restore API
- Fedora Sitemap API
- Questions have been raised as to whether a Sitemap API belongs in the repository APIs or should be loosely-coupled in the manner of indexing operations. See comments to this page.
- API
- Questions have been raised about the utility of an independent Identifier API. See comments to this page.
Some optional suites will feature their own ontologies, which will describe the RDF that they make available to transact across LDP as extensions to the upper ontology. Some optional suites may also define an accompanying Java SPI that will define types and semantics for a pluggable implementation of that suite's functionality. For example, the Identifier Minting API will the Backup/Restore API should be accompanied by an SPI that includes the type PidMinter and its meaningtypes that define backup/export formats, and extension mechanics to add to them.
An obvious pair of questions: should any of these APIs be folded into the baseline? Are there others not yet listed here?