Talk:PubMan Collections and Organizational Units

Authority files - controlled lists[edit]

It is still open, which concrete information will be stored/ maintained in the real authority file and which information will be stored in "help files" and how this information is linked.

User, Persons[edit]

Relation "user", "person" and the normed information related to them. All users are persons, but not all persons are users.

probably we need to relax a bit this terminology. Users must not be persons (e.g. one user per institution such as university etc.). Also there are non registered users who use the system. They can not be in any case related to the persons. --Natasa 15:34, 23 October 2007 (CEST)

Persons might have flat metadata attached (cf "affiliations"), user might be objects, with normed and managed information (cf "organisational units")

Comment (by Robert): It seems as if all cases mentioned in the introduction are variations on the "persons in the system are affiliated to a specific organisation at a given point in time" theme, authors and users being merely special persons. Is this correct and do all persons require an affiliation at all times?

No, there will be many persons related to a publication for which the system does not know the affiliation --Inga 13:09, 19 October 2007 (CEST)

But will the system know them as Persons? Or rather as opaque metadata of a publication? --Robert

IMHO the system will sometimes know them as opaque metadata and sometimes will have an entry to the publication -> this will probably depend on the policies set-up in a specific institute and for pubman solution. We first need to answer: shall we allow authors / persons to be stated as creators in the metadata of a publication even if we do not have an authority entry?--Natasa 15:31, 23 October 2007 (CEST)

History of organisational units[edit]

Use cases for managing the history are missing. In this context, the browse by -feature has to be adapted as well: User might want to decide if browsing items by "current" orgunit only, or include items from predecessor orgunit. What will be default setting, provided centrally? What can be configured locally, for institute-specific entry point (later releases)

Check also initial set of examples

Examples from eDoc[edit]

Example from the MPIPKS Dresden

Departments are being closed and should still be available as "former groups".

Example from the Max-Planck-Institut für Kernphysik

Groups within departments move to another department.
Groups, that belonged to a department become independent reasearch groups.
Groups within a department gets splitted and the 2 sub groubs are now in different departments.

Organizational units metadata[edit]

Current organization-details structure:

   <xs:element name="organization-details">
       <xs:element name="abbreviation" type="xs:normalizedString">
       <xs:element name="name" type="xs:normalizedString">
       <xs:element name="uri" type="xs:token" minOccurs="0">
       <xs:element name="organization-type" type="xs:normalizedString" minOccurs="0">
       <xs:element name="description" type="xs:string" minOccurs="0">
       <xs:element name="external-id" type="xs:token" minOccurs="0">
       <xs:element name="postcode" type="xs:normalizedString" minOccurs="0">
       <xs:element name="country" type="xs:normalizedString" minOccurs="0">
       <xs:element name="region" type="xs:normalizedString" minOccurs="0">
       <xs:element name="address" type="xs:string" minOccurs="0">
       <xs:element name="city" type="xs:normalizedString" minOccurs="0">
       <xs:element name="telephone" type="xs:normalizedString" minOccurs="0">
       <xs:element name="fax" type="xs:normalizedString" minOccurs="0">
       <xs:element name="email" type="xs:token" minOccurs="0">
       <xs:element name="geo-coordinate" minOccurs="0">
           <xs:element name="location-longitude" type="xs:token">
           <xs:element name="location-latitude" type="xs:token">
       </xs:element> 
   </xs:element>

Names[edit]

The organization object only allows one name and one abbreviation. We probably need to allow more than one name/abbreviation for an organization (e.g. "MPI für Herz- und Lungenforschung" is identical to "W. G. Kerckhoff-Institut"). In addition, the language of the name is of importance.

Question 1: Should these multiple names be "property" of organizational unit (or part of institutions-authority files - all authority entry linked to the same orgunit ID and in addition include language tag?) -- Natasa

Assuming that "organizational units" are administrated more centrally by the participating institutes and the "institution authority file" is somehow created jointly by PubMan depositors, metadata editors and/or moderators I would vote to put

all official name variants (e.g. the Englisch translation, the abbreviation used on the web site) to the organizational units -> needs to be copied to the corresponding entries in authority file -> btw: org unit names in various languages might also be relevant for internationalization, i.e. if a user is in the German interface and chooses "Browse by affiliation" the German variant is used
further name alternatives (e.g. additional abbreviations like Fritz Haber Inst) to the authority file only --Inga

Question 2: Should the names displays be dependent on actual language of the user interface currently in use? -- Natasa

yes --Inga

Question 3: Should not we have one "default" name only as "official" i.e. the one officially "registered"? -- Natasa

I believe this fails. Institutes have more than on "official" title, but yes we should know which of the existing titles are the officials... --Inga

How do we know which names of the organizational units are "official"? Are there more than one "official" names?--Natasa 15:50, 23 October 2007 (CEST)

Question 4: Which attributes should be tagged by language?

To my understanding, only name and description are relevant for multiple language values --Ulla

