reconciliation-api / testbench Goto Github PK

If a service's manifest can be accessed by CORS, then we want to do all other queries to it with CORS rather than JSONP. Currently, all queries in the testbench are done via JSONP except when testing for CORS availability on the manifest.

It should just trigger endpoint validation.

We don't seem to have set up continuous integration for this repository yet. We could at least have a GitHub Actions CI to check that the source compiles. A test suite would be even better!

In Chrome 87, even allowing "insecure content" for the test bench site, doesn't allow reconciliation services which are served over HTTP to be tested. It would be nice to figure out a way around this without having to go around and implement CORS and/or HTTPS everywhere, but I'm not sure what the options are.

Possibilities?:

• Serve a version of the test bench over HTTP
• Load manifest as pure JSON to be parsed safely without JSONP callback eval

As an aside, one of the sites doesn't appear to support JSONP or CORS http://openup.nhm-wien.ac.at/commonNames/?callback=foo returns pure JSON with no callback function wrapper.

The testbench shows this for many services:

Validation errors for service manifest: should have required property 'versions'.”

This is an optional key, see https://reconciliation-api.github.io/specs/latest/#service-manifest.
So the testbench should not report it as mandatory, but could reword to a milder warning, with link to the section.

https://reconciliation-api.github.io/testbench/#/ now has 80 servers listed, and some organization is needed

• sorting: is it sorted by URL? The sort seems random at first sight, but is surprisingly useful (eg the 3 Getty are next tg o each other, the 3 Ontotext also, the 6-7 GTAA also...). Maybe just add "sort" controls on Name and URL cols, and optionally a Creator col with sort controls?
• grouping: not sure how to organize it, see mix-n-match.toolforge.org for some ideas. Maybe use "main subject of" and some similar WD fields?

Btw the data model "API end point of Recon protocol" doesn't work in all cases, eg see reconcile-api and nomenklatura that are softwares for building Recon services but not datasets with their own end points.

(related to reconciliation-api/specs#52 and reconciliation-api/specs#55)

https://reconciliation-api.github.io/testbench/ shows lang-specific URLs for the first two services.

• It takes data from WD, eg the first row https://wikidata.reconci.link/en/api is from http://www.wikidata.org/entity/Q2013#P6269
• I added "language of work or name: English" for that URL:

Wikidata
  API endpoint: https://wikidata.reconci.link/en/api
    protocol: OpenRefine reconciliation service API
    described at URL: https://wikidata.reconci.link/
    source code repository: https://github.com/wetneb/openrefine-wikibase
    language of work or name: English

• However, WD has a gazillion service URLs that vary by lang, eg https://wikidata.reconci.link/bg/api
• It would be counter-productive to add them all as separate instances of P6269, and that would overload the testbench table

How to indicate endpoint URL variation by a fixed param? I imagine it as an extra column Varies By in the table.

How to express this in Wikidata? URL templates are called formatters in WD. I looked at available props, and maybe https://www.wikidata.org/wiki/Property:P8183 is what we need. The data needs to be restructured as follows:

Wikidata
  online service (P2361): Wikidata OpenRefine reconciliation service
Wikidata OpenRefine reconciliation service
  protocol: OpenRefine reconciliation service API
  # API endpoint: no language-independent endpoint
  general property-based URL formatter (P8183): https://wikidata.reconci.link/{P407}/api # language of work
  described at URL: https://wikidata.reconci.link/
  source code repository: https://github.com/wetneb/openrefine-wikibase

OpenCorporates
  online service (P2361): OpenCorporates OpenRefine reconciliation service
OpenCorporates OpenRefine reconciliation service
  protocol: OpenRefine reconciliation service API
  API endpoint: https://opencorporates.com/reconcile # ALL jurisdictions
  general property-based URL formatter (P8183): https://opencorporates.com/reconcile/{P1001} # applies to jurisdiction
  described at URL: https://api.opencorporates.com/documentation/Open-Refine-Reconciliation-API

Hi,

CONTRIBUTING.md defines that one need to join the CG to contribute. But what about simply using the code? Is this released under an open source license such as Apache, LGPL, CC-something, ...? Currently it is undefined and hence difficult to (re-)use, as the licensing is unclear...

Regards,
Wolfgang

In the current list of available services, there are entries that do not comply to the spec (e.g. offering GET support for reconciliation only, not POST support). Maybe there could be way to automatically test submissions. Possibly even with results being mirrored in differentiated status/support values in the testbench list.

Maybe an automatic and a manual (with form values) test method?

At the moment, the interactive test bench does all its calls via JSONP. So, for endpoints which only support CORS, this will fail. We should implement CORS support and use this by default for all services which do support it.

The more granular matching features introduced in reconciliation-api/specs#38 could be displayed by the testbench when they are returned by the service.

When using the Workbench, entering a URL with http (not https) gives the error message "The endpoint must return a JSONP document describing the service." In this case JSONP is supported with http. Replacing the url with the https transport alternative effectively removes the JSONP error message.

Expected behaviour is to display a warning that "the endpoint SHOULD be available over https".

The current JSONP error message is misleading.

At the moment we are not able to specify limit parameters in queries, we should add an input for that.

It would be nice if there were a direct link from the test bench site back to the source repo (ie here) for folks who'd like to file an issue or fix a bug.

When opening the test bench with some endpoint, and then switching back to the Services tab, and then to the "Test bench" tab, we lose the service being tested. It could be nice to preserve it.

All endpoints are returning an error.
Safari -> "Error: i is not a function. (In 'i(t)', 'i' is undefined)"
Firefox -> "Error: i is not a function"

Reproduced on endpoints : https://api.artsdata.ca/recon, https://reconcile.ontotext.com/people

Test bench for the endpoint https://lobid.org/organisations/reconcile with the query 'basf' returns:
''Error: Cannot read property 'result' of undefined" in Opera,
"Error: t.q0 is undefined" in Firefox,
"Error: undefined is not an object (evaluating 't.q0.result')" in Safari.

When a reconciliation candidate is a match it turns blue in the UI. The ID link disappears because the background of a matched candidate is the same blue as the link's blue.

The expected behaviour is for the ID link in a matched candidate to turn white.

We should use the URL hash to store which reconciliation endpoint we are testing against.
Otherwise if we click on some external links (such as reconciliation candidates) and use the browser's back button, then we go back to the list of services.

    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:133:10)
    at module.exports (/private/tmp/testbench/node_modules/webpack/lib/util/createHash.js:90:53)
    at NormalModule._initBuildHash (/private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:401:16)
    at handleParseError (/private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:449:10)
    at /private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:481:5
    at /private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:342:12
    at /private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at iterateNormalLoaders (/private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
    at /private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:236:3
    at runSyncOrAsync (/private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
    at iterateNormalLoaders (/private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
    at Array.<anonymous> (/private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/private/tmp/testbench/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
    at /private/tmp/testbench/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
/private/tmp/testbench/node_modules/react-scripts/scripts/start.js:19
  throw err;
  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:133:10)
    at module.exports (/private/tmp/testbench/node_modules/webpack/lib/util/createHash.js:90:53)
    at NormalModule._initBuildHash (/private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:401:16)
    at /private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:433:10
    at /private/tmp/testbench/node_modules/webpack/lib/NormalModule.js:308:13
    at /private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:233:18
    at context.callback (/private/tmp/testbench/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at /private/tmp/testbench/node_modules/babel-loader/lib/index.js:51:103 {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v18.0.0

The workaround here seemed to fix it.

FWIW, I'm running on OSX 12.0.1 with npm version 8.6.0.

At the moment we cannot test the data extension protocol. We have a panel for that.

The form could have two inputs: a list of entity ids (filled with suggest service if available) and a list of properties (also filled with the suggest service if available).

We need renderers for all possible property values.

In today's call we mentioned it would be useful to have a link from the testbench to the census.

The first sentence on https://reconciliation-api.github.io/testbench/#/ reads

"This table lists reconciliation services known to Wikidata and indicates which..."

Shouldn't this be OpenRefine rather than Wikidata?

At the moment we cannot test previews. We could have it in two places:

• in the list of reconciliation candidates, when hovering over candidates (in a similar way to OpenRefine);
• as an independent pannel (already added).

The readme of this repo starting at
https://github.com/reconciliation-api/testbench#npm-run-eject
Is some template stuff that I think should be removed

This is feature is not exposed by OpenRefine but it is in principle possible to supply multiple types in a reconciliation query, and set a type_strict parameter to configure how these types should be matched. We should probably add support for that.

Reconciliation services themselves could want to reuse the components used here to let users try out their reconciliation services interactively on their own website. I would be interested in this for the Wikibase enpdoints. We could look into publishing the React components for that.

At the moment the test bench only adds the widget to input additional properties if the service offers a suggest service for properties. That should be relaxed since suggest services are really just there for UI integration, the client could somehow know what properties are supported by the service.

I have successfully used the test bench to test my reconciliation API (api.artsdata.ca) however, when using a tool like OpenRefine, nothing worked (spinning forever while waiting determining types). I found the problem by applying the JSON Schema provided in the excellent spec documentation to validate my JSON. The problem was that the 'type' value in the query result was not placed in a list when only one type is returned.

Expected behaviour is to be shown in the test bench when JSON serialization is not a valid schema.

using the URL https://services.getty.edu/vocab/reconcile/ and they type /ulan, a query for "Robert" generates the following error:

Error: undefined is not an object (evaluating 't.q0.result')

See attached screenshot for configuration.