Specifying the Fedora API

What is durability? It's complicated.

1. Durability is not absence of change.

2. Durability is not resistance to change.

3. Something is durable when:

   1. it responds elegantly to change

   2. while preserving or conserving its meaning or intention.

We've learnt a lot about creating durable information from "doing Fedora".

1. We know that we have to separate the syntax of our material from its semantics.
2. We know that we have to make both public and accessible.
3. We know that sharing syntax and sharing semantics are both good things to do, but we sometime share those two things with different communities.
   1. Syntax we share with technical communities.
   2. Semantics we share with communities with which we share interest in our content.

1. Don't we have a specified API?

1. Such documentation describes, instead of prescribing.

2. That means that code written against such an API has expectations, but not guarantees.

   1. If your expectations fail, it's your problem. If guarantees fail, you share the problem with the community that makes the guarantee.
3. What is the specification of a given version of the API? "Whatever that version of Fedora Commons software does!"

1. "Object", "Datastream", "Dissemination", etc.
2. have evolved greatly over the years, but not in a formally-specified manner
3. Aren't accessible to machine-processing by non-Fedora software without a lot of human intervention

1.  a "repository" of praxes and human relationships
2. this meeting is an example

1. Built by the community as the premier implementation of the information architecture
2. Not the only implementation
   1. Bill Parod's experiments
   2.  UCSD DAMS, Oxford Databank

1. For Fedora information architecture
   1. The clarification and publication of ontological claims (content modeling and the graph of relationships amongst resources)
   2. What is an intellectual object?
   3. What kinds of relationships obtain amongst intellectual objects?
2. For the Fedora community
   1. arises from concerted action
   2. My ontological claims are both stronger and more useful when they are shared
   3. My practices become better as I refine them by comparison with yours
   4. We can reduce the costs of practice by sharing them
3. For Fedora Commons
   1.  arises from well-known properties of open source development and software engineering
   2. Modularization
   3. Good versioning
   4. Testability

1. Makes its semantics / ontological commitments clear and makes them publicly available
2. Uses widely-shared forms of syntax.
3. Makes it easy to establish and curate relationships amongst resources
4. Integrates with larger communities to share burdens and strengthen practices
5. Makes it easy for the Fedora community to integrate with larger communities (the Semantic Web, the Web itself)
6. Features those well-known properties of good software engineering that contribute to durability

1. Modularization means choice
2. Modules are organized into logical packages of API pieces you would be likely to use together
3. Every module (including the core) will comprise an HTTP API specification, an accompanying ontology, and test suites
4. The API spec tells you how to talk with a repository (syntax), the ontology tells you what the communication means (semantics)

1. The (Semantic) Web
   1. True RESTful interactions
      1. Responses are representations, not serializations
      2. Uncouples the syntax of the API from choices you make about the format of persistence
   2. RDF all the things!
      1. Makes the technical syntax of the API the same as the syntax for content
      2. In Fedora 3, XML was the technical language and often the language for content: we expect RDF to take that role
   3. Use formal ontologies to describe the Fedora model
      1. Doesn't mean you have to use them, but they are available
      2. Makes it easier to use formal ontologies to work with content
      3. Makes our semantics / ontological commitments clear and public
      4. Provides artifacts that can be handled by machine (as opposed to human-readable documentation like wikis)
2. LDP
   1. A standard for services on the Web that transact in Linked Data
   2. Repositories are an example
   3. Handles CRUD for content and relationships-- the core of the API
   4. Technical aspects of the repository (e.g. configuration, auditing information) are just a special kind of content with system-defined semantics
   5. We are closely engaged with the LDP WG (thanks especially to Rob Sanderson!) helping it to evolve in ways that will be good for Fedora

1.  Workflows APIs: What you probably want for basic operation
   1. The core: LDP + core ontology
   2. Transactions
   3. Versioning
   4. Locking?
2. Administration APIs: what you might want to administer a repository as a whole
   1.  Backup/Restore
3. Other guys
   1. Fixity

1. Understanding how LDP relates to the core ontology

1. Fixity seems particularly out of whack