Unique flag not working?

[danmichaelo]

I would expect one result here, but get three: https://skosmos.biblionaut.net/rest/v1/search?query=nanomedi*&unique=true

(Btw. my Skosmos installation is at @2947b94c434)

[osma]

The problem is that there are no hints in the REST query about which language to prefer. All three languages end up having the same priority. If you add a labellang parameter you will get just one result:

https://skosmos.biblionaut.net/rest/v1/search?query=nanomedi*&labellang=nb&unique=true

Note that the labellang parameter doesn't restrict the matching to that language. This also gives essentially the same result even if it matches only the English label:

https://skosmos.biblionaut.net/rest/v1/search?query=nanomedic*&labellang=nb&unique=true

Not sure if this is a bug or a feature, at least it should be documented somewhere.

[danmichaelo]

Aha, mainly a documentation issue then. The behaviour is acceptable once you understand it, but it's not straightforward intuitive :)

[osma]

It surprised me too! I think this might still be a bug, but I haven't yet investigated in detail why this happens.

[osma]

Even if the REST query doesn't specify any language, we could fall back to the default language of the vocabulary, as is done for other REST methods.

[danmichaelo]

Seems like a good idea. Even if documented, the current behaviour could still be confusing in the standard UI:

[osma]

The REST call made by the UI doesn't set the unique flag at all, so it is not directly affected by this issue.

This is done deliberately, in order to not hide matches from the user. For example, if the query in your screenshot only showed a match for "Nanomedisin"@nb, the user might erroneously conclude that "Nanomedicine”@en and "Nanomedisin"@nn are not in the vocabulary. We've had situations like this before and have decided to opt for showing all the matches, even though there are duplicates.

[osma]

This actually doesn't affect the current development version anymore, probably as a side effect of the refactoring done in #393.

finto.fi is running v1.4-maintenance and shows the problem:
http://finto.fi/rest/v1/yso/search?query=ufolog*&unique=true

dev.finto.fi is running current master and doesn't have the problem:
http://dev.finto.fi/rest/v1/yso/search?query=ufolog*&unique=true

Unfortunately the refactoring in #393 is extensive, it cannot be backported to v1.4. If this is a real problem for current 1.4 usage then we can consider making a quick fix (probably just identifying the situation where unique=true but no search language is given, and setting the label language to the default language of the vocabulary).

[danmichaelo]

Cool, I'll pull in the latest version then.

[osma]

I've verified that the language now always defaults to the vocabulary default language, so this problem should be fixed for good in 1.5.