Versions Compared

Old Version 6

changes.mady.by.user Greg Jansen

Saved on

compared with

New Version 7

changes.mady.by.user Michael Durbin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added some UVA use cases.

...

University of Illinois

 

University of Virginia

While it's unclear whether we need to explicitly list some of the more foundational features of fedora (disaster recovery through transparent storage, integrated access control, etc.) the following use cases are either not met by the current fedora, or are listed because there's been considerable talk of dropping support for them in future versions.

Title (goal)
 Applications can be easily built to work against fedora
Primary Actor developers
Scope 
Level 
Story

 In creating an application that uses fedora as the underlying data store, the API should meet some very basic needs.

  • CRUD (create, read, update delete)
  • transactions (if the fourth API call in an operation fails, don't require the developer to roll back the previous 3, any of which steps could also fail)
  • concurrency/locking (have other programs, users, threads modified this object since I looked at it)
  • basic queries (does object X exist)
  • more complex queries (does object with character X and/or Y exist)
Title (goal)
Repository-level metadata transformations/mapping
Primary Actoruser
Scope 
Level 
Story

 A user requests metadata in a certain form.  The repository (based on RDF assertions, metadata characteristics, or any other mechanism) provides metadata in that form.  In the three-series fedora, this can be accomplished by exposing a method in a service definition for dissemination of metadata in that form.  The repository need not maintain metadata in multiple forms, it just needs to maintain mappings.  For the benefits of preservation, having this transformation be embedded in the repository is important.  (this may further the goal of TRAC B2.8 in cases where the metadata format of record is application-specific)

One of the strengths of fedora 3.* was the ease with which one could add a new service to a content model.  Updating every object to change their behaviors in the repository is an unacceptable regression to the functionality of fedora 2*.

Title (goal)
Repository generated/mediated derivatives
Primary Actor repository manager
Scope 
Level 
Story

 A user requests the download of some material from the repository.  Based on the metadata for that object, the characteristics of the requesting user the derivative provided to the user contains extra information (context, rights restrictions, etc.).  This attachment of functionality to an object in fedora must be integrated into fedora such that:

  1.  access controls at the repository level are in effect
  2. changes to this behavior can be accomplished centrally

University of Hull

 

University of Maryland

...