Talk:PubMan Func Spec Organizational Unit Management

UC_PM_OUM_01 Create organizational unit

The user creates a new organizational unit and specifies the position in the organizational unit structure.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to create a new organizational unit.

Actors

• Service Administrator

Pre-Conditions

• None

Flow of Events

• 1. The user chooses to create an organizational unit.
• 2. The system displays an organizational unit details view.
• 3. The user enters the data for the new organizational unit.
• 4. (Optionally) The user selects one or more parent organizational units in the organizational unit structure.
• 5. The user confirms the creation.
• 6. The system checks if an organizational unit with the given name already exists under the same parent.
  • a. An organizational unit with the given name does not exist under the same parent.
  • b. Otherwise the system displays an error message (MSG_PM_OUM_01), continue with 3.
• 7. The system creates and stores a new organizational unit in state “open” and the relations to the parent organizational units. The system displays a success message (MSG_PM_OUM_02). The use case ends successfully.

Post-Conditions / Results

• The new organizational unit in the state “open” is created.

UC_PM_OUM_02 Edit organizational unit

The user changes data of an organizational unit.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to edit the data of an organizational unit.

Actors

• Service Administrator

Pre-Conditions

• An organizational unit is selected.
• See General rules for assignment of children and/or parents.

Flow of Events

• 1. The user chooses to edit the selected organizational unit.
• 2. The system displays the details of the selected organizational unit in an edit view.
• 3. (Optionally) The user changes the data for the organizational unit. See General rules
• 4. (Optionally) The user changes the parent organizational units. See General rules
• 5. The user confirms the changes.
• 6. The system checks if an organizational unit with the given name already exists under the same parent.
  • a. An organizational unit with the given name does not exist under the same parent.
  • b. Otherwise the system displays an error message (MSG_PM_OUM_01), continue with 3.

7. The system stores the changes and displays a success message (MSG_PM_OUM_02). The use case ends successfully.

Post-Conditions / Results

• The changed organizational unit is stored.

UC_PM_OUM_03 Close organizational unit

The user closes an organizational unit.

Status/Schedule

• Status: in specification
• Schedule:to be defined

UC_PM_OUM_04 Delete organizational unit

The user deletes an organizational unit.

Status/Schedule

• Status: implemented
• Schedule: R3

Triggers

• The user wants to delete an organizational unit.

Actors

• Service Administrator

Pre-Conditions

• The selected organizational unit is in state "created"
• No children of the selected organizational unit exist.

Flow of Events

• 1. The user chooses to delete an organizational unit.
• 2. The system displays an organizational unit details view.
• 3. The user deletes the organizational unit.
• 4. The system deletes the selected organizational unit. The use case ends successfully.

Post-Conditions / Results

• The organizational unit is deleted.

Future Development

• It should be possible to change the order of the organizational units. Currently the org. units are displayed in the org. unit browsing tree displayed in the order they were entered via the admin interfaces.
• Prepare consequences for editing organisational units (Indexes, searches, browsing)
• Prepare use cases/scenarios for "tracking history of org units" (ie. merging, closing etc.)
  • Scenario for defining "context of origin" of a publication => consider to de-couple the assignment of context of origin from history information on OU referenced by Controlled Vocab
    • assign a closed organisational units to a publication
    • assign pre-decessor to a publication (i.e. publication is published after org unit has merged into another one)
  • Scenario for defining org units as "context of responsibility" for a collection/context
  • Scenario for users assigned to org units
    • a)if org unit is closed, move user to successor org unit or parent org unit?
    • b) if org unit is closed, de-activate user account?

General rules

• assign parent to an organizational unit in status "created"
  • parent must be in status "opened" or "created"

• assign parent to an organizational unit in status "opened"
  • not allowed

• assign parent to an organizational unit in status "closed"
  • not allowed

• assign children to an organizational unit in status "created"
  • children must be in status "created"

• assign children to an organizational unit in status "closed"
  • not allowed

• assign children to an organizational unit in status "opened"
  • children must be in status "created"

• remove parent from an organizational unit in status "created"
  • organizational unit must be in status "created"

• remove parent from an organizational unit in status "opened" or "closed"
  • not allowed

• remove children
  • (is not directly supported, it is executed via remove parent for child organizations, therefore above rules apply)

• open organizational unit
  • if parents exist, parents must be in status "opened"
  • if children exist, no effects to children

• close organizational unit
  • if children in status "opened" the operation should not be allowed (or previously should be assigned to a new parent by the client solution)
  • if children in status "created" exist the operation should not be allowed (client solution should decide what it needs to do with these children)
  • if children is status "closed" only exist the operation should be allowed

• delete organizational unit
  • can be deleted if in status "created" and if no children exist

Clarification of statuses:

• CREATED - organizational unit is created in the system, users have several possibilities to edit it, it is still not considered as a resource that can be used to relate it to other resources in the system (except in cases stated above, assign parents, assign children). In other words, new organizational units are visible only internally within the "Organizational unit handler" and the solution that manages organizational units.
• OPENED - organizational unit is valid it is used by the system, can be related to other resources in the system (i.e. to users, contexts BUT NOT TO NEW PARENTS etc)
• CLOSED - organizational unit is closed (it officially does not exist any longer, it is visible as in case of "OPENED" but it can not be related to "new resources" or new relations can not be created to existing resources).

Organizational Unit Handler

• Modification of existing methods:
  • create organizational unit should create org units with status "created"
  • method "delete" should be updated to allow deletion of organizational units only in case when they have no children and when they are in status "created"

• New methods:
  • method to "open" organizational unit is missing
  • method to "close" organizational unit is missing

• Additional issues: data consistency is not implemented properly at the moment, see CLARIFICATION for STATUSES above and examples below:
  • Organizational units can be associated with the Context only if OrgUnit status is "opened". A context object has organizational units related. When a context object is created only organizational units in status "opened" can be related as responsible for the context.--Natasa 10:23, 7 December 2007 (CET)
  • Organizational units can be associated with Users only if OrgUnit status is "opened". When a user is created a relation to an organizational unit from which this user comes from is also created. In this case organizational unit that is given during creation of a user must be in status "opened".
  • Organizational units can be deleted only if OrgUnit status is "created" and when there are no children in status other then "created". --Natasa 10:23, 7 December 2007 (CET)

Metadata

• decision on the content of OrganizationalUnit is needed - Frank

Frank, can you provide short info what do you think with this, so we prepare smth in advance?

Clarified - MPDL will provide some more info, this is only refering to the organization-details section!--Natasa 11:54, 19 November 2007 (CET)

This may pertain the properties too if in the details is some candidate for a filter or a value that occures in both properties and details. Frank 15:21, 6 December 2007 (CET)

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> 

Changes in details section

(note: inclusion of language flags via dc: elements referenced and dc:simpleLiteral type reference):

   <xs:element name="organization-details">
       <xs:element ref="dc:title">
       <xs:element ref="dcterms:alternative" minOccurs=0>
       <xs:element ref="dc:identifier" type="xs:token" minOccurs="0" maxOccurs="unbounded"> 
       <xs:element name="organization-type" type="dc:simpleLiteral" minOccurs="0">
       <xs:element name="dc:description" minOccurs="0"> 
       <xs:element name="country" type="dc:simpleLiteral"> 
       <xs:element name="city" type="dc:simpleLiteral"> 
       <xs:element name="start-date" type="dcterms:W3CDTF" minOccurs="0"/>
       <xs:element name="end-date" type="dcterms:W3CDTF" minOccurs="0"/>
       <xs:element ref="georss:point"/> (should be taken from xmlns:georss="http://www.georss.org/" namespace)
   </xs:element> 

--Natasa 16:05, 10 December 2007 (CET)

i'd go for http://www.georss.org/ - i.e. <georss:point>45.256 -71.92</georss:point> for the coordinate. Robert 16:22, 10 December 2007 (CET)

OK, accepted and the details section changed. --Natasa 11:48, 11 December 2007 (CET)

• dc:alternative should be dcterms:alternative (http://purl.org/dc/terms/alternative)? Frank 12:35, 8 January 2008 (CET)

First Proposal

<organizational-unit:organizational-unit xmlns:organizational-unit="http://www.escidoc.de/schemas/organizationalunit/0.3"
            objid="escidoc:persistent13" last-modification-date="2008-01-07T16:46:23.656Z">
	<organizational-unit:properties>
		<organizational-unit:name>Max Planck Society</organizational-unit:name><!-- read-only, derived from metadata dc:title -->
		<organizational-unit:description>The Max Planck Society for the Advancement of Science is an independent, non-profit research
                                                 organization that primarily promotes and supports research at its own institutes.
                </organizational-unit:description><!-- read-only, derived from metadata dc:description -->
		<organizational-unit:creation-date>2007-03-22T08:23:35.562Z</organizational-unit:creation-date>
		<organizational-unit:created-by objid="escidoc:user42"/>
		<organizational-unit:modified-by objid="escidoc:user42"/>
		<organizational-unit:public-status>opened</organizational-unit:public-status>
		<organizational-unit:has-children>true</organizational-unit:has-children>
	</organizational-unit:properties>
	<md-records:md-records xmlns:md-records="http://www.escidoc.de/schemas/metadatarecords/0.3">
		<md-records:md-record name="escidoc">
			<ou:ou xmlns:ou="http://www.escidoc.de/metadata/organizational-unit" xmlns:dc="http://purl.org/dc/elements/1.1/" 
                                    xmlns:dcterms="http://purl.org/dc/terms/">
				<dc:title>Max Planck Society</dc:title>
				<dcterms:alternative>MPS</dcterms:alternative>
				<dc:description>The Max Planck Society for the Advancement of Science is an independent, non-profit research
                                     organization that primarily promotes and supports research at its own institutes.</dc:description>
				<!-- <organizational-unit:uri>http://www.mpg.de</organizational-unit:uri> -->
				<dc:identifier></dc:identifier>
				<ou:organization-type>institute</ou:organization-type>
				<ou:country>Germany</ou:country>
				<ou:city>Munich</ou:city>
				<!-- <organizational-unit:telephone>+49892108-0</organizational-unit:telephone>
				<organizational-unit:fax>+49892108-1111</organizational-unit:fax>
				<organizational-unit:email>presse@gv.mpg.de</organizational-unit:email> -->
				<ou:start-date>2007-03-22T08:23:35.562Z</ou:start-date>
				<ou:end-date>2009-03-22</ou:end-date>
				<georss:point xmlns:georss="http://www.georss.org/">45.256 -71.92</georss:point>
			</ou:ou>
		</md-records:md-record>
	</md-records:md-records>
        <organizational-unit:parent-ous><!-- objid of (or link to) if some --></organizational-unit:parent-ous>
</organizational-unit:organizational-unit>

Frank 17:56, 8 January 2008 (CET)

Use Case

Organizational Unit

Central European Time

Max Planck Digital Library

Max Planck Society