Handy links
Current game plan
We intend to develop an approach to API specification featuring a minimal core or baseline to which may be added orthogonal suites of optional features.
- Fedora 4 Baseline = LDP + Fedora 4 upper ontology + API for bytestreams
- 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 Transactions API + ontology
- Fedora Versioning API + ontology
- Fedora Locking API + ontology
- Fedora Fixity API + ontology
- Fedora Backup/Restore API
- Fedora Identifier Minting API
- Fedora Administrative Search API
- Fedora Sitemap 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.
An obvious pair of questions: should any of these APIs be folded into the baseline? Are there others not yet listed here?
Current Work
Factor the list of API portions as fully as possible, present that work to TWG
Consider the parallel factoring of the Fedora ontologies
Determine whether the LDP non-RDF source specification will be sufficient to describe the behavior of Fedora 4 bytestreams, or whether something more and more particular is needed
Deliverables
A clear explanation of the relationship between LDP and Fedora
- Particularly the place of bytestreams
API specification for human audience
Ontologies that are fully factored for API portions
TCK (test suite) for each API specification portion
- Probably based on LDP test suite
