json format of the query result

[eroux]

We should define the JSON format we want for the output of the query interface, and solely use that (building the html table in the client, the server should absolutely not do that in no circumstance). The format should probably be something like:

{
  "links": { hateoas stuff if relevant },
  "execInfo": {
    "timing": { timing information },
    "debug": { some debug info if relevant }
  },
  "results": whatever the SPARQL query actually returned
}

see this link for hateoas, it's an interesting concept we could use for pagination (and maybe other things?). Many modern APIs use this concept. The debug information could probably be triggered by a debug parameter in the URL and there could maybe be an authentication condition for a user to use this parameter.

[MarcAgate]

Json format is Default jena fuseki raw response format : https://www.w3.org/TR/rdf-sparql-json-res/ Run curl --data "searchType=pdi_w_bibli&L_NAME=chos+dbyings+bstod+pa" http://buda1.bdrc.io:13280/lds-pdi/query for an example

[eroux]

Well, I think we could want that as a possibility, but I also think it shouldn't be the only format. It misses most of the features of my initial proposal, for instance hateoas for pagination, meta-info (execution time, debug symbols, etc.), so I still think we can work a bit more on this...

[MarcAgate]

I think we agreed that jena raw response format was quite satisfactory for the moment and that we can amend it if new requirements require changes.

[xristy]

We need to prioritize Élie's proposal high and perhaps take the jena raw response format as *.raw, e.g.

Pagination in particular is most important for supporting clients that use ldspdi as the app server

[MarcAgate]

I searched a little bit about that and I've plan to tackle pagination this week. This is an issue not related to json output format and as far as I know, Jena has some utilities that should facilitate the process (fuseki endpoint is doing pagination).

[xristy]

JSON figures in to the issue since it is presumed that client apps will have a preference for JSON.

I agree with Élie that using hateoas approach is sensible. Whether pagination is done via jena support in fuseki or in ldspdi, there is still an issue of how the pagination is presented to the client which is independent of the mechanization. It's an interface issue.

We may well end up with other actions that pagination that we want to support and using an approach that allows for dynamic discovery will be to our benefit.

It would also be good to add some info to the lds-pdi README regarding the format of the JSON including exec fields like total number of results, exec time, and number of results this page and so

[MarcAgate]

We are now using a custum format with pagination information and JsonParameter Strings for JSON post. Here is an example :

{ "pageNumber" : 1, "numberOfPages" : 10, "pageSize" : 10, "numResults" : 100, "execTime" : 498, "hash" : 240864041, "isLastPage" : false, "isFirstPage" : true, "pLinks" : { "prevGet" : null, "nextGet" : null, "currJsonParams" : "{\"L_NAME\":\"(\\"chos rgyal\\")\",\"searchType\":\"Res_byName\",\"pageSize\":\"10\",\"I_LIM\":\"100\",\"hash\":\"240864041\",\"L_LANG\":\"@bo-x-ewts\"}", "prevJsonParams" : null, "nextJsonParams" : "{\"L_NAME\":\"(\\"chos rgyal\\")\",\"pageNumber\":\"2\",\"searchType\":\"Res_byName\",\"pageSize\":\"10\",\"I_LIM\":\"100\",\"hash\":\"240864041\",\"L_LANG\":\"@bo-x-ewts\"}" }, "headers" : [ "s", "lit" ], "rows" : [ { "dataRow" : { "s" : " P4951", "lit" : "chos rgyal/@bo-x-ewts" } }, { "dataRow" : { "s" : " P10203", "lit" : "chos rgyal/@bo-x-ewts" } },

etc... The pLinks objects holds (depending on the request method) GET Urls for previous and next pages or POST json param lists of current, previous and next pages.

I close the subject for now, until new or finer requirements.