Workspace item: An item that is under submission and active edit by an authorized user. The workspace item is visible only to the submitter and the system administrators (currently there are not friendly way to find/browse such items other than go with direct item ID or use the supervisor functionality). Using the supervisor functionality a system admin can allow other authorized user to see/edit the item in the workspace state.

Expected use cases:

-          Self deposit

-          Collaboration over an in-progress submission for small group of researcher (this use case is implemented only with major limit with the supervision feature – concurrency, lack of delegation: supervision need to be defined by the sys administrators, etc.)

 

Workflow Item: An item that is under reviewing for quality control and policy meet assurance. The workflow item is visible to the original submitter (currently only basic metadata are visible out-of-box in the mydspace summary list), users  assigned to the specific workflow step where the item reside, and system administrators (currently there are not friendly way to find/browse such items other than go with direct item ID or use the abort workflow functionality).

Expected use cases:

-          Quality control assurance

-          Improvements to the bibliographic record (metadata available in workflow can be different than which ones asked to the submitter)

-          Check of policy / copyright

 

Withdrawn item: It is a logical deletion. It can be restored and it can be used to keep track of what has been available for a while on the public site.

Expected use cases:

-          Staging area for item to remove when copyright issues arise with publisher. If the copyright issue is confirmed the item will be permanently deleted or keeped in the withdrawn state for future reference

-          Logical deletion delegated to community/collection admin, where permanently deletion is reserved to system administrators

-          Logical deletion, where permanently deletion is not an option for some organization

-          Removing of an old version of an item forcing redirect of a new up-to-date version of the item (this use case is not currently implemented out-of-box in DSpace, see )

Private item: as said by the tips in the submission and by the underline java attribute “discoverable” this state should only refer to the discoverable nature of the item. A private item will be not included in any system that aims to help users to find items. So it will not appears in

-          Browse

-          Recent submission

-          Search result

-          OAI-PMH (at least for the ListRecords and ListIdentifiers verb; though the OAI-PMH specification are not clear about inconsistent implementation of the ListRecords and GetRecord verb)

-          REST list and search methods

It should be accessible under the actual ACL rules of DSpace using direct URL or query method such

-          Splash page access (i.e. /handle/<xxxxx>/<yyyyy>)

-          OAI-PMH GetRecord verb

-          REST direct access /rest/item/<item-id> or equivalent

Expected use cases:

-          Provide a light right awareness feature where discovery is not enabled for the search and/or the browse

-          Hide “special items” such repository presentations, guide or support materials

-          Hide an old version of an Item in case where real versioning is not appropriate or liked

-          Hide specific types of item such as “Item used to record Journal record: Journal Title, ISSN, Publisher etc.” used as authority file for metadata (dc.relation.ispartof) of “normal item”

Archived/Published item:

An item that is in a “stable” state available on the repository under the defined ACL rule. Changes to these items are possible only for a restricted group of users (administrators) and should produce versioning according to the Institution policy.

Embargoed Item (as in DSpace 3.0+):

Are a special case of Archived/Published Item. The item has some time based ACL attached to it and/or the underlying bitstreams. Specifically read permission for someone (EPerson Group) starting from a defined date. Typically embargo apply to the bitstreams so that "fulltext" has initially very limited access (normally administrators or other "repository staff" groups) and only after a defined date the fulltext become visible to all users (Anonymous group). This scenario is used to implement typical "embargo requirements" from publishers see http://en.wikipedia.org/wiki/Delayed_open_access

If the metadata of the item should be visible only to specific group of users it is possible to define an embargo policy also for the ITEM itself, a READ policy for a specific group will mean that only the users in that group will be able to access the item splash page. Note that currently only some UIs (JSPUI/XMLUI) and in a very specific configuration (discovery enabled as search provider, and the SOLRBrowseDAOs is used for the Browse system) are full rights aware, this mean that in different UIs or with different configurations (legacy lucene search or DBMS browse)  some metadata of restricted item could be exposed to unauthorized users. When you need to work with UIs not fully rights aware a workaround can be to use the "Private Item" flag to make the item undiscoverable so that metadata will be not exposed to unauthorized users. Please note that this workaround has several major limitation:

  • no one, not ever authorized users,  are able to find the item browsing or searching the repository
  • you need to manage externally a schedule that alert you when the embargo is expired so to re-enable the discoverable nature of the item
  • No labels

1 Comment

  1. Richard Rodgers

    Hi Andrea:

    Thanks for the useful writeup, and sorry for late comments. I agree it is important to have a shared understanding of content state/lifecycle.

    A few quick observations from my perspective:

    I regard withdrawn state as 'administrative hold', rather than logical deletion. I think there are important differences between the two:

        (1) Items can be deleted that have never been withdrawn (e.g. just delete a collection, and all items are deleted), and conversely

       (2) Withdrawn items can be reinstated (which deleted items cannot).

       (3) Withdrawn items are 'resolvable' in the data model and to end-users: they see a 'tombstone' for withdrawn (= we have this, but it's on hold), whereas for deleted content, they would get a 'not found'.

    DSpace doesn't really have a logical delete in that sense. I wish it did, actually. We have sort of a halfway lmeasure, where the metadata gets purged, but the bitstreams are only flagged as deleted (they disappear when 'cleanup' is run).

    Private items: I think you have captured the behavior, but I struggle to come up with a really coherent and useful meaning for this 'state'. It seems more like a 'hint' to application code to do certain things. But it doesn't seem to limit discoverability really: as long as the content is fetch-able (accessible), it will surely be discoverable.  Bots like Google do not need browse pages to find content, since they can guess that URLs similar to ones that resolve might also contain content.

    And 'private' in the other sense - meaning limited access - is customarily modeled in DSpace with Resource Policies. So I'm unclear what the state adds to this.

    I'll try to think on this and add some more comments.

     Thanks again,

    Richard

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