Restrict data extension property settings to specific properties

[fsteeg]

In the lobid-gnd reconciliation service we have an extends.property_settings item to select if a property should be added as an ID or a label. This only makes sense for non-reconciled properties, since reconciled properties already have both ID and label. Since OpenRefine always shows the configure link, we explain in our documentation that this setting only makes sense for non-reconciled properties.

To allow clients to show configuration UI only for supported properties, perhaps it would make sense to add support for restricting settings to specific properties in data extension property settings, e.g. with a target field. This could contain an array with the targeted property IDs, or some service-specific value (like non_reconciled in our example).

[wetneb]

Makes sense… but for services like Wikidata which have thousands of properties, it could be slightly impractical to list many of them in the manifest? I mean, we could totally add that feature and it would obviously not be a problem for the Wikidata service since the settings apply to all properties currently, but say I wanted to add a setting which would only work for "external-id" properties, it would be quite impractical to list the thousands of such properties in the manifest. So if we can think of a way that could also encompass that sort of use case, perhaps it could be slightly preferable?

Overall I am not very happy with the way property settings work in the data extension protocol, it might be worth a more thorough overhaul in future versions. When I proposed to add the data extension protocol to the reconciliation API, others from the OpenRefine team suggested we use a full-fledged query language such as GraphQL, which would get rid of this issue, but I was reluctant for the following reasons:

• implementing a full GraphQL service might be hard for services, even if there are libraries for that in many languages now;
• that would make it harder to make the API tailored to OpenRefine's data model (for instance, for services to returned reconciled values, which are sort of OpenRefine-specific)
• services might not want to expose the full expressiveness of GraphQL through their OpenRefine API, because this has a cost for them;
• it would be harder to build an intuitive UI for data extension: there are no chances we can capture the full GraphQL expressiveness in a graphical UI. If we have a UI that only allows users to make a particular sort of simple queries, it would be waste to require services to implement GraphQL in full without exposing that to the users;
• generally speaking it would be inconsistent with the current simplicity of the rest of the API…

But of course that's a choice we can reconsider!