Search UI returns multiple positive results based on register item text about ukl-registry-poc HOT 3 CLOSED

Yes the multiple positive hits are effectively from _red:2 through _red:5.

Agreed that some form of consolidation would be better, not trivial to do but will add this to the list. This is a UI issue more than an API issue.

This has nothing to to with named graphs/default graphs. Each time an item is registered a separate search index term is created pointing back to the item. This is a lucene index and not part of the triple store. There are 4 hits because only 4 of the 5 items which have been know as _red had a label "reddish", the first one had label "red".

Initially when an item was updated I updated the text index so a search for reddish would only return one hit. The problem is that you would then never find "red". So now all versions are indexed and the API attempts to consolidate.

from ukl-registry-poc.

"""This is a UI issue more than an API issue."""

Agreed.

"""There are 4 hits because only 4 of the 5 items which have been know as _red had a label "reddish", the first one had label "red"."""

Agreed that the first version of the register item for /def/colours/red would not be found when searching for "reddish". However, the point I was making was that it also did not find the triple in NAMED GRAPH /def/colours/_red:2#graph ... from the SPARQL query panel I can see that the following triple exists therein:

</def/colours/red> rdfs:label "reddish"@en .

Would this have made the 5th "hit"? (if NAMED GRAPHs are also being searched?)

from ukl-registry-poc.

The index is not over triples. It indexes each item based on the item label which in turn is a copy from the entity description in the named graph. The search results are based on entity lists (as specified) so the UI can't link from the entity to a specific item version in the index.

I've arranged for duplicate suppression in the search results but retain the indexing of each historic version.

from ukl-registry-poc.