1. 1 Fedora and versioning VIF Workshops 22 nd April 2008 Richard Green (University of Hull)

2. 2 Fedora object model persistent identifier DC metadata other metadata 1 other metadata n relationships datastream1 datastream 2 datastream n System identifier { Metadata datastream(s) { Content datastream(s)

3. 3 Example Fedora text object model persistent identifier DC metadata MODS metadata preservation metadata relationships thumbnail Pdf file Word file System identifier { Metadata datastream(s) { Content datastream(s)

4. 4 Example Fedora text object model 2 persistent identifier DC metadata MODS metadata preservation metadata relationships thumbnail Pdf file (v1.0) Word file { System identifier { Metadata datastream(s) { Content datastream(s) Version 0.1 Version 0.n Version 1.0

5. 5 RepoMMan tool The RepoMMan project developed a tool to allow users to interact with a ‘private’ repository space:

6. 6 RepoMMan tool - versions Double clicking a “file” (actually a digital object in the repository) allowed the user access to versions (uploading a file creates a version, not a replacement):

7. 7 Datastream versions Any metadata or content datastream can be versioned Identified by date-time stamp Default is to retrieve most recent time-stamped version All versions can be retrieved at will...but no easy way to match a data version with a metadata version.

8. 8 So what are we versioning? ‘Versions’ versus ‘revisions’ A single Fedora object is best suited to developments of the same thing (v0.1, 0.2, 0.3...) Significantly different forms of content (author’s completed first draft, author’s final, publisher’s version, second edition) are probably best kept as different Fedora objects with relationships declared between them

9. 9 Identifiers Essential (well, good practice anyway) that the metadata of related objects contains the basis for declaring relationships (shared elements: common title, original catalogue reference,...) Include as many identifiers as possible and provide clarity about what the ‘digital payload’ represents

10. 10 Contact etc Richard Green (r.green@hull.ac.uk)