What's about city, country, region (e.g. "Florenz", "Florence", "Firenze")? --Inga 15:57, 19 October 2007 (CEST)

Correct, but this probably means we have to decide on more "metadata records" for single organizational unit (each in separate language) as organizational unit descriptions, or simply as different objects with same PID? (probably has also something to do with rights/privileges?)--Natasa 15:52, 23 October 2007 (CEST)

external-id[edit]

[Robert:] the problem with the external-id property of org units is not only that the element is read-only. in its current form it's not useful. the idea - as explained to me by inga - was to have a way to relate external identifiers to escidoc org units. in particular, there may be more of them - e.g. an ovid id, an id in the IP database, ... and not only should the element be repeatable, but is must also contain the id-type information, the "ovid" or "ip database" thing in the example above. there was also a discussion whether a single name and abbreviation property of org units will suffice. from my experience, most mpis have at least two names and typically both in an english version, too.

external-ids should be independent on the language in which the organizational unit is described. --Natasa 15:55, 23 October 2007 (CEST)

Section information[edit]

[Natasa]:

As we have a requirement on having section information for the MPG organizational units for the purpose of the OA statistics on eDoc - this should also be taken into consideration for the Organizational units within the eSciDoc.

One should clearly specify if we would like to maintain the section information as special type of organizational unit or it should be a "tag" i.e. classification on the organizational units.

We should also have in mind that different societies will have different requirements regarding typization or tagging (or name it multiple classifications) on the organizational units.

It would be good to have also Margit on board regarding functional decisions on this topic.

Possible standards[edit]

Does OASIS draft spec make any sense?

Pilot Feedback on Organizational Units/Affiliations[edit]

Overall remarks[edit]

Approval of the basic concept on Affiliations/Organizational Units: as far as both the context of origin and the further administration/ grouping of data (context of responsibility) are concerned.

Views/Entry points (Sichten/Einstiegspunkte)[edit]

Approval of the idea of different views on data by institute/department/group -> has been explicitly articulated as a necessity, independently from the presentation.

It would be useful if the user had one-click access to all data of an institute he has privileges.

It should be guaranteed that there are more than one entry points at the same time.

Entry point: the functional aspect (direct access to the data pool of the corresponding Organizational Unit) should be addressed early as they are a marketing aspect (Logo, URL, Colouring etc.)

Handling[edit]

The cration and representation of Hierarchies is required.

If a person has more affiliations, it should also be identifiable by only one affiliation inside each metadata set.

(Eine Person gehört zu mehreren Affiliations, muss aber auch in einem Datensatz auch nur mit einer Affiliation ausweisbar sein.)

It should be possible to include -or leave out- predecessors or successors while searching or browsing.

(Bei Suche und Browsing sollte es möglich sein, Vorgänger und Nachfolger miteinzubeziehen oder auch wegzulassen.)

MPG- Scientists can be in two affiliations at a time. Question: should this be depicted in the system?

(MPG-Wissenschaftler können in zwei Affiliations gleichzeitig sein. Frage: muss das im System abgebildet werden?)

Clarification: If two MPG Affiliations have been merged, it should be possible, while entering the authors, during submission, to indicate, to which of the old affiliations the author had belonged.

(Klärung: Bei der Eingabe der Autoren muss es möglich sein, dass nach einer Verschmelzung von zwei MPG/Affiliations bei der Submission angegeben werden kann, zu welcher der alten Affiliations der Autor gehört hat.)

In some cases, the date of the merging is important, so that eventual queries have a point / Identity of names before and after the merging.

( In bestimmten Fällen ist das Datum der Verschmelzung wichtig, um sinnvolle Anfragen stellen zu können / Namensgleichheit vor und nach der Verschmelzung.)

How are name changes of persons to be handled?

(Wie werden Namensänderungen von Personen behandelt?)

Research Schools can either be handled like "normal" Top Level Affiliations or IMPRS could be the Top Level Affiliation and the individual Schools its subordinates. It is further possible that members of the Research School are also located in other positions in institutes.

(Research Schools können wie eine “normale” Top Level Affliliation behandelt werden oder IMPRS als Top level Affiliation und die einzelnen Schools als untergeordnete Affiliations. Es kann auch sein, dass die Mitglieder der Research School an anderen Stellen in Instituten angesiedelt sind)

Connecting persons and affiliations is important. Idea: after an affiliation has been entered for the first author, it should be set as default for all remaining authors.

(Verknüpfung von Personen und Affiliation wichtig. Idee: nach der Auswahl der Affiliation für den ersten Autor sollte diese defaultmäßig für alle weiteren Autoren voreingestellt sein.)

Affiliations must have controlled vocabulary.

(Affiliation muß kontrolliertes Vokabular sein .)

The structure of affiliations (hierarchy-tree) should be able to be displayed for account users/external users, to get better understanding of organization of institute. additionally, the hierarchy tree should include information on history of changes/modifications of institute organisation, which can be displayed on demand.