PubMan Collections and Organizational Units

From MPDLMediaWiki
Revision as of 13:21, 14 July 2016 by Nelli (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
eSciDoc Solutions
PubMan:
Overview · Functionalities
Interfaces · Support
Faces:
Overview · Functionalities
Scope · Support
ViRR:
Overview · Functionalities
Scope · Support
imeji
Digitization Lifecycle
edit

This page gives an overview on the relations between collections, organizational units, affiliations and users.

Introduction

The information on organizational units is important information to be kept in the system, for several reasons:

  • Publication items are published by authors, which are affiliated to an organizational unit at a given point in time.
  • Users of the system belong to a specific organization at a given point in time and due to this may be assigned with privileges to create, modify or delete objects
  • Persons are affiliated to a specific organization at a given point in time.

Functional definitions

Organizational unit

describe organizational entities (no matter the level of granularity or jurisdiction) which are stored, managed, versioned in the system. Organizational units are objects in the system. Organizational units evolve over time. They are subject to versioning, to be able to track their evolution over time (= history of organizational units). Managing organizational units is needed for collection management, workflow management, for user management and for access restrictions (e.g. IPInternet Protocol range restricted access to a fulltext file). Organizational units are objects in the system and are managed by local administrators and/or central service administrator. One or more organizational units can always be selected as affiliation(s) for a specific author.

Affiliation

describe the flat metadata information relevant for a specific publication at a specific point in time. Affiliations describe the affiliation of the author(s) to an institutional entity or project at the point of publication. the publication therefore "heredates" the affiliation of the respective authors. One or more affiliations can be attached to one author. Affiliations can be represented by organizational units managed in the system, but do not have to.

A special case of affiliations are projects. publications can be published in the context of a specific project. Project information is too complex to be managed with all details (persons related to the project, institutional entities related to the project, time span of the project etc.) We therefore do not consider projects as organizational units. In case an institute sees their projects as major organizational principle and not their organizational units (e.g. departments), they are free of course to create and manage their projects as organizational units.

Context

are the administrative units for management of the publication items. One or more organizational units are responsible for a context. Contexts are used to configure the publication workflows, user rights and privileges, default metadata values, validation rules for metadata etc.

In case the organizational units evolve over time, the successor organizational unit may close the context or may decide to maintain it further by becoming an actual responsible organizational unit for the context.

User

is related to one organizational unit. His privileges are assigned on collection level, depending also on the workflow assigned to this collection. Exception: Local administrator act on organizational unit level (e.g. creating users, creating collections), ie. they have privileges on orgunit level, not only on collection level.

Context controlled vocabulary

Controlled lists are needed both for affiliations as well as for organizational units. please see also the page on Controlled Vocabulary

The level of detail of normed information, however, is different.

Affiliations

Affiliation are flat metadata, however controlled by lists. We want to control possible naming variants and an IDIdentifier.

Organizational units

Organizational units are real objects in the system, we want to norm and manage detailed information on naming variants, predecessor and successors and their timespans, IPInternet Protocol ranges, Users, postal address etc.

Related functionalities

Browse Item

Organizational units are the default entry points to the archive, i.e. they represent the organizational units managed within the system. Triggering a search from browsing tree (by choosing to view all publications of a specific organizational unit) delivers all items affiliated to this exact organizational unit.

NOTE for user: In this context, the "network of trust" between the different organizational units is important: It might happen, that items are listed under your organizational unit which has been edited by another organizational unit. In this context, quality standards should be maintained by each organizational unit in own interest.

NOTE for user, regarding items from authors before their MPG-time: Depending on the collection policy, users are free to submit items they published before the author was affiliated to any organizational unit represented on the system (e.g. the MPGMax-Planck-Gesellschaft). For the browsing scenario, that means, that this items cannot be retrieved by browsing. User has to search for the provided affiliation to find the item.

Search Items

Items can be searched by affiliations and/or organizational units.

Edit Item

During submission, user can select the related institutional entity to an author from a list. User does not have to deal with the difference between "affiliation" or "organizational unit".

Create an entry in controlled list of affiliations

In case user wants to provide during submission information on an institution still not available in the list, he is able to enter an affiliation manually. Quality process (??) afterwards has to check, if this is "just" a new affiliation entry or if the new entry is possible candidate for new "organizational unit".(see below? or new use case?)

Edit an entry in controlled list of affiliations

We will have one central controlled list of affiliations. Entries in controlled list of affiliations can be edited by MDMetadata editors or any other QAQuality Assurance role, no matter the collection they are assigned to or the organizational unit they belong to. User should have the possibility to re-define a new entry in the list of affiliations as "organizational unit".

Create/edit an entry in authority record of organizational units

We will have one central authority file for organizational units. As this information is sensitive, it can be edited only by local administrators and central service administrator.

Open issues

please see Discussion Page