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 CRUD behavior of RDF resources and non-RDF resources
• The ontology explains the semantics of the RDF that may be transacted via LDP
• • Other ontologies might be brought into play in a given repository, but that is instance-specific behavior, not part of the Fedora specification
• 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

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 API
  • 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 Identifier Minting API will be accompanied by an SPI that includes the type PidMinter and its meaning.

An obvious pair of questions: should any of these APIs be folded into the baseline? Are there others not yet listed here?