-
Notifications
You must be signed in to change notification settings - Fork 0
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
Ubergraph filters #28
Comments
@balhoff - wondering if there is a way to add a third graph with less redundancy stripping than the nonredundant graph that fulfills this use case. Also would like to consider OAK as the best home for methods to take advantage of this if we can't fix with additional graphs. |
@dosumis what do you think about these query results? https://api.triplydb.com/s/MGJqUWP_6 |
@dosumis I think this one more directly encodes what you're looking for, but sometimes NOT EXISTS is expensive. It seems to work in this case: https://api.triplydb.com/s/c5DmHCzmG and I think it gives the right results for those two terms: https://api.triplydb.com/s/SinnoFp-e |
That works & makes sense too. Thanks! (I think too slowly in SPARQL) |
Do you want to try the query approach and hold off on thinking about new graphs for the moment? |
I think the query approach makes the most sense & seems to scale well. We could always revisit the new graph approach in future if use-cases justify it. |
STATUS: DRAFT
Problem
The results of direct queries of ubergraph redundant and non-redundant graphs often give suboptimal results for biologist-facing use cases. The redundant
Case 1: Most precise object term needed.
Query of object graph => object terms that are too abstract. Query of non-redundant graph fails to => any object term in cases where redundancy stripping assumes users will be able to infer from the properties of a more general class.
Examples:
capable of
)https://api.triplydb.com/s/166HwhWEo
The redundant graph => 67 cell types
-->
For each subject: query for all subClassOf relationships between object terms. Filter out all triples from the original query where the term has subclasses according to this second query. However, this would require many secondary queries and so would be inefficient. Is there some clever way to do this in SPARQL with subqueries?
CASE2: Graph-view generation
Aim: simple redundancy stripping that does not assume users can deal with inheritance of properties down the class heirarchy.
{details and examples TBA}
The text was updated successfully, but these errors were encountered: