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.
- LDP defines the HTTP behavior of RDF resources and non-RDF resources; the syntax of the core API.
- The ontology gives the meaning of the RDF that may be transacted via LDP; the semantics of the core API.
- Other ontologies may be 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 Backup/Restore API
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 Backup/Restore API should be accompanied by an SPI that includes the types 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?