specs
specs copied to clipboard
Specifications of the reconciliation API
I think it's great to standardise on what a reconciliation API should and shouldn't do, but I strongly favour ensuring that the API response is in line with the W3C...
Sometimes, reconciliation queries can be invalid, for all sorts of reasons: * their JSON structure does not fit the schema * they contain references to objects that do not exist...
http://www.cs.ox.ac.uk/isg/challenges/sem-tab/ Describes a task called - Tabular Data to Knowledge Graph Matching, or - Entity Linking for Tabular Data The key difference is this: - Reconciliation matches **one** column (with...
We should add a not about how services should throttle queries. Probably using standard HTTP mechanisms like a `Retry-After` header - so there is probably not much to specify except...
We've been exploring using the Reconciliation API in a smart building/smart grid/IoT setting: we have sensor names (and only sensor names) from legacy industrial equipment and we want to predict...
Currently the spec says: - `type_strict`: Optionally, a type strictness parameter, which can be one of the strings "should", "all" or "any". - (later) - NOTE: The meaning of the...
As I mentioned in PR #23 I think there might be a need to introduce something similar to the existing `type_strict` but for `properties`. > I think this is useful...
## Recon spec https://reconciliation-api.github.io/specs/latest/#reconciliation-query-responses includes two characteristics that determine the "quality" of a candidate: - `score` (numeric) and - `match` (boolean) I think these rules would make sense: - `match`...
Reconciliation candidates returned by services can contain a `"matched"` attribute, which indicates whether the service predicts that the entity matches the query. At the moment, we do not specify anything...
I think that in many cases it will be useful to match rows by their textual content, using it as a general context for the entities in the KB. NLP...