Create Edge-Type Attribute File

[callahantiff]

Task

Add an output file to accompany the node metadata created for each build that provides users with an easy way to identify what type each triple is.

Design

The file should at a minimum contain the following information:

• Triple Identifier: Ideally, this file would either take the subject, object, and predicate of each triple as an identifier or preferably, we would index each triple with an integer identifier that would align to the integer-based edge lists (for n-triple files we can create this as a named graph).
• Edge Type: String label recording edge type, current types are shown here
• Pattern: Relation type information like symmetry, transitivity, composition, inversion
• Category: Relation type information like N:1, 1:N, 1:1
• Weight1: Values that can be used as an edge weight. Will consider including multiple types of weight, if available, some of which could be derived from the evidence used in the original source when the edge was created
• Weight1_Type: String that specifies the type for Weight1

Additional information related to the edge could also be added, but it's unclear at this time what would be useful.

[callahantiff]

Per discussion with @LucaCappelletti94 - create two separate tsv files:

• Node Data: contains node identifiers and node type. For nodes with multiple types, separate each type label with a |
• Edge Data: contains columns for source and destination node identifiers, edge weight, and edge type. For edges with multiple types, separate each type label with a |. Example: relation:edge type | relation:edge type

Will let you know as soon as this is ready @LucaCappelletti94!

[LucaCappelletti94]

One more thing: if you have, generally speaking, node features and edge features, as in either other categorical or metric ones, even stuff like the BED coordinates if some are genomic regions, they can be useful when running GNN and GCN models on the graph.

[callahantiff]

Great suggestion @LucaCappelletti94! One thought that immediately comes to mind is gene expression values (for specific tissues) we can definitely add that. I'll think through what else might make a good edge type.

Sometimes the distinction between what should be used as a weight or type gets blurred. However, if we were to first mark everything that may be interesting/useful as an edge type (i.e., all categorical and metric-based), then we would also allow the user the ability to select from those what they wanted to use an edge based on their use case. I like this idea a lot!

[felipemello1]

Hi, if you dont mind me sharing my two cents. In the data PheKnowLator_v2.1.0_full_subclass_relationsOnly_OWLNETS_SUBCLASS_purified_Triples_Identifiers.txt there are 291 unique edge_types. Are all of these edge_types in the dataset?

Also, in DisGeNet, for example, the edges between DIS-GENE can have multiple labels, which completely changes the meaning between their interaction. Would it be possible to add the edge subtypes? https://www.disgenet.org/dbinfo paragraph The DisGeNET Association Type Ontology

In PheKnowLator's data sources description, it doesnt seem that any particular type of edge was filtered/selected: https://github.com/callahantiff/PheKnowLator/wiki/v2-Data-Sources#disgenet

For Protein-Protein from String, there are multiple scores. Some of them, for example, are lab based, others are from literature, and others are from predictions. I would imagine that some stakeholders would feel better being able to filter out only the scores coming from lab based experiments. So maybe all the provided scores could be made available for filtering/enhancement? Same logic applies to DisGeNet, where count of # of papers seems to be a good score metric too.

[callahantiff]

Hi, if you dont mind me sharing my two cents. In the data PheKnowLator_v2.1.0_full_subclass_relationsOnly_OWLNETS_SUBCLASS_purified_Triples_Identifiers.txt there are 291 unique edge_types. Are all of these edge_types in the dataset?

Also, in DisGeNet, for example, the edges between DIS-GENE can have multiple labels, which completely changes the meaning between their interaction. Would it be possible to add the edge subtypes? https://www.disgenet.org/dbinfo paragraph The DisGeNET Association Type Ontology

In PheKnowLator's data sources description, it doesnt seem that any particular type of edge was filtered/selected: https://github.com/callahantiff/PheKnowLator/wiki/v2-Data-Sources#disgenet

For Protein-Protein from String, there are multiple scores. Some of them, for example, are lab based, others are from literature, and others are from predictions. I would imagine that some stakeholders would feel better being able to filter out only the scores coming from lab based experiments. So maybe all the provided scores could be made available for filtering/enhancement? Same logic applies to DisGeNet, where count of # of papers seems to be a good score metric too.

Hi @fmellomascarenhas - I always appreciate your feedback!

You are right that I have not yet included specific edge typing from the resources that we import, like DisGeNet and STRING. I agree it's time that we do!

I will spend some time working on and thinking through this tomorrow and will create a spec for what we can add from each source we import. I will also include a brief plan/overview of how I might approach integrating them (there will always be some solutions that are easier or better than others 😄). I can post those both here so guys can take a look. I will set aside time next week to make the changes as part of a new major release.

How does that sound?

[felipemello1]

Sounds great! :)

From a Machine Learning point of view, I see four main uses for that:

1. Filter data that my stakeholders might not want there, for example, edges created from protein-protein predictions;
2. Predict specific edgetypes, for example, drug-approved_treatment-disease;
3. Predict multiple edgetypes at once, as a multitask learning problem;
4. Use as an edge feature;

[callahantiff]

Excellent points and even more motivation for me to make these changes! 👍

[callahantiff]

Just an update -- I was not able to get to this last week, but plan on coming back to it next week. Sorry for the delay!

[callahantiff]

Sorry for the delay, I think we are close to being able to make the updates we have been discussing in this thread. I have been reviewing the different resources that we bring in and thinking through some of the challenges with @bill-baumgartner, who has been involved with me from the beginning in building pkt.

I think we came up with the best possible solution in terms of being able to incorporate the greatest amount of edge and node metadata from all input data sources. This should also allow us to easily incorporate other attributes or data types like timestamps and multiple edge weights. Note that this approach is specifically not designed to extend the base OWL knowledge representation as that can quickly get complicated. Instead, this approach is meant to supplement the existing output files in the least complicated way. Ideally, it provides each user with the most flexibility and options and enabling full downstream customization without having to know the details of each use case ahead of time. A brief description of what I am proposing is included below. Hope you like it!

---

Current Approach and Output

Currently, we are only producing metadata output for nodes and relations, not for triples or edges.

Node Metadata

Filename: XXXX_OWL_NodeLabels.txt
Output: tab-delimited txt file containing six columns. This file is somewhat misleading as it also contains information for each relation.

entity_type   integer_id   entity_uri                                      label      description/definition   synonym
NODES         375312       <http://www.ncbi.nlm.nih.gov/gene/58155>        PTBP2 (human)         A protein coding gene PTBP2 in human.   None
NODES         6297907      <https://www.ncbi.nlm.nih.gov/snp/rs10902762>   NM_000203.5(IDUA):c.60G>A (p.Ala20=)   This variant is a germline/unknown single nucleotide variant located on chromosome 4 (NC_000004.12, start:987144/stop:987144 positions, cytogenetic location:4p16.3) and has clinical significance 'Benign'. This entry is for the GRCh38 and was last reviewed on Nov 26, 2020 with review status 'criteria provided, multiple submitters, no conflicts'    None
RELATIONS     2057563      <http://purl.obolibrary.org/obo/RO_0002002>     has boundary   a relation between a material entity and a 2D immaterial entity (the boundary), in which the boundary delimits the material entity   None
RELATIONS     958453       <http://purl.obolibrary.org/obo/RO_0002444>     parasite of   None   direct parasite of
...

---

Proposed Representation

All data for nodes and edges will be output to a JSON Lines file (jsonl) file. This file essentially outputs a separate JSON file for each element. A more detailed description of the benefits of using this type of file can be found here. An example output is shown below (taken from https://jsonlines.org).

{"name": "Gilbert", "wins": [["straight", "7♣"], ["one pair", "10♥"]]}
{"name": "Alexa", "wins": [["two pair", "4♠"], ["two pair", "9♠"]]}
{"name": "May", "wins": []}
{"name": "Deloise", "wins": [["three of a kind", "5♣"]]}

Node Metadata

Output Filename: XXXXX_node_metadata.jsonl

The node metadata file will be keyed uri and each node will contain at a minimum, the following metadata:

• integer_id: the numeric identifier generated for the integer-based edge lists
• primary_type: A string stating the type of node, taken from the source ontology or input data type. Additional node types can be added, but will appear like <<src>>_entity_type, where src with being the name of the data source that the type was obtained from (more details below)
• primary_label: a string label for the node
• primary_description/definition: a string containing the definition for node
• primary_synonym: a list of synonyms for the node

Additional types of metadata at the node level will be added and the general format will be: <<src>>_<<type>>, where src is the name of the data source and type is the metadata type for that node (e.g., type, weight).

Edge Metadata

Output Filename: XXXXX_edge_metadata.jsonl

The edge metadata file will be keyed by a triple or edge identifier created as the MD5 hash of each identifier in the edge (i.e., MD5(subj_uri, relation_uri, obj_uri), and each edge will contain at a minimum, the following metadata:

• ``primary_relation_type`: A string containing the primary type for the edge
• weight: all edges will be initialized to 0.0

Additional types of metadata at the edge level will be added and the general format will be: <<src>>_<<type>>, where src is the name of the data source and type is the metadata type for that edge (e.g., weight).

As a result of including this file, I will also update the two flat-file outputs (XXXX_Triples_Identifiers.txt and XXXX_Triples_Integers.txt) to include the triple identifiers. Even though these can easily be generated on the fly.

Feedback/Questions

@bill-baumgartner - does that seem correct and cover everything we talked about?

@LucaCappelletti94 - I realize that the proposed output would not readily work as input to Embiggen, I am still very happy to produce a file in the input format we originally discussed.

@fmellomascarenhas and @sanyabt - Please let me know if you have any comments/feedback or if you have any issues with this approach. I think it will be the best overall and hopefully, be flexible enough to be useful for most use cases.

[felipemello1]

Hi @callahantiff , I am vacation this week, but I will get back to you soon! Thanks :)