Page MenuHomePhabricator

DataStorage/Relationship clean up/refactoring
Closed, ResolvedPublic

Description

In this meta task everything is grouped that we have defined as tasks or found as concrete open questions in the context of our DataStorage, DataNodes, and Relations.

Following key findings and observiation where made and where motivators for the sub tasks:

  • Role/difference of properties in DataNodes and BaseData become blurry (e.g. DICOM color information is important for rendering but also an rendering relevant information)
  • We can specify relations in the storage, but there are one limited to one type of relation ("parent<->child"). You can not define different types of relations.
  • What is with data relevant relations?
  • What is the role of the DataNode? (especially, if we have data relevant relations)

After the discussion we decided to go for a PropertyRelation service approach. This allows relations without a) having the conflict of relations that are data relevant but modeled in the node or b) having to do a very big refactoring which needs a lot more discussion and work. b) may come but till then it is a proper interim solution.

The following use cases / aims should be solved/possible with the implementation of the service and the other sub taks:

  1. [technical] Create the possibility to have an abstracted interface to define and query relations in the data.
  2. [technical] Standardization/abstraction/encapsulation of rules and business logic to detect and define (property/data based) releations.
  3. Allow views on the data storage that represent arbitrary application defined types of relations. (something like the Patient View plugin (T19850) on steriods ;)
  4. Assure that DICOM relevant relations are correctly resempled in the properties of the data and that the way/"relation encoding style" is standardized in MITK. (e.g. How encodes MITK in DICOM tags that an image is a source image or a mask or an AIF image for perfusion fits...; this is a.o. important for the perfusion and registration domaine)
  5. Support for ontologies (e.g. Semantic relations or registration ontologie) to deduce more easily the ABox out of the data storage content.

Related Objects

StatusAssignedTask
Resolvedfloca
Resolvedfloca
Resolvedkislinsk
Resolvedkislinsk
Resolvedkislinsk
DuplicateNone
Resolvedkislinsk
Resolvedfloca
Resolvedfloca
OpenNone
Resolvedkalali
Resolvedfloca
Resolvedfloca
Resolvedfloca
Resolvedfloca
Resolvedfloca
Resolvedkislinsk
Resolvedkislinsk
Resolvedkislinsk
Resolvedfloca
Resolvedkislinsk
Resolvedfloca
OpenNone
Resolvedfloca
Resolvedkalali

Event Timeline

I added you on that level, because:

  1. I think for a review it is important to have the whole picture.
  2. I added more explicitely the aims, so what we (should) gain by the new PropertyRelations stuff (service and and its class "eco system").
  3. I will also refine of the existing tasks today, because I found missing aspects and rethought the concept.
floca removed floca as the assignee of this task.Feb 25 2020, 5:22 PM
floca claimed this task.