[ 
https://issues.apache.org/jira/browse/LUCENE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497499#comment-17497499
 ] 

Andriy Redko commented on LUCENE-10432:
---------------------------------------

Yeah, it may not 100% cover everything (like the {{Weight#explain), }}but it is 
also not needed in every place. Probably generic bag for contextual properties 
would be less intrusive and extensible way to propagate name and other things 
(which are backed into description now), just another example for random 
scoring function explanation:
{noformat}
{
    "value": 0.38554674,
    "description": "random score function (seed: 738562412, field: null, _name: 
func2)",
    "details": []
}{noformat}

> Add optional 'name' property to org.apache.lucene.search.Explanation 
> ---------------------------------------------------------------------
>
>                 Key: LUCENE-10432
>                 URL: https://issues.apache.org/jira/browse/LUCENE-10432
>             Project: Lucene - Core
>          Issue Type: Improvement
>    Affects Versions: 9.0, 8.10.1
>            Reporter: Andriy Redko
>            Priority: Minor
>
> Right now, the `Explanation` class has the `description` property which is 
> used pretty much as placeholder for free-style, human readable summary of 
> what is happening. This is totally fine but it would be great to have a bit 
> more formal way to link the explanation with corresponding function / query / 
> filter if supported by the underlying engine.
> Example: Opensearch / Elasticseach has the concept of named queries / filters 
> [1]. This is not supported by Apache Lucene at the moment but it would be 
> helpful to propagate this information back as part of Explanation tree, for 
> example by introducing  optional 'name' property:
>  
> {noformat}
> {    
>     "value": 0.0,    
>     "description": "script score function, computed with script: ...",        
>  
>     "name": "script1",
>     "details": [        
>      {            
>          "value": 1.0,            
>          "description": "_score: ",            
>          "details": [                
>               {                    
>                   "value": 1.0,                    
>                   "description": "*:*",                    
>                   "details": []                
>                }            
>           ]        
>       }    
>     ]
> }{noformat}
>  
> From the other side, the `name` property may look like not belonging here, 
> the alternative suggestion would be to add support of `properties` /  
> `parameters` / `tags` key/value bag, for example:
>  
> {noformat}
> {    
>     "value": 0.0,    
>     "description": "script score function, computed with script: ...",        
>  
>     "tags": [
>        {  "name": "script1" }
>     ],
>     "details": [        
>      {            
>          "value": 1.0,            
>          "description": "_score: ",            
>          "details": [                
>               {                    
>                   "value": 1.0,                    
>                   "description": "*:*",                    
>                   "details": []                
>                }            
>           ]        
>       }    
>     ]
> }{noformat}
> The change should be non-breaking but quite useful for engines to enrich the 
> `Explanation` with additional context.
> [1] 
> https://www.elastic.co/guide/en/elasticsearch/reference/7.16/query-dsl-bool-query.html#named-queries
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to