Understanding the Solr Result Set - fl parameter
In this first of a series of blogs about Solr result sets I'd like to talk about returned fields, both static and dynamic.
Stored Fields
Any field that is stored in Solr can be returned in the result set. The following table shows all available stored fields:
| Name | Description | Type | Indexed |
|---|---|---|---|
| ab_* | all abstracts | mixed: alexandria_text, alexandria_asian_text | true |
| ad | filing date | tint | true |
| an | application number (tokenized) | alexandria_token | true |
| anorig | original, patent office format application number | alexandria_token | true |
| anseries | US application series code | alexandria_string | true |
| anucid | standardized filing identifier | string | true |
| ecla | ECLA classification | alexandria_string | true |
| fam | family identifier | string | true |
| fterm | F-Terms | alexandria_string | true |
| icl,cpcl,uscl,ficl | classifications suitable for display | string | false |
| ifi_name_current_id | current assignee identifier | string | true |
| ifi_name_original_id | original assignee identifier | string | true |
| ifi_pa | IFI assignees | alexandria_token | true |
| inv | inventors | alexandria_token | true |
| loadid | meta load identifier | tint | true |
| nclms | number of claims | tint | true |
| nindepclms | number of independent claims | tint | true |
| pa | applicants/assignees (all formats) | alexandria_token | true |
| pd | publication date | tint | true |
| pn | patent number (tokenized) | alexandria_token | true |
| pri | priority filing number (tokenized) | alexandria_string | true |
| prid | earliest priority filing date | tint | true |
| priorig | original, patent office format priority number | alexandria_string | true |
| timestamp | last modification stamp | tdate | true |
| ttl_* | all titles | mixed: alexandria_text, alexandria_asian_text | true |
| ucid | unique character identifier | string | true |
The shorthand to return all static fields is the asterisk fl=*
/search/query?q=ucid:US-20160054444-A1&fl=*&rows=1
As with all examples, we discuss results in JSON format.
"docs" : [
{
"timestamp" : "2016-02-27T08:29:31.936Z",
"ucid" : "US-20160054444-A1",
"loadid" : 229946,
"nclms" : 19,
"nindepclms" : 2,
"fam" : "-1",
"pn" : "US-20160054444-A1 US20160054444A1",
"pd" : 20160225,
"an" : "US-201514833357-A"
"anseries" : "14",
"anorig" : "US-14833357",
"ad" : 20150824,
"pri" : [
"FR-1457951"
],
"prid" : 20140825,
"priorig" : [
"FR-1457951"
],
"cpcl" : [
"G01S 15/588 20130101 LI20160225BHUS ",
"G01S 15/60 20130101 FI20160225BHUS "
],
"icl" : [
"G01S 15/58 20060101ALI20160225BHUS ",
"G01S 15/60 20060101AFI20160225BHUS "
],
"ifi_pa" : [
"ECA ROBOTICS",
"ECA ROBOTICS"
],
"inv" : [
"Pinto, Marc"
],
"pa" : [
"ECA ROBOTICS",
"ECA ROBOTICS"
],
"ttl_en" : [
"METHOD AND SONAR DEVICE FOR DETERMINING THE SPEED OF MOVEMENT OF A NAVAL VEHICLE IN RELATION TO THE SEA BED"
],
"ab_en" : [
"<abstract mxw-id=\"PA168904151\" lang=\"EN\" load-source=\"patent-office\">\n <p id=\"p-0001\" num=\"0000\">Sonar intended to be carried by a naval vehicle including at least one element for transmitting an acoustic signal, at least one element for receiving the acoustic signal transmitted and reflected on the sea bed and at least two phase centres (PC<sub>1</sub>, PC<sub>2</sub>) that are disposed along a first and a second axis (v<sub>1</sub>, v<sub>2</sub>), respectively, forming an interferometric antenna. The sonar includes elements for determining the speed of movement of the vehicle as a function of the computed value of the relative trim angle (β) formed between a straight line (d<sub>1</sub>) that is perpendicular to the axes (v<sub>1</sub>, v<sub>2</sub>) of the phase centres and a straight line (d<sub>2</sub>) that is perpendicular to the sea bed (F) and of the value determined for the angle of sight.</p>\n </abstract>"
],
}
],
Some things to notice: Multi-valued fields are returned as JSON arrays. Also, as inv, pa and ifi_pa are copyFields containing multiple values, duplicate entries may appear.
Dynamic Fields
Dynamic fields are fields that are generated either internally, like the relevance score or fields that can be generated by computing values using function queries. Dynamic fields must be listed explicitly in the fl parameter, e.g., fl=score. Below, we request the static ucid field together with the relevance score for 5 results.
/search/query?q=ab_en:sonar&fl=ucid,score&rows=5
"docs" : [
{
"ucid" : "US-20160054444-A1",
"score" : 1.1746656
},
{
"ucid" : "US-9268020-B2",
"score" : 2.8773313
},
{
"ucid" : "US-20160047906-A1",
"score" : 1.1735018
},
{
"ucid" : "US-20160049143-A1",
"score" : 0.99574935
},
{
"ucid" : "US-20160047891-A1",
"score" : 1.1675186
}
],
Another type of dynamic field makes use of function queries. A simple, yet contrived, example would be to return the number of dependent claims. CLAIMS Direct stores the total number of claims in nclms as well as the number of independent claims in nindepclms, both as tint. Simple subtraction yields the desired result.
/search/query?q=ab_en:sonar&fl=ucid,nclms,nindepclms,sub(nclms,nindepclms)&rows=2
"docs" : [
{
"ucid" : "US-20160054444-A1",
"nclms" : 19,
"nindepclms" : 2,
"sub(nclms,nindepclms)" : 17
},
{
"ucid" : "US-9268020-B2",
"nclms" : 74,
"nindepclms" : 3,
"sub(nclms,nindepclms)" : 71
}
],
Field Aliases
Field aliasing allows individual fields in the result set to be renamed. This functionality is particularly useful to give meaningful names to pseudo fields created by function queries as in the example above. Any field can be renamed using aliases. The syntax is: alias-field-name:original-field-name
Note
ucid is the only exception. When trying to alias the ucid, an HTTP 500 will be returned.
/search/query?q=ab_en:sonar&fl=ucid,total:nclms,independent:nindepclms,dependent:sub(nclms,nindepclms)&rows=1
"docs" : [
{
"ucid" : "US-20160054444-A1",
"total" : 19,
"independent" : 2,
"dependent" : 17
}
],
