ESciDoc Transfer Ownership

From MPDLMediaWiki
Revision as of 09:42, 7 January 2011 by Kristina (talk | contribs) (→‎Issues)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Resources[edit]

  • for Items
  • for Containers
  • for Contexts

Definitions[edit]

  • Owner of a resource in eSciDoc is a user who has created the resource (the depositor of the resource) i.e. property: created-by
  • Transferring of the ownership would mean that another user is from the moment of transferring owner of the resource

Current status[edit]

  • Item/Container resources are versioned
  • there is no distinction between created-by on resource level and created-by on version level
  • only last-modified by on version level is kept for each version
  • Context resource is not versioned
  • there is only distinction between created-by

Approaches for Items/Containers[edit]

Modify created-by for all versions of the resource (Discarded)[edit]

  • this has to be done by special core method
  • the information on who had been previous owner is lost
    • an entry in the version history shall be made with event-type (transfer ownership) and information on the old user
    • new user becomes automatically "created-by" of the resource
  • rights and privileges related to the owner automaticaly are transferred to the new owner
  • simpler, smaller revision needed

Modify created-by for last version of the resource only (Discarded)[edit]

  • core service has to introduce created-by for versions as well
  • in this case, created-by for resource will be equal to created-by for versions starting with the version in which the resource was at the time of ownership transfer
  • rights and privileges related to the owner are always checked by created-by on the resource level (not on the version)
  • complex, huge revision needed

Use new property owned-by for all versions of the resource (discarded)[edit]

  • if no owner is set, object is owned by creator
  • owner of an object is not stored in fedora, but in separate database-table (as lock-owner)
  • new core-methods to set and change an owner (for all versions!)
  • additional filters to filter objects for owner
  • possibility to create policies that are dependent on owner of an object

Rename property "created-by" to "owned-by" to have clear semantics[edit]

  • the "created-by" property will be renamed to "owner" property (to have clear semantics)
  • each Item/Container resource version has already last-modified-by property (which actually gives information which user created that particular version of a resource )
  • new "owned-by" value will be delivered in the presentation of all versions of the resource
  • XACML policies will be modified to reference "owned-by" instead of "created-by" property

Future use case: Deposit-on-behalf-on[edit]

  • would require separate service (e.g. SWORD Server API) and separate role (e.g. user A grants deposit-on-behalf rights to user B for som/all of his contexts)

Approaches for Contexts[edit]

  • one possible approach is to do nothing, but assume that the user who needs to do something on the context has Context Modifier role
  • another approach is to transfer the ownership to another user who has context administrator role
  • note: Roles are extended on the referenced pages

Issues[edit]