Uploaded image for project: 'PhenoTips'
  1. PT-2617

Change internal representation of pedigrees

    Details

      Description

      Change internal representation of pedigrees to follow the proposal @ https://phenotips.org/Design/REST_Family2:

      -----------------

      This issue implements the following version of Pedigree JSON:

      {
       "JSON_version": TEXT,
       "proband": ID, // optional
       "members": [ {"id":1, "properties": {...}}, {"id":2, "properties": {...}, "pedigreeProperties": {...}}, {"id":3}, ... ],  // required                                                                                                                     
                // each member may have an optional "properties" parameter (which has the same format as PT Patient JSON)
                // or/and "pedigreeProperties" parameter, which contains pedigree-specific data (which may change over time together with "JSON_version")
      
       "relationships": [     // is used to specify a relationship between two or more members (partners, parent(s)-child, siblings).
                               // Note: current pedigree implementation will always create a []--*--() figure in the pedigree
                               //           (even for two siblings, it will add new virtual parents - this should be improved in future versions)
            {
              "id": RID,                // needed for layout and long edges; only unique among relationships; not needed if there is no layout provided
      
              "members": [ ID1, ID2 ],  // at most 2 members are supported for now, these are the members which form the []--*--() part
                                        //children/siblings are specified in the "children" section
                                        // required: either 2 members (in a relationship) or one member + at least one child or no members and at least two children
      
              "properties": { "separated": true/false, "childlessStatus": "no"/"childless"/"infertile", "childlessReason": "text", "consanguinity": "yes"/"no"/"auto" (default) }, // optional
      
              "children": [                                                                                        // optional
                 {
                    "id": ID,                   // a child can only be listed in one relationship (unless "adopted in" in one and "adopted out" in another - unsupported for now)
                    "adopted": "no"/"in"/"out"  // default: "no"
                                                // (if one relationship has the child as "in" and another as "out" a path should be drawn from one family to the other, unsupported for now)
                 } 
              ]
            }, ...
       ],
      
       "layout": {  // optional
          "members":       { ID1 : {"generation": W, "order": Z, "x": X}, ID2: {...} }, ... ],    // generation is mandatory, order is optional
          "relationships": { RID1: {"order": Z, "x": X}, RID2: {...}, ... },
          "longedges":     { RID_A: { "member": ID, "path": [ {"order": Z, "x": X}, {...}, ...] }, RID_B: {...}, ... ]   // top to bottom, from the person to the relationship
        },
      
        "settings": { "colors": { ... },   // optional, used to keep abnormality colors consistent, enables support for custom abnormality names; also currently used by pedigree legend
                      "names": { ... }     //           may be discarded in one of the future versions
        }
      }
      
      - note:"properties" should be in the same format as PhenoTips patient JSON except that nodes not linked to PhenoTips patients should not/will not have an {{code}}"id"{{/code}} field defined there
      - implementation note: if at any point layout disagrees with pedigree, layout is scrapped and pedigree is re-laid-out
      - only "members" field is mandatory, however since pedigree should be a connected component if there is more than one member there must be a corresponding link in the "relationships".
      
      

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                asm Andriy Misyura
                Reporter:
                sasha Sasha Andjic
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: