Suggested RIG changes for 2026

[mbrush]

This Discussion hosts any input or questions regarding how we might improve RIG schema and conventions. e.g. properties to drop or add, requirement levels to change, improvements to templates or schema docs, etc.

[mbrush]

A few ideas from me:

• Define a process and modeling to support ingest owner-assigned 'prior confidence scores' for each edge type
• Coordinated schema / data collection expansions to support useful retrieval provenance #335 (proposed extensions to RIG schema and conventions for data collection)

[mbrush]

Make an explicit connection between Edge Types specifications in RIGs and edges in the data/KGs

• Approach:

  • Assign an edge type id in the RIG, and capture this on instances of all edges in the data/KGs.

• Value/Rationale:

  • Helps with QA - reviewer can find spec for each edge type in summary reports - to check conformance. Hard to do now in many cases - esp sources with many edge types / ingested files
  • Lets us assign and attach EdgeType-level info to edges (in the data or the UI)
    • ui_explanations: makes sense to author these in RIGs where Edge types are defined and evaluated - but these need to be propagated to specific edge instances (in the UI)
    • prior_confidence_scores: we want to use DINGO modeler/ingestor expertise about sources/edge types as one input into confidence scoring. Makes sense to capture this at level of RIG as well

• Example:

# In the RIG:
  target_info:
    infores_id:  infores:translator-ctd
    edge_type_info:
      - edge_type_id: ctd_012                # Edge type id in the RIG
      - subject_categories:
          - biolink:ChemicalEntity
        predicates:
          - biolink:associated_with
        object_categories:
          - biolink:BiologicalProcessOrActivity
          - biolink:MolecularActivity
          - biolink:CellularComponent
        knowledge_level:
          - statistical_association
        agent_type:
          - data_analysis_pipeline
        primary_knowledge_sources:
          - infores:ctd
        edge_properties:
          - biolink:adjusted_p_value
          - biolink:p_value
        ui_explanation: "Source CTD data are based on an enrichment analysis of Gene Ontology (GO) terms annotated to all genes that interact with a particular chemical - to derive Chemical-GO Term associations. This analysis is performed by a CTD automated analysis pipeline. The CTD record used to create this Translator edge reports an overrepresented GO term associated with a particular chemical - as indicated by a sufficiently low p-value from the analysis. This hints but does not directly demonstrate that the chemical may impact the process, activity, or cellular component the GO term represents. The indirect, statistical basis of this relationship is best represented using the 'associated_with' predicate in Biolink."
        source_files:
          - CTD_chem_go_enriched.tsv
        prior_confidence_score:  0.6
        confidence_explanation: Naive prior of 0.8 for statistical associations reduced to 0.6 due primarily to the indirect nature of evidence for the reported association - i.e.  not based on data about the subject and object concepts, but based on the frequency/specificity of their shared Gene associations. This suggests that a biologically meaningful relationship may exist, but is not based on evidence that directly tests this. Note that if we defined/used a more specific predicate here (e.g. shares_go_annotaitons_with), then our confidence prior would remain high (possibly even increase - because of the simplicity of the statement and the soundness of the method).
        additional_notes:   

# An edge of this type in the data:
{
  "id": "urn:uuid:2ba4d195-fecd-413f-8185-bd53b2df0675",
  "category": [
    "biolink:ChemicalEntityToBiologicalProcessAssociation"
  ],
  "subject": "UMLS:C0002241",
  "predicate": "biolink:affects",
  "object": "GO:0004021",
  "publications": [
    "PMID:40379039"
  ],
  "sources": [
    {
      "id": "urn:uuid:d3784c82-15f5-4a8a-a1e8-3ecb9f6a5240",
      "category": [
        "biolink:RetrievalSource"
      ],
      "resource_id": "infores:ctd",
      "resource_role": "primary_knowledge_source"
    }
  ],
  "knowledge_level": "knowledge_assertion",
  "agent_type": "manual_agent",
  "species_context_qualifier": "NCBITaxon:10090",
  "anatomical_context_qualifier": [
    "MESH:D044967"
  ],
  "qualified_predicate": "biolink:causes",
  "object_direction_qualifier": "increased",
  "original_subject": "MESH:D053959",
  "original_object": "GO:0004021"
  "edge_type_id": "ctd:012"             # Edge Type ID link in an edge instance
}

• Questions:
  • Is this approach feasible (can ingest code map form RIG edge types to the edges it creates)

[colleenXu]

Overall:

• Make additional_notes a list of strings (currently 1 string). I sometimes have long blocks with lists (drugcentral, dgidb)

Source_info:

• Tighten up schema? Recall some feedback from DAWG saying value-types were sometimes very diff between RIGs (citations, data_access_locations fields not being just urls?)

Ingest info:

• file fields: I've put database tables here, not files (drugcentral). Add notes to template/schema saying this is okay, or change field names?
• Make included_content optional, and must include at least 1 of included_content / filtered_content. I'm often putting info in the "included" section that better fits/is repetitive with the "filtered" section (dgidb, drugcentral, G2P, TTD).
• included_content / filtered_content should only cover the ingest code in the folder, not anything done downstream (ex: filtering doesn't need to note that we also filter out stuff during NodeNorming)

Target_info:

• Only include edge_properties / node_properties added by ingest code in the folder, not anything added downstream by pipeline (ex: NodeNorming adds original sub/obj to edge, node attrib)