Change Details

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.

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.

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.