specs

specs copied to clipboard

Would be nice to set some params globally, without having to add columns of fixed values.

#52 gives two examples:

• WD language
• OpenCorporates jurisdiction

Extra example:

• I'm reconciling places in Bulgaria. I'd like to add param country fixed to "Bulgaria"

These fixed params are very similar to "extra props" and need the same flexibility.

Requirements:

• Services should advertise their allowed params
• Services should suggest param names (like "Suggest property")
• After param is selected, services should suggest param values (like "Suggest class")
• Params should be configured at the recon service level, but can be changed per reconciliation
• Param values are global (not taken from the current record)
• The value check can be global (eg WD language), or related to the current record (eg jurisdiction, country)

#52 describes the current practice of hardcoding the param value in the URL

• We could capture this by using URL templates eg https://wikidata.reconci.link/api/{lang}
• But the insertion needs to go to the end, so there's a single service URL that can describe the param (https://wikidata.reconci.link/api)
• So the WD service still needs to be changed
• Therefore there's little benefit to accommodate the current practice

That's clearly something we need to improve. I agree with the aim to have a single URL for a given endpoint. URL templates are a problem.

Why isn't country just a property? The current OpenRefine client implementation which requires constants to be in a column is clumsy, but it's just a weakness in the implementation, not the spec. There's nothing preventing the client software from allowing the user to specify a constant property value without adding a new column.

The current Wikidata practice of requiring the language to be specified and only supporting a single language at a time seems limiting to me. Shouldn't we be shooting for a model where label language can be specified on a per-label basis (with the global language as a degenerate case)?

If I remember correctly it is also possible to specify the country as a property in the OpenCorporates recon service.

I think supplying languages string-by-string could be doable but not a substitute for specifying the preferred language of the user. At the moment, the language setting of the Wikidata recon service determines in which language the labels and descriptions of items are returned - not the language of the data to reconcile. The two are really different: I could want to reconcile data from a language I am not familiar with (pl) but have results returned in my native language (fr). The first language might indeed vary from query to query (I could have the language code in a separate column and supply that to the service), but I think it makes sense to keep the UI language constant.

Please comment about lang in the related issue, not here.

@tfmorris I agree that country should be a property (in my example, a global one). So these "fixed params" should be treated like service properties, but not related to any class.

And I agree that lang may vary per row, and even per cell! Please post that as a separate issue.

There's nothing preventing the client software from allowing the user to specify a constant property value without adding a new column.

I disagree that the protocol doesn't need to know whether a param is global or per-row. A global param may be handled more efficiently in the query to the underlying storage.

Having said that, your suggestion is an excellent work-around until we enrich the protocol to add "fixed params".

I think I can present another use case for such parameters: I am reconciling against SKOS concepts in conceptSchemes maintained by different user accounts. At least one of these levels (user accounts) introduces the possibility that the same entity appears in multiple (say, competing) collections. Currently, I am solving this by adding account and vocabulary query parameters.

Granted, the backend is one single flat index of concept items with account and vocabulary maintained in fact as properties of the concept items, but I consider this an artifact of the implementation and would prefer not to force this down the user's throat from whose point of view it might make more sense to see these things as nested collections.

For what it's worth, I thought I needed a way to signal to users what vocabularies (by which accounts) are available, so I have added an ­­- out-of-spec - field vocabs (it should probably be better, because more generically: collections) to my service manifest that contains an array of { id: <URI>, account: <String>, title: { <lang>: <String> }, description: { <lang>: <String> } } objects. Then the id is what can be specified in the vocabulary/collection parameter...