search

reconciliation-api / specs

Specifications of the reconciliation API
https://reconciliation-api.github.io/specs/draft/
30 stars 9 forks source link

Reformulate the 'type' parameter as another property #145

Open wetneb opened 7 months ago

wetneb commented 7 months ago

Given that we are thinking about changing the query field of reconciliation queries into a property (https://github.com/reconciliation-api/specs/issues/134), I think it's tempting to think whether we could do the same for types. It would then let us use the additional settings on properties (https://github.com/reconciliation-api/specs/pull/131), essentially offering users the choice between:

One problem is that the property values we currently allow in a reconciliation query do not include type ids. I am not too sure what to do about this.

But overall I feel like #115 is likely going in the wrong direction, given the recurrent feedback we get in OpenRefine about needing support for reconciling against multiple types. (See the discussion in #109 too)

thadguidry commented 7 months ago

I think property values need to support the best practice of "Things not Strings". Now, there are a few ways to allow for that, and JSON-LD provides one way https://w3c.github.io/json-ld-bp/#things-not-strings along with several other best practices. In fact, once my eye heals, I'll be writing and hosting a service that uses JSON-LD to provide not only @context but also allow mappings via @vocab. I generally think at this point of the next draft we should take our time and see how to incorporate more JSON-LD to allow even more standardization and reuse, I.e. not Hydra as an interop example but instead JSON-LD and the Principles of Linked Data. I think eventually we could also publish a JSON-LD Context for standardization.