-
Notifications
You must be signed in to change notification settings - Fork 28
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
Update Migration Guide #420
Conversation
You can more easily read the new formatted guide here: https://github.com/uhbrar/ReasonerAPI/blob/update_guide/MigrationAndImplementationGuide1-4.md |
Added subclass example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seemed to be some substantial push-back against implementing this policy when we brought this up, so I think this will need some more discussion before merging.
} | ||
] | ||
}, | ||
"edge_bindings": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think results have edge_bindings any more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was decided that KP's should not use result.edge_bindings and should instead construct an analysis object.
I thought that it was pretty well accepted that subclasses could be represented this way when discussed at architecture. There was definitely discussion about this use case being added to the guide. |
My recollection from the TRAPI call is that this was discussed and there was substantial push-back, perhaps from Vlado and others, I don't recall now exactly. The notes say:
I started the issue here: #414 I think this change will need formal approvals before merging. I suggest conversion continue in the issue. |
@@ -1,10 +1,12 @@ | |||
# TRAPI 1.4 Migration and Implementation Guide | |||
This guide is split into two major sections. The first section focusses on ARA's. The second section focusses on KP's. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -225,7 +334,7 @@ Most of the knowledge graph will remain the same in this example. Only one of th | |||
"predicate": "treats", | |||
"attributes": [ | |||
{ | |||
"attribute_type_id": "support graph", | |||
"attribute_type_id": "infores:support_graphs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this supposed to be "biolink:support_graphs", from here?
And is the value for this attribute_type_id always an array (vs a string key for one auxiliary graph)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thank you.
There's noting in the specification that necessarily says that it has to be a list, but I think expected practice is a list as opposed to a single value. Unless this was further specified in the biolink model.
@@ -452,7 +569,7 @@ Finally, we can put all of it back together, to show the full message. | |||
"predicate": "treats", | |||
"attributes": [ | |||
{ | |||
"attribute_type_id": "support graph", | |||
"attribute_type_id": "infores:support_graphs", |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
"query_graph": { | ||
"nodes": { | ||
"query_node_0": { | ||
"ids": ["MONDO:0005148"] |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thank you.
Also does the description for Result need editing since it discusses edges and edge-bindings? https://github.com/uhbrar/ReasonerAPI/blob/1.4/TranslatorReasonerAPI.yaml#L564 |
I didn't notice that. I thought I'd already fixed the description for Result. I'll put in a separate pull request in for that. |
@@ -1,10 +1,12 @@ | |||
# TRAPI 1.4 Migration and Implementation Guide | |||
This guide is split into two major sections. The first section focuses on ARAs. The second section focusses on KPs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still has a "focusses" typo
The number of approvals is very meagre, but I'm going to merge this anyway, because if we actually wait for approvals we'll never merge it. |
This adds a guide dedicated more to KP's as opposed to ARA's. This also includes an example for source retrieval provenance refactoring.