Codes say they're in NUTS scheme but don't show up when building the tree top-down

[kiramclean]

This causes some search results to return an empty codelist. E.g. search "Geography" for "wales" to see this:

The reason the NUTS scheme appears but is empty is because the search returns some codes that are marked as being in that codelist, but don't appear when the tree is built from the top-down (which is how we currently fetch the data to build the tree UI).

---

In case it's helpful, these are the steps I did to get a hold of the relevant data and convince myself of what's going on (I did these from a repl with the namespaces from ook.search.elastic.codes loaded):

• search for the code with id http://data.europa.eu/nuts/code/UKL

  (esd/search (esu/get-connection "http://localhost:9200")
                                    "code" "_doc"
                                    {:query 
                                     {:match {:_id "http://data.europa.eu/nuts/code/UKL"}}})

• Note http://data.europa.eu/nuts/scheme/2016 is included in the schemes for that code (which is the "NUTS - Nomenclature of territorial units for statistics classification (2016)") one with the problem here)
• Note it has no topConceptOf, so follow the broaders up:

  (esd/search (esu/get-connection "http://localhost:9200")
                                    "code" "_doc"
                                    {:query 
                                     {:terms 
                                      {:_id
                                       ["http://data.europa.eu/nuts/code/UK"
                                        "data/gss_data/trade/international-trade-in-services-by-subnational-areas-of-the-uk#concept-scheme/location/nuts"]}}})

• Doing this again (following the broaders of those) never turns up the http://data.europa.eu/nuts/scheme/2016 scheme

[Robsteranium]

I think this might be a mistake in the data. What I have loaded locally includes the jsonld equivalent of:

<http://data.europa.eu/nuts/code/UK> skos:topConceptOf <http://data.europa.eu/nuts/scheme/2016>

I believe this should solve the problem.

The gap was likely caused by the previous loading behaviour as with #69 (where unordered limit/offset paging wasn't contiguous).

We should look to confirm this once the current pipeline run is complete.

[Robsteranium]

The new data didn't resolve it, but #107 did (incidentally).