Retrieval Provenance Refactor Proposal Voting

[mbrush]

Thread to discuss / decide on an approach for refactoring the 'source retrieval provenance' model to be more expressive - specifically to represent an ordered tree of retrievals that may result from edge merging operations, where it is clear which source was primary/original, and which were aggregators.

Three proposals are outlined in separate comments below, for discussion and voting. Details and links to artifacts for each proposal are in the original ticket #369.

Voting Scheme:
+2 Highest (heart) - Love it
+1 High (thumb up) - Like it
0 Medium (none) - Meh
-1 Low Priority (thumb down) - We should not do this

[mbrush]

Candidate A: Use the existing Attribute structure, with nesting to capture 'previous_sources' for each aggregator knowledge source. Overview, Data Examples.

{
  "edges": {
    "id": "e719491"
    "subject": "RXCUI:1544384",
    "predicate": "biolink:correlated_with",
    "object": "MONDO:0008383",
    "attributes": [
      {                                        
        "attribute_type_id": "primary_knowledge_source",                  
        "value": "infores:KS_1",
        "value_type_id": "biolink:InformationResource",
        "attribute_source": ["infores:KP_1","infores:KP_2", "infores:KP_3"]
      },
      {                                        
        "attribute_type_id": "aggregator_knowledge_source",                  
        "value": "infores:KP_1",
        "value_type_id": "biolink:InformationResource",
        "attribute_source": ["infores:KP_1"]
        "attributes": [
           {
             "attribute_type_id": "previous_knowledge_source",
             "value": "infores:KS_1",
             "value_type_id": "biolink:InformationResource",
             "attribute_source": ["infores:KP_1"]
           }
         ]
      },   

Pros:

• no changes needed to TRAPI schema - just a policy doc that guides data creators in how to use Attributes to capture this information.
• if we wanted to capture more details about each retrieval operation (who did it, when, how) this would be possible by creating another level of nested Attributes.

Cons:

• retrieval provenance attributes are mixed in with the many other types of edge metadata found in attributes.
• edge merging code has to look inside nested objects to parse out what is needed for the edge merging use case . . . possible, but computationally more expensive than Candidate B.

[ehinderer]

Seems like a more comprehensive solution, but how much nesting will be allowed? Could be difficult to parse, if we're wanting to order and organize edges by specific EPC attributes.

[mbrush]

Candidate B: Defining a dedicated structure for representing source retrieval provenance.
Overview, Data Examples.

 {
  "edges": {
    "id": "e719491"
    "subject": "RXCUI:1544384",
    "predicate": "biolink:correlated_with",
    "object": "MONDO:0008383",
    "sources": [
      {
      "type": biolink:RetrievalSource,
      "resource": "infores:KS_1",
      "resource_role": "primary knowledge source",
      },
      {                                        
      "type": biolink:RetrievalSource
      "resource": "infores:KP_1",
      "resource_role": "aggregator knowledge source",
      "previous_resource": ["infores:KS_1"]      
      },
      {                                        
      "type": biolink:RetrievalSource,
      "resource": "infores:KP_2",
      "resource_role": "aggregator knowledge source",
      "previous_resource": ["infores:KS_1"]
      },
      {                                        
      "type": biolink:RetrievalSource,
      "resource": "infores:ARA_1",
      "resource_role": "aggregator knowledge source",
      "previous_resource": ["infores:KP_1", "infores:KP_2"]
      },

Pros:

• retrieval provenance info is clearly separated from the many other types of edge metadata found in attributes
• this info is not as deeply nested - making it easier to find/parse for edge merging and other use cases.

Cons:

• requires schema changes (add a sources edge property, and create a Source class)
• supporting possible use case for capturing more details about each retrieval operation would require additional schema changes/refactoring.

[mbrush]

Candidate A.1: Use Attributes exactly as in Candidate A, but create a new edge property to hold Attribute objects that describe retrieval provenance metadata (e.g. retrieval_attributes, which would sit alongside the more general attributes property).

{
  "edges": {
    "id": "e719491"
    "subject": "RXCUI:1544384",
    "predicate": "biolink:correlated_with",
    "object": "MONDO:0008383",
    "attributes": [ ],
    "retrieval_attributes": [
      {                                        
        "attribute_type_id": "primary_knowledge_source",                  
        "value": "infores:KS_1",
        "value_type_id": "biolink:InformationResource",
        "attribute_source": ["infores:KP_1","infores:KP_2", "infores:KP_3"]
      },
      {                                        
        "attribute_type_id": "aggregator_knowledge_source",                  
        "value": "infores:KP_1",
        "value_type_id": "biolink:InformationResource",
        "attribute_source": ["infores:KP_1"]
        "attributes": [
           {
             "attribute_type_id": "previous_knowledge_source",
             "value": "infores:KS_1",
             "value_type_id": "biolink:InformationResource",
             "attribute_source": ["infores:KP_1"]
           }
         ]
      },   
...   

Pros: all of the pros for Candidate A, plus it does make parsing the data for edge merging a little easier/more efficient.

Cons: all the cons of Candidate A, plus there is a small schema change required (adding one new edge property)

[ehinderer]

Nice to have the separation of source retrieval from other EPC attributes (like p-value, log_ratio, etc.). However, if someone wanted to ask "where did this p-value come from?" it would be clumsy to make the connection.

[mbrush]

To be clear, we are NOT proposing to organize all other EPC info (e.g. p-value, log_ratio, etc.) that may be provided by a given source in Attribute objects nested under the Attribute that tells us about that source.

e.g. If Chembl is the original source of an 'X interacts with Y' Edge, and it provides an IC50 value as evidence - the Attribute holding this IC50 value would NOT be nested under the Attribute telling us that Chembl is the primary source of the Edge.

Rather, the Attribute holding the IC50 value would be a top level Attribute object, and the attribute_source property within this object would tell us that Chembl provided it.

Given this, to me it makes sense to structurally separate in some way 'retrieval provenance' metadata, from other types of EPC - since we are considering these as separate kinds of provenance and don't need to make direct connections between Attirbutes holding them.