Title (Goal)

As a data management specialist, I want to understand where my package is in the deposit workflow. 

Primary Actor

Data management specialist 

Scope

 

Level

 

Author

Elliot Metsger 

Story (A paragraph or two describing what happens)

Receive a machine-readable or human-readable document that describes the state of the workflow for my deposited package. 

After I have deposited my package, I would like to know the status of that deposit.  That way I can have confidence that the repository has received and is currently processing my deposit, or I have assurance that the deposit is on a queue, waiting to be processed.  

Being a user who understands that things can go wrong with technology, I want the ability to obtain a refreshed and up-to-date view of my deposit status at any time.   Because I am a user who is comfortable with angle brackets or curly braces, I am fine with the deposit status being serialized in a machine readable form, but it would also be nice to have a human-readable form for my colleagues who are less comfortable with XML or JSON.  

Because deposits may be queued due to a lack of system resources, the deposit may take a while to complete.  It would be really nice if the repository could alert me when the deposit completes.

If my deposit fails for whatever reason, I would want the reason to be shown in the deposit status, along with the objects that were successfully processed, so that I can take corrective action. 

 

4 Comments

  1. A. Soroka

    I can see why this kind of "dashboard" functionality is important and useful, but is it an "extension of the Fedora API" in any real sense? It seems more like a case for an independent application that happens to have a Fedora API instance as one of its backend services.

  2. Elliot Metsger

     

    I can see why this kind of "dashboard" functionality is important and useful, but is it an "extension of the Fedora API" in any real sense?

    Well, I think a deeper dive into some of these use cases are warranted, and a discussion would shed light on this.  This particular use case hasn't benefited yet from a deep discussion, as it hasn't been selected as a proof of concept by the stakeholders.

    You might imagine a collection resource exposes, implemented as API-X extension, an endpoint that exposes links to a workflow status: /path/to/resource/depositService:status

    It seems more like a case for an independent application that happens to have a Fedora API instance as one of its backend services.

    The role of API-X in this case is to link backend services to resources in the Fedora repository.

    1. A. Soroka

      Seems like you're setting up for a considerable amount of the state of workflows to go in the repository itself. I'm not arguing against that (lots of sites do it and it can work quite well) but I suspect that this use case can be decomposed into others. Your example of depositService:status seems like a combination of this and the use of external data as inputs into resource representations. If this use case is taken up I would like very much understand what the advantage of attaching this kind of "dashboard" to particular resources is.

      1. Elliot Metsger

         I would like very much understand what the advantage of attaching this kind of "dashboard" to particular resources is.

        Sure, as I mentioned, this use case hasn't been given a deep review.  The use-cases are wide-ranging and can be high-level, low-level, etc.  Some of them could be decomposed into multiple, discrete use cases or modified to handle a more general case.  

        This use case really isn't trying to specify what information is kept in the repository, vs. what is managed by a back-end workflow.   But at a minimum, this use case requires API-X to expose a backend workflow state service as link.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.