-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add TermsCardinalitySets as an index #8
Add TermsCardinalitySets as an index #8
Conversation
…redicates and getObjects - need to fix coverage still
Thanks for the PR @pietercolpaert! I had a quick look at the proposed API, but It's quite a bit different to what I had in mind, which might be caused by our different requirements. While we already had quad indexes, this PR adds unary indexes. But there is also a need for binary and ternary indexes. But the current implementation with TermsCardinalitySets obviously works, and solves your use case. So one option might be to use your fork of this library until I've managed to look into implementing this index abstraction. |
Thanks! That works for me. Can we however agree already on the method names then, such as |
I'm not too sure to be honest. If we follow this approach for binary and ternary access as well, then will need a huge amount of methods for handling all possible combinations of access. So we may need something more abstract. But I don't have a clean way in mind atm. Possible something using |
How about |
I don't think that will be sufficient to capture queries such as S? or ?P on SP index. |
Right... How about:
That way you can then bind the variables to the distincts you want? i.e.
Would translate into: SELECT DISTINCT ?s WHERE {
?s a foaf:Person .
} |
Perhaps, something like that could work. |
This pull request introduces a new index called TermsCardinalitySets, speeding up distinct look-ups of subject, predicate, objects and/or graphs.
In the index, we maintain an overview of their cardinalities of how many times they have been used in that position. While currently to exploited, this could also be useful towards speeding up certain counts.
Full test coverage should be reached, but I lack the typescript coverage experience to understand how the last line can be covered as well. Can you help with that?