Versions Compared

Old Version 1

changes.mady.by.user Stefano Cossu

Saved on

compared with

New Version 2

changes.mady.by.user Stefano Cossu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Title (Goal) Support Fedora 3-style object classes (content models)
Primary ActorRepository architect & implementer 
ScopeData architecture and access
LevelHigh 
Story (A paragraph or two describing what happens)

We want to implement a Fedora repository using our own client. Since we are not using Islandora or Hydra frameworks to manage object classes, therefore the solution in Fedora 3 would be to set up content models that can be attached via "hasModel" relationships to objects.

If we decide to use F4 for our repository, we need a similar facility to rely on at repository level.

Specific F3-style use cases:

  • Attach a "published for web" content model to an object on the fly (through API or admin GUI). This CM is tied to a set of SDefs and SDeps that allow generation of, and access to, "web large" and "web small" derivatives. If the relationship is broken (also via API or admin GUI) those derivatives are not available any more.
  • Enforce datastream presence in an object. If we want to attach an "image resource" content model to an object, we want to make it mandatory for that object to have a MASTER datastream with mimetype image/tiff, image/png etc.
    • Use case 1
      1. As a repository manager,
        1. I will be able to associate "content models" to objects via an API
        2. I will be able to associate services with "content models"
          1. Example services include the generation of image derivatives, and the serving of images
        3. I will be able to disassociate objects from "content models" via an API
          1. In so doing, services associated with those "content models" are no longer available on those objects
      2. As a repository user,
        1. I will be able to access resources via services that are associated with defined "content models"
    • Use case 2
      1. As a repository manager,
        1. I can define "content models" that ensure the presence of defined datastreams
          1. A defined datastream has a defined name and a defined mime-type
    • Use case 3
      1. As a repository manager,
        1. I can associate access policies to "content model" parts
        2. I will be able to associate objects with a single content model only
        3. I will be able to define relationships between objects

     

    Enforce access policies and other relationships. Objects attached to "image resource" content model MAY NOT be attached to "text resource" or "multimedia resource" content models and MAY have a "isResourceOf" relationship with an object with "manufact" content model. DC properties of objects with "published for web" content model are readable by all.

    These goals are determining for whether we may be able to implement F4.