Report number of results available

[jcoyne]

In order to paginate through a result set, it is helpful to know how many results are in the full set (vs the number returned on the current page). Ideally, the UI could return the URL for the next and previous pages. See http://demo.projectblacklight.org/catalog.json?f[format][]=Book for an example.

[elrayle]

Plan discussed in QA-Sinopia meeting today...

Proposed results structure

{
  "response": {
    "result_count": 2,
    "total_results": 122
  },
  "results": [
  {
    "uri": "http://aims.fao.org/aos/agrovoc/c_9884e64c",
    "id": "http://aims.fao.org/aos/agrovoc/c_9884e64c",
    "label": "acidified milk"
  },
  {
    "uri": "http://aims.fao.org/aos/agrovoc/c_8602",
    "id": "http://aims.fao.org/aos/agrovoc/c_8602",
    "label": "acidophilus milk"
  }
}

Work involved:

QA:

• Add configuration specifying default data to include in results. Potential values: results (required), response header, performance data
• Add parameter response_header=true to API request to indicate that the results should include response header in the results
• Add code to process the total number of results triple
• Update code that generates the response to add in the response header if requested
• Release of QA required

Cache:

• Get the total number of results, which is already available from the index search
• Identify a predicate to use to report the results as a whole Question: What would be the subject of the triple?
• Inject the total number of results in the results graph returned to QA

[eichmann]

Might want to include record_offset to anticipate the need to know where in the pagination this result came from...

[eichmann]

Does Sinopia have a DOI or comparable to use as a subject URI for the count?

[jermnelson]

Not really, in the past we've used a http://sinopia.io/vocabulary/ as a namespace for the sinopia:hasResourceTemplate predicate in the editor.

[jcoyne]

@eichmann Why would the count need a subject URI? Shouldn't QA just be returning JSON?

[elrayle]

@jcoyne QA will return the json in the Proposed Results Structure. But QA does not receive all results, so the results coming from the cache have to tell QA the total_results_count. Since the data coming from the cache is completely linked data, the total_results_count needs to be in a triple in the results graph that can be queried by QA.

[eichmann]

@elrayle how does this look for a count triple:

http://ld4l.org/ld4l_services/cache http://vivoweb.org/ontology/core#count "712" .

Not sure that count is actually a vivo property, but there's nice symmetry with rank.

[eichmann]

Demo implementation running at http://wintermute.slis.uiowa.edu:8081/ld4l_services/share_vde/x_batch.jsp for all VDE sites and 'x' is one of the site names. Counts are easy, as my tag library already provide it.

[elrayle]

@eichmann This looks good. I'll give it a go today and see about creating the results info in the QA response.

[elrayle]

Ready on stage for QA authorities driven from LD4L_CACHE.

This does not include Discogs.

[elrayle]

Final format of the response header is...

"response_header": {
"start_record": 0,
"requested_records": "DEFAULT",
"retrieved_records": 4,
"total_records": "NOT REPORTED"
}

[elrayle]

This issue is complete for LD4L_CACHE. A new issue was created for the DISCOGs work.

#252 Create response header with pagination information for Discogs