On Fri, Nov 5, 2021 at 3:46 PM Thomas Douillard <thomas.douill...@gmail.com> wrote:
> [...] > But a query planner/rewriter should be able to detect a pattern like « > filter lang() = "en" » to take advantage of such an index ? > > With how blazegraph works it is hard to apply filters on literals unless the data to filter is "inlined" in the btree. Unfortunately what blazegraph offers is inlining the whole literal not just the lang tag and inlining all string literals is definitely not possible for wikidata, the btree would explode. Perhaps there are other triple stores that could inline solely the language tag that would make this query faster? While I agree that labels are important they are rarely used as a criteria to traverse the graph but often used as a first step to "search" or as a last step to "display", this is why I wonder if it would not be a better approach to federate multiple data APIs: - the query service for pure graph traversal - wikidata search APIs for label/alias/description searching - upcoming wikidata REST api for label/alias/description fetching David.
_______________________________________________ Wikidata mailing list -- wikidata@lists.wikimedia.org To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
