Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

knowledge_level on all edges? #358

Open
edeutsch opened this issue Jan 10, 2024 · 12 comments
Open

knowledge_level on all edges? #358

edeutsch opened this issue Jan 10, 2024 · 12 comments
Assignees

Comments

@edeutsch
Copy link
Contributor

From Tyler's post in Architecture today:

image

@saramsey
Copy link
Member

April 1 deadline to get this coded and deployed.

@saramsey
Copy link
Member

Steve: look in the Biolink model to see if we can get the controlled vocabulary for knowledge_level

@saramsey
Copy link
Member

saramsey commented Jan 16, 2024

Here is the schema that we will need to implement. There are actually two new edge properties, agent_type and knowledge_level:

https://github.com/NCATSTranslator/ReasonerAPI/blob/master/ImplementationGuidance/Specifications/knowledge_level_agent_type_specification.md

@saramsey
Copy link
Member

I'm hearing that we should plan our work to aim to have this rolled out in a new build of RTX-KG2 KP and tested in CI (and ready to deploy to ITRB TEST) by mid-March (final date to be announced at the relay next week).

@saramsey
Copy link
Member

Lili and I are envisioning a new module that processes the KG2 edges json-lines file, downstream of filter_kg_and_remap_predicates.py. In rough pseudocode:



# load JSON-lines edge file

# iterate over edges

# for each edge, assume the edge exists as a python dictionary `edge_dict`

primary_knowledge_source = edge_dict['primary_knowledge_source']
edge_dict['attributes'] = [
    {
        "attribute_type_id": "biolink:agent_type",
        "value": "not_provided",
        "attribute_source": primary_knowledge_source
    },
    {   
        "attribute_type_id": "biolink:knowledge_level",
        "value": "not_provided",
        "attribute_source": primary_knowledge_source
    }
]

# write the edges list back out as a JSON-lines file (with a new filename)

@saramsey
Copy link
Member

TBD: we will need to come up with a mapping strategy (which may be based on yet another YAML file) to determine what values should be put, instead of "not_provided".

@saramsey
Copy link
Member

saramsey commented Mar 25, 2024

We are hoping to get this as KG2.10.Xc into the Translator release that takes place after the Eel release (which would probably mean a late June deadline for an ARAX based on KG2.10.Xc to be requested to be deployed into ITRB TEST. Which, in turn, would mean that KG2.10.Xpre would need to be built and validated correct for this issue by mid-May. We are aiming to do the treats refactor work (#373) before this, i.e., in the Eel release.

@ecwood ecwood assigned ecwood and unassigned saramsey and acevedol Jul 1, 2024
@ecwood
Copy link
Collaborator

ecwood commented Jul 1, 2024

@saramsey Do we need this in an attributes list? Currently, we don't use an attributes list in RTX-KG2pre. That data type won't serialize nicely into Neo4j (since it just becomes a big string). I think that the attributes list is usually created downstream of KG2pre. I think this schema would make more sense, given that the attribute_source will be identical to the source of the edge anyway (the primary_knowledge_source). Further, it would be consistent with all of the other edge properties currently in KG2.

edge_dict['agent_type'] = agent_type_map[primary_knowledge_source]
edge_dict['knowledge_level'] = knowledge_level_map[primary_knowledge_source]

@ecwood
Copy link
Collaborator

ecwood commented Jul 1, 2024

@saramsey Are we currently expected to fulfill the short term or long term specification on https://github.com/NCATSTranslator/ReasonerAPI/blob/master/ImplementationGuidance/Specifications/knowledge_level_agent_type_specification.md?

@saramsey
Copy link
Member

saramsey commented Jul 1, 2024

@ecwood no I don't think in KG2pre, we need it in an edge attributes list. It could be two new edge properties knowledge_level and agent_type that could be turned into edge attributes in the RTX-KG2 TRAPI interface. @amykglen and @sundareswarpullela does that make sense?

But yes, @ecwood, at this point, Translator has moved to implement the long-term spec, i.e., each edge needs to have a knowledge_level and agent_type documented on it. But I think for the purpose of the KG2pre build, it makes sense to do it using two new edge properties, knowledge_level and agent_type, which can be turned into TRAPI edge attributes in the RTX-KG2 TRAPI interface.

@amykglen
Copy link
Member

amykglen commented Jul 2, 2024

yes, adding knowledge_level and agent_type as two new edge properties in KG2pre makes sense to me. that should be easy to incorporate into KG2c and load into TRAPI format in the RTX-KG2 API code (as we do for the other KG2 properties).

@ecwood
Copy link
Collaborator

ecwood commented Jul 3, 2024

Per my exchange with Sierra, while the infores_catalog.yaml file is still on the short term specifications, we should be using the long term specifications:

For the knowledge_level and agent_type attributes, should we be using the short or long term specification? It looks like the infores catalog uses the short term one, but I wanted to reach out to see if this is accurate/whether it will be changing soon.

apologies Erica! this slipped through the cracks. definitely the long-term specification here. at the DM call last week we talked through possibly removing the infores defaults (or keeping them and updating them to the long-term spec as well). I think we decided to keep them in the infores catalog but update them to the long-term spec as some KPs hadn't quite finished the conversion and having the defaults was helpful.
but, ultimately, we want the KPs to add these edge metadata according to the long-term spec so that the infores catalog defaults eventually go away

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants