Page MenuHomePhabricator

DataStorage/Relationship clean up/refactoring
Open, NormalPublic


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.

Event Timeline

floca created this task.Nov 17 2017, 11:56 AM
floca updated the task description. (Show Details)Nov 17 2017, 12:05 PM
floca claimed this task.Nov 17 2017, 4:21 PM
floca updated the task description. (Show Details)Nov 17 2017, 5:20 PM

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 updated the task description. (Show Details)Nov 20 2017, 11:16 AM