Page MenuHomePhabricator

Should we persiste the ID of Identifiable when loading/saving BaseDatas?
Closed, ResolvedPublic


Implementing Identifable interface BaseData derived classes have now a UID one can query. Currently the UID is not persisted and therefor more something like a runtime UID. So the same image loaded twice has currently different UID; also loading the same image in two different sessions will not have the same UID. Thus the UID is not persistent and able to serve as persitent reference.

I am open for any decission, but I think we should explicitly decide and document it. So the question is

Should UID of Identifiable should be a persitant information?

Or do we even want need 2 UID types. One realy unique (like the pointer) and one persistant (and there for closer to content ID).

Some thoughts about pro and cons:

  • Yes: Would be comfortable in several situation.
  • Yes: Would allow to make GenericIDPropertyRelationRule also able to establish persitent relations. Currently we cannot persist the ID layer of the relation for obvious reason.
  • No: We cannot cover this feature directly in DICOM (in future one important output format). We would have to introduce a mitk privat tag for the UID. Do we want that? Have problem with that?
  • No: It comes closer to a content ID. There are reasons to offer that, but wouldn't it be better to do a real content ID as functional result (hash value) of the content itself? (even though that might be much harder...). May be we need both, because there are use cases where you realy want to identify the instance at runtime.

Revisions and Commits

Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision

Event Timeline

floca triaged this task as High priority.Jul 27 2018, 10:24 AM
floca added subscribers: kislinsk, nolden.

I think we should calrify this, before the release! (and therefore before it gets official)

We discussed it today with the following results.

  1. What does the UID stand for/what is its scope?
    1. It is unique in its creation, but it is not a content specific unique ID. Therfore:
      1. A class instance, associated with a UID, may change its values over its lifetime, but still have the same UID.
      2. If a class instance gets persistet and loaded multiple times, then theire could be several instances with the same UID.
    2. UID are therefore more simelar to git paths than to git hashes. It identifies something, but the state of something can change (stream of commits).
    3. It is up to the application that builds upon that feature to ensure appropriate usage within the application scope.
  2. It is not a feature of mitk::Identifiable per se to be persistable. It depends on classes that derive from mitk::Identifiable, if and who they implement a persistancy mechanism for their MITK UID.
  3. The derivations of mitk::BaseData (which implements mitk::Identifiable) should persist the UID, if possible (with the limitations described above).
    1. Current candidates (i.a.)
      1. mitk::Image
        1. via mitkItkImageIO it should be persisted into the metainformation key "org.mitk.uid"
        2. DICOM: if there is no appropriate tag, we have to store it in an private tag.
      2. mitk::MatchPointRegistrationWrapper
        1. store it also as "org.mitk.uid" and modify the IO
  4. The documentation should be more elaborate on that matter. 1-2 should be added to the documentation of Identifiable. 3 Should be added to the respective class documentation.
NOTE: We do not push for the current release because the upcoming changes would mean no regression or "downgrading" change in the interface.
NOTE: A reale content based ID should be achived by further pushing internal DICOM conformance and giving all data (images etc.) instance UID(s) when creating/generating them. See also T23746: MITK and DICOM (realization) and T24303: A segmentation should generate all DICOM relevant IDs as soon as it can be referenced..
floca added a parent task: Restricted Maniphest Task.Oct 29 2018, 12:42 PM
floca added a revision: Restricted Differential Revision.Jun 1 2020, 11:28 AM