You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is to suggest that we treat subclass_of edges, similar_to edges, and related ones in the same manner as we treat occurs_together_in_literature_withedges, meaning that we return them in the answer subgraphs, but not as nodes/edges in the answer results, and probably not consider those metrics as part of the scoring/ranking. I understand why we added those edges, but they feel more like node properties or supporting evidence to me, not "knowledge" that is returned in response to a user query.
For example, this result set dilutes the user intention and any meaningful results:
Alternatively, or in addition to, perhaps we can support a feature that allows users to "turn off" subclassing or specific predicates? That might be the easier option.
This is a complicated topic because subclass edges can be returned as part of a query in several ways:
a query that specifically asked for subclass edges
a query with an edge without a specified predicate
as part of the implicit subclassing Plater does to infer answers that don't match the query exactly but for which the inclusion of one hop subclass edges generates matching results
I kind of disagree that they are like properties or supporting evidence, they are never added unless the subclass edge and node were necessary to produce a result. However, if we want to represent them differently in the UI that could make sense regardless.
Importantly, Plater recently changed how it represents results using implicit subclassing. Now it creates a new edge that is a composite of the subclass_of edge and the edge that matches the query edge. It adds that edge to the knowledge graph and as a support graph for that result. We also do not include the subclass nodes used in implicit subclassing in node bindings anymore, only in the knowledge graph section of TRAPI. We have not really tested this in the UI yet and it may already "fix" some of these issues (or cause new ones), due to subclass nodes not appearing in specific results.
Additionally, Plater now has a feature to turn off implicit subclassing with a simple url parameter during the call, which I think can address @karafecho main concerns, if we add a feature to the UI to allow the user to choose if they want it or not, but that needs to be added to Aragorn as well so it gets passed along to Plater. #139
#194 should not be an issue anymore, self / loop subclass edges were removed.
This issue is to suggest that we treat
subclass_of
edges,similar_to
edges, and related ones in the same manner as we treatoccurs_together_in_literature_with
edges, meaning that we return them in the answer subgraphs, but not as nodes/edges in the answer results, and probably not consider those metrics as part of the scoring/ranking. I understand why we added those edges, but they feel more like node properties or supporting evidence to me, not "knowledge" that is returned in response to a user query.For example, this result set dilutes the user intention and any meaningful results:
Alternatively, or in addition to, perhaps we can support a feature that allows users to "turn off" subclassing or specific predicates? That might be the easier option.
Note that this issue is related to #139 and #194.
The text was updated successfully, but these errors were encountered: