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

Rethink predicates such as subclass_of, similar_to, etc #230

Open
karafecho opened this issue Sep 20, 2024 · 2 comments
Open

Rethink predicates such as subclass_of, similar_to, etc #230

karafecho opened this issue Sep 20, 2024 · 2 comments

Comments

@karafecho
Copy link

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:

image

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.

@karafecho
Copy link
Author

Also see #221.

@hina-shah hina-shah added enhancement New feature or request help wanted Extra attention is needed labels Oct 1, 2024
@EvanDietzMorris
Copy link

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.

@hina-shah hina-shah added subclassing and removed help wanted Extra attention is needed labels Nov 6, 2024
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

4 participants