[
https://issues.apache.org/jira/browse/SOLR-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474425#comment-16474425
]
Hoss Man commented on SOLR-9480:
--------------------------------
Updated patch...
bq. ... some bug where the existing refinement logic isn't picking up the
function contributions of some shards when the doc count is 0 ...
I tracked down the problems I was seeing to SOLR-12343 -- knowning that bug
exists, I've made the test "self regulate" itself to avoid it: first it picks a
random sort option, and then if the sort is one that _might_ result in that bug
causing incorect stat values, i force the limit option to be big enough that
all posible field values will be refined & returned to the client. This let me
relax a *lot* of the other constraints I had put on the test based on earlier
misdiagnoses of what was causing these types of problems.
{quote}
* right now the redundent fore & back "size" values (which are the same for
every slot/bucket) are returned for every bucket ... i'd like to try and figure
out if i can put that data in the facet "context" to reduce the shard response
size.
...
* figuring out what/how/where to put info in the facetDebug output
{quote}
...neither of these really seem possible at the moment for similar/overlapping
reasons...
# There are currently no "per bucket" facet debug information, everything is
reported at the "Per-Facet" level
# AggValueSources/SlotAccs currently don't know what their "key" is in the
parent facet/context ...
#* which means there is no "safe" key for the accumulator to use if it tried to
put data directly into the (parent) facet response, or if it tried to put any
stat specific debug info in the FacetDebugInfo Map
(This situation of "what is my instances key/name?" is something we probably
want to solve eventually, if not for optimizing the response size and/or adding
debuging info then for the "making the queries optional, and inheriting them
from "ancestor" function instances higher up the tree" type functionality i
mentioned in my previous comment)
...so i went ahead and removed those nocommits from the patch.
> Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
> --------------------------------------------------------------------------
>
> Key: SOLR-9480
> URL: https://issues.apache.org/jira/browse/SOLR-9480
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Trey Grainger
> Priority: Major
> Attachments: SOLR-9480.patch, SOLR-9480.patch, SOLR-9480.patch
>
>
> This issue is to track the contribution of the Semantic Knowledge Graph Solr
> Plugin (request handler), which exposes a graph-like interface for
> discovering and traversing significant relationships between entities within
> an inverted index.
> This data model has been described in the following research paper: [The
> Semantic Knowledge Graph: A compact, auto-generated model for real-time
> traversal and ranking of any relationship within a
> domain|https://arxiv.org/abs/1609.00464], as well as in presentations I gave
> in October 2015 at [Lucene/Solr
> Revolution|http://www.slideshare.net/treygrainger/leveraging-lucenesolr-as-a-knowledge-graph-and-intent-engine]
> and November 2015 at the [Bay Area Search
> Meetup|http://www.treygrainger.com/posts/presentations/searching-on-intent-knowledge-graphs-personalization-and-contextual-disambiguation/].
> The source code for this project is currently available at
> [https://github.com/careerbuilder/semantic-knowledge-graph], and the folks at
> CareerBuilder (where this was built) have given me the go-ahead to now
> contribute this back to the Apache Solr Project, as well.
> Check out the Github repository, research paper, or presentations for a more
> detailed description of this contribution. Initial patch coming soon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
