Specifying the Fedora API

I.    Motivation

1. Durability for the content must be supported by durability for the repository machinery itself.

2. What is durability? It's complicated.

3. 1. Durability is not absence of change.

   2. Durability is not resistance to change.

   3. Something is durable when:

   4. 1. 1. it responds elegantly to change

         2. while preserving or conserving its meaning or intention.

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

   1. 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.
5. A specified API allows systems that include a Fedora repository to evolve carefully and without nasty surprises: to respond to change gracefully, while preserving the meaning of our repository services.
   
   1. Don't we have a specified API?
   2. No. We have extensive human-readable documentation.

      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!"

II.    What to do: The three kinds of Fedora

    ⁃    Fedora, the information architecture

    ⁃    E.g. "Object", "Datastream", "Dissemination", etc.

    ⁃    have evolved greatly over the years, but not in a formally-specified manner

    ⁃    Aren't accessible to machine-processing by non-Fedora software without a lot of human intervention

    ⁃    The Fedora community

    ⁃    a "repository" of praxes and human relationships

    ⁃    this meeting is an example

    ⁃    Fedora Commons

    ⁃    Built by the community as the premier implementation of the information architecture.

    ⁃    Not the only implementation

    ⁃    Bill Parod's experiments

    ⁃    UCSD and Oxford

    ⁃    Durability

    ⁃    for Fedora information architecture

    ⁃    The clarification and publication of ontological claims (content modeling and the graph of relationships amongst resources)

    ⁃    What is an intellectual object?

    ⁃    What kinds of relationships obtain amongst intellectual objects?

    ⁃    for the Fedora community

    ⁃    arises from concerted action

    ⁃    My ontological claims are both stronger and more useful when they are shared

    ⁃    My practices become better as I refine them by comparison with yours

    ⁃    We can reduce the costs of practice by sharing them

    ⁃    for Fedora Commons

    ⁃    arises from well-known properties of open source development and software engineering

    ⁃    modularization

    ⁃    good versioning

    ⁃    testability

    III.    Let's apply these ideas to the Fedora API

    ⁃    We want an API that:

    ⁃    Makes its ontological commitments clear and makes them publicly available

    ⁃    Makes it easy to establish and curate relationships amongst resources

    ⁃    Integrates with larger communities to share burdens and strengthen practices

    ⁃    Makes it easy for the Fedora community to integrate with larger communities (the Semantic Web, the Web itself)

    ⁃    Features well-known properties of good software engineering that contribute to durability

    IV.    What are we doing with the API?

    ⁃    The API consists of a core and modules

    ⁃    Modularization means choice

    ⁃    Modules are organized into larger logical units of API pieces you would be likely to use together

    ⁃    Every module (including the core) will comprise an API specification, an accompanying ontology, and test suites

    ⁃    testability!

    ⁃    The API spec tells you how to talk with a repository, the ontology tells you what the communication means (syntax and semantics)

    ⁃    We work from a context within larger communities

    ⁃    The Semantic Web

    ⁃    RDF all the things!

    ⁃    Makes the technical language of the API the same as the language for content

    ⁃    In Fedora 3, XML was the technical language and often the language for content

    ⁃    We expect RDF to take that role

    ⁃    Use formal ontologies to describe the Fedora model

    ⁃    Doesn't mean you have to use them, but they are available

    ⁃    Makes it easier to use formal ontologies to work with content

    ⁃    Makes our ontological commitments clear and public

    ⁃    Provides artifacts that can be handled by machine (as opposed to human-readable documentation like wikis)

    ⁃    W3C/LDP

    ⁃    A standard for services on the Web that transact in Linked Data

    ⁃    Repositories are an example

    ⁃    Handles CRUD for content and relationships-- the core of the API

    ⁃    Technical aspects of the repository are just a special kind of content with system-defined semantics

    ⁃    We are closely engaged with the LDP WG (thanks Stanford, especially Rob Sanderson!) helping it to evolve in ways that will be good for Fedora

    ⁃    The modules:

    ⁃    The Workflows APIs: What you need for basic operation

    ⁃    The core: LDP + core ontology

    ⁃    CRUD for resources, including their relationships

    ⁃    Transactions

    ⁃    Versioning

    ⁃    Locking

    ⁃    The Administration APIs: what you need to administer a repository as a whole

    ⁃    Adminstrative Search

    ⁃    Backup/Restore

    ⁃    Sitemap (which has an uncertain future)

    ⁃    Other guys

    ⁃    Fixity

    ⁃    Identifier minting (which has an uncertain future)

    V.    Where we are, how to help

    ⁃    Questions!?