PubMan Collections and Organizational Units
This page gives an overview on the relations between collections, organizational units, affiliations and users.
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.
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. IP 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.
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.
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.
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.
Affiliation are flat metadata, however controlled by lists. We want to control possible naming variants and an ID.
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, IP ranges, Users, postal address etc.
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 MPG). 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.
Items can be searched by affiliations and/or organizational units.
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 MD editors or any other QA 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".
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.
please see Discussion Page