Differences between revisions 10 and 11
Revision 10 as of 2008-10-17 08:11:04
Size: 2756
Editor: abr
Comment:
Revision 11 as of 2010-03-17 13:08:49
Size: 2761
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
attachment:StateTransition.jpeg {{attachment:StateTransition.jpeg}}
Line 30: Line 30:
The ontology for all objects of [:DataModel/ContentModel_DOMS: doms:ContentModel_DOMS] require that all subscribing objects have a literal relation, called The ontology for all objects of [[DataModel/ContentModel DOMS| doms:ContentModel_DOMS]] require that all subscribing objects have a literal relation, called

How to work without transactions

Fedora has no concept of transactions. There are situations where this is simply not good enough for the DOMS system. To get around this, we have built a system which gives us the most nessesary benefits of transactions.

Each data object in the DOMS is in one of three States.

  • draft - The object is still under preparation. The object can be edited freely. It is not available for public dissemination, and is disregarded by the validator.
  • published - The object is finished, and should be valid in regards to datamodel. The object is available for public dissemination.
  • intermediate - The object published, but is temporarily offline, as it is being updated. It is not available for public dissemination and will be disregarded by the validator.

The transition between these three states can be seen here

StateTransition.jpeg

Newly created objects will always be in the draft state. Once a user decide the object is ready for the public, the state should be changed to published. This will cause the validator to run, and if the object is valid, it will be published. Otherwise, the object will remain in draft, and the user will be notified about the errors.

Once the object is published, it can never revert to the draft state. If something needs to be changed, the object can be taken offline for a little while. The exact procedure is like this:

  1. Load the object(s) locally, and perform the changes in your local version(s).
  2. Change the state of the object(s) to intermediate
  3. Write your changes to the object(s).
  4. Change the state back to published. If your changes broke (any of) the object(s), the validator will report errors, and the state will not change (for these objects).

The State representation in an object

We have chosen to store the state as a rdf literal. This means Ressource Index queries about it are possible, which is very desireable.

The ontology for all objects of doms:ContentModel_DOMS require that all subscribing objects have a literal relation, called "state:isInState". There is formal requirements that the object be in one of the three states, but the validator code will check this.

The "RELS-EXT" datastream will therefore have such a tag

<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>published</state:isInState>

or

<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>intermediate</state:isInState>

or

<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>draft</state:isInState>

The Fedora API and State

FedoraTransactionsReplacement (last edited 2010-03-17 13:08:49 by localhost)