Talk:PubMan PID

Functionallity conclusion for dicussion in concerning to Bugzilla issue

The framework supports Persistent Identifier (PID):

1. The PID references the whole object (Object PID).
   This is the counterpart to the Floating Object Reference.
2. The PID references a defined version of an object (Version PID).
   The reference counterpart is the Fixed Object Reference.

and three ways to assign it to an resource.

1. The PID to a resource exists before an item/container will be created. This way is useful to import an existing collection in the framework but not to assign a PID to an existing framework resource. This PID represents the Object PID.

   Write the PID in the property section of the object and call the create() method. The following XML snippet is an example of a resource which creates an item with existing PID.

   <?xml version=”1.0” encoding=”UTF-8”>
   <item:item xmlns.item=…>
      <item:properties>
           …
           <item:pid>persistent identifier</item:pid>
           …
      </item:properties>
      …
   </item:item>
   

   The necessary updates of resolver (to announce the new URL of the resource) must be completed by method caller (Solution or user).

2. Assign an Object PID by calling assignObjectPid(). This method creates and registers a PID to the provided resource URL in the corresponding PID system and assigns it to the resource. The registered resource URL corresponds to the Floating Object Reference.

   The current implementation allows this assignment process only if the object has reached the public-status "released". This should avoid dangling PID-resource-pointer to non-accessible objects. A PID assignment leads not to a new version of resource.

3. Assign a Version PID by calling assignVersionPid().
   This method creates and registers a PID to a resource URL which identifies a certain resource version.

   This assignment process is only allowed on resource versions in public-status "released" and leads not to a new version of resource.

In response to Issue #316 is a decision concerning to the role policies expected

With the current roles an author is forbidden to alter a resource after it has reached public-status "released". This means that, without new role definition, the System Administrator has to call the assignment methods (for Version/Object PID).

Probably this is the wrong understanding of the versioning concept provided by MPDL for PubMan. For items: every item can be modified after it is released, also by the author. In fact, the author by this modification creates a new (pending) version of the item. An Item can have any number of versions after it has been first time released. The restriction in this case is that the versions must follow the pending->submitted->released status i.e. there can not be "branches" in the item life-cycle --Natasa 11:49, 11 October 2007 (CEST)

Proposals to solve this restriction:

1. Introducing new task access definitions for the resource PID assignment methods (see Concept for Authentication and Authorization).
   Which roles are necessary? Who can assign PIDs? Is "everybody who has the right to release an item should also have the right to assign a PID" completely?

2. The public-status restriction could be changed to avoid new task access definitions.

   A resource needs not be even more in public-status "released" before a PID could be assigned. A resource has to assign now with PID before the object has reached public-status "released".

   This avoids the introducing of new administrative rules. A later PID assignment, after resource has reached public-status “released”, is impossible.

   In case of version PIDs this lead to a new issue: A version of resource with a PID could not ever reach the public-status "released". Now have a lot of non-released versions a PID - a lot of PIDs with restricted resource access.

   E.g. version 2 seams to be ready for release and will be assigned with a version PID. Resource changes lead to three new versions. For version 5, which is now really ready to release, a new PID is to assign.
   This procedure can lead to a set of versions where a few versions are related with PIDs (in most cases wear the uninteresting versions PIDs).

3. Introduce new task definitions to allow assignment after public-status "released" and remove other public-status restrictions (combination of proposal 1 and 2).

To sum up, a new task access definition is necessary. How should the methods restricted? Should we change the public-status restriction concept too?

Issue 316: feedback

As the reason to extract the PID assignment from the "release" task of the item was to actually free the PID assignment to be invoked either via item creation, item update or item release (actions from solution point of view).

• create item with existing PID - everybody with create rights on the resource should be able to define the PID (object or version) of the item (one of the cases described above, where PID for the item already exists before the item is created in the repository; mapping of the resolution is separate task.)
• update item with existing PID - everybody with the update rights on the resource should be able to define the PID (object or version) of the item in following manner by invoking update method and associating PID value - same use case as above
• assign ObjectPID - everybody with the update rights on the resource version (note: not typo, update rights are dependent on last version rights in the solution) should be able to do this
  • Only updates of the latest version are allowed (this is true for every resource). Therefore we can confert everybody with the update rights on the resource version INTO everybody with the update rights on the resource. No specific version is specified to call assingObjectPID. Frank 12:00, 7 December 2007 (CET)

Frank, probably this will not work (valid for same remarks below as well): if the user is "depositor" he can update only if the version is in status "pending" and not if the version is in status "submitted" - so this was the reason I used the wording "version". Not certain if you took this in consideration or not --Natasa 17:01, 10 December 2007 (CET)

Didn't see that. But: There are update rights for "depositor" defined and that definition uses some properties of the resource -- irrelevant if that properties belongs to the latest version or the entire object. I didn't get the difference between somebody is allowed to update the latest version and somebody is allowed to update the object.

For assign VersionPID I can see the difference. You want to allow the assignment to a specific version depending on properties of that version (like somebody is allowed to see/retrieve released version). But update rights on an older version didn't make sense to me; possibly we should simply speak about the right to assign a version pid. Though, technically it is possible to define update rights version specific and declare the assignement of pid as update. And all calls to an update method with an old version number in the parameter are blocked by the businesslogic except calls to assignVersionPid. Frank 17:47, 10 December 2007 (CET)

Older versions can not be updated directly - i.e. there is no "branching" in any case. Only the last version can be updated - and how it can be updated it depends on the privileges of the user. We distinguish between version pid and object pid in the following: each version of the object can have a different PID. If the PID should be object PID - then the PID should be for all versions of that object from the moment the PID is assigned (i.e. user by default always resolves to the last version he can see with that PID).

My proposal is - as we now have clarified the problems and probably we have common understanding of them - that is very easy to be resolved on the WS (including some sketches on the board :) --Natasa 18:24, 10 December 2007 (CET)

Obviously we have a slightly different understanding of object pid. In my opinion, object pid refers to the entire object (which usually is represented with the latest version of the object) and not to every single version. Also, there i see the reason to use both, version and object pid. Frank 09:40, 11 December 2007 (CET)

Did we mean the same with "an object pid should be for all versions of that object from the moment the pid is assigned"? I think, regardless in which version the object pid is assigned it is stated with the representation of the first version, too!? Frank 09:40, 11 December 2007 (CET)

(puh! :) not easy to answer)... Technically - it is always a version pid - and with respect to that you are right. Logically, the OBJECT PID (which is assigned to e.g. version 3) is automatically same also for version 4, version 5 etc. If we talk on VERSION PID it is different for version 3, version 6, version 7 etc.(note: not all versions must have a PID associated). The resolution via PID in case of OBJECT PID always comes to the last version of the object, the resolution via PID in case of VERSION PID always comes to the exact version of the object to which that PID is assigned. (not for here, but in this case we also have issues with the search - but i will try to make a clarification later on this issue, as not certain myself). --Natasa 11:01, 11 December 2007 (CET)

• assign VersionPID - everybody with the update rights on the resource version should be able to do this
  • Only updates of the latest version are allowed. Therefore we can confert everybody with the update rights on the resource version INTO everybody with the update rights on the resource AND assigning version PIDs is only possible for latest versions. Frank 12:00, 7 December 2007 (CET)

--Natasa 11:52, 11 October 2007 (CEST)

ObjectPIDs and VersionPIDs

--Natasa 11:50, 11 October 2007 (CEST) We should understand the actual difference from functional aspects. Isn't this something that should be part of the ContentModel actually?

• It depends on the ContentModel what is the PID rule for versions - we assign a PID either to a version or to an object (independent on how many versions there are for this object). What would be the point (gain) that an object has both PIDs?

i.e. I would hardly assume that we will have e.g. PubItems, SWB Collections, FacesItems that will need to have both at the same time.

• In older logical data model documents we've had this question, and PID assignment method is actually part of the CModel definition: for all items of certain content type we decide actually if we associate version PID or object PID.

Persistent Identifer or Identification

Extensible Markup Language

Unicode Transformation Format

Uniform Resource Locator

Max Planck Digital Library

Publication Management

Central European Summer Time

Central European Time

Scholary Workbench