Page History

...

• Remove the requirement for all users to have Administrator access to the reporepository:
  • Use Workflow transitions and claims to grant each individual user write access to an individual resource instance.
  • Rely on existing graph-based access control to manage read access to unpublished resources.
• Employ role-based access control to manage access to each workflow transition
• Allow separate, isolated, streams of workflow - e.g. .  For example,  Lab A and Lab B can share a repo repository without being able even to see each other's unpublished resorucesresources.
• Produce user-sensitive reports on:
  • Transitions available to current user
  • Resources visible to current user with workflow implications
    (This might be used for autocomplete auto-complete result sets)
• Highly configurable and extensible data-driven design, so some unanticipated needs can be met simply by changing internal data and configuration

...

Here is the typical expected use of workflow.  The blue states are unpublished (and thus not indexed nor visible to the public); only the gold state is published. Lines with arrows show the possible transitions, and the role(s) permitted to take them.  The New state is implicit, it is where new instances come from. 

Two Isolated Labs

The other proposed use case is a pair (or more) of labs which share a repository, but they must not be allowed to see each other's unpublished resources.  In this picture, Lab A's resources are stored in separate workspaces - including a separate published graph and separate withdrawn graph - from Lab B's. 

The labs also have separate resource-navigator and curator roles, RNav-A, etc.  When a user in the RNav-A role creates a new instance, she must choose (or take by default, if it is the only one available) the transition out of New into the Draft state in Workspace A.   Note that the states are labelled A and B but they are really the same states, it is the workspace or other graph which separates A from B. 

Presumably the repository's access controls are configured so only Lab A's personnel have read access to the Workspace A and Withdrawn A graphs.  The two Published graphs must be world-readable, and of tyep type Published, but they also have to be separate: Resources are not "owned" by any user or role.   The workflow transitions available on a resource instance are governed by a combination of the resource's home graph and the user's role, so keeping Lab A's published resources in e.g. the Published A graph will let you configure workflow transitions on that graph so they are only available to Lab A's users.

...

The set of States is fixed and relatively immutable.  Normally a repository administrator never needs to add or remove states.  They can always do so by uploading RDF with the /graph service, but it is not expected to be necessary.  States live in the NG_Internal (intenral internal metadata) graph.

We will add a state, named "New", representing a  resource instance in the process of being created.  The state only exists momentarily inside the creation process to drive a workflow transition.

...

Actions are instances of a Java class implementing the WorkflowAction interface.  Its onTransition() method gets called with  the resource instance, and a transition-specific parameter (an RDF value object specific to the workflow transition, provided so the same action class can be re-used with different transitions).  For example, a transition that moves a resource instance to a different named graph woudl would use a common move-to-graph action with the destination graph as its parameter.  Planned stock actions include:

...

Method: GET or POST
Args:
 workspace=URI - restirct restrict results to transitions applying to given workspace (includes wildcards). Default is to list all.
 format=mime - tyep type of result.

Returns the selected workflow transitions as SPARQL tabular results.
Result columns are:

...

The workflow mechanism also requires a couple of administrative UI pages, so admins can configure and examine the workflow system, and manage instances.  All of these functions require the Administrator role.

...

Manage Workflow Transitions

This page lists all workflow transitions, along with salient details of each - enough to select the one to edit.  E.g. label, initailinitial/final states, workspace.  The master page also includes a link to create a new transaction (by filling in the detail page).

...

List resource claimed instances (restricted by workspace, user, etc) and allow the admin to release the claim, either indvidiaully individually or on a group.  Includes sorting and pagination since results may be large.