Makes most sense for URI lookups (because they will have a higher hit ratio) but we may also want to cache search results.

Caching in a shared in-memory store (Redis) would be most efficient. We can begin with caching in each Node runtime separately.

Decided with @sdevalk to do #265 first, then come up with a generic caching solution that applies to term search and lookup as well as reconciliation requests.

If a source returns just one term, this term is ignored by the TermsTransformer, yielding an empty result set. For example:

./bin/run sources:query --identifiers cht --query rembrandt --loglevel info

The TermsTransformer wrongly assumes that the source contains more terms:

https://github.com/netwerk-digitaal-erfgoed/network-of-terms-comunica/blob/master/src/services/terms.ts#L37

We need to refactor this code a bit. Point of attention: terms arrive in a stream, so we don't know beforehand how many terms there are.

For example https://termennetwerk.netwerkdigitaalerfgoed.nl/?q=das&datasets=https://data.cultureelerfgoed.nl/PoolParty/sparql/term/id/cht returns ‘dassenjachten’ twice.

@sdevalk currently uses GitLab for this; we’d like to move all CI to GitHub to live with the code. GH caught up with GL’s CI capabilities; for instance, GH now has its own package registry.

Use GitHub Actions to build a container image after each push to master (which we then consider the stable branch) and push that to the GitHub container registry.

Kerken, Kloosters and Kapellen (K3).

A SPARQL endpoint should be delivered this week.

These will not be used by the Network of Terms due to performance issues, so let’s remove them from catalog.ttl. The NoT will use SPARQL only (for now).

Ref #42.

Regarding the network-of-terms-api repository as the central repository for the network-of-terms I would expect to find a high level overview of the Network-of-Terms functionality, maybe similar to what is being published in FAQ in the front-end. This would be very helpful for people from outside our network that are interested in our work.

The readme has a link to https://www.netwerkdigitaalerfgoed.nl/en/knowledge-services/usable-digital-heritage/network-of-terms/, but that page no longer exists. Can you fix the link to the correct page or perhaps replace it with a link to the (English) FAQ?

Currently, the catalog.ttl and .rq query files are read on each request. We can optimise this by reading and caching them on server start.

Term sources may time out (#210) or return erroneous responses. When this happens, it may be useful to store and expose an availability status for each source. That status can then be shown in the UI.

Proposal

• When a source times out when answering user queries, mark it is unavailable (in an in-memory store).
• When a source that has previously been marked unavailable responds again to user queries, mark it as available.
• Expose the availability status in the API so it can be picked up by clients.

Questions

1. Should we consider a source unavailable after a single timeout? Or n timeouts?
2. Should we include the status in the existing sources API call or create a separate endpoint?

/cc @EnnoMeijers @sdevalk

Currently the aat.rq search query requires prefLables to be defined as Dutch using the following non-optional clause:
?uri skosxl:prefLabel ?prefLabel_uri .
?prefLabel_uri dcterms:language aat:300388256 . # Dutch (language)

This leads to the problem that non-Dutch labels which are commonly used are not being found e.g. "alba amicorum' (http://vocab.getty.edu/aat/300374942). This is a Latin term that is commonly used for book categories but has no Dutch prefLabel which is probably correct because it is a Latin term. Is there a way to support finding these terms without flooding the results with hits from many different languages?

See the following example query in the README.md:
bin/run sources:query --identifiers nta --query "'Wier*'"

This returns the following error: Error: Invalid SPARQL endpoint (http://data.bibliotheken.nl/sparql) response: undefined

More example queries have problems, please check them or correct the README.

Instantiate service objects only once, and parameterise all required arguments in function calls on those service objects. This was started in #251 (comment), so ensure we apply this pattern consistently throughout the codebase.

@mielvds suggested Grasp as a way for the Network of Terms to manage its SPARQL queries. Graph’s use case is different: a single GraphQL query results in a single SPARQL query, whereas in the NoT we have different queries per endpoint.

Still, the idea of using templates to generate SPARQL queries is interesting.

Pros

1. We can move pre-processing from network-of-terms-api back to the catalog. This results in a better separation of concerns, as the catalog already knows about SPARQL endpoints. The API would no longer supply several query variants. Instead, the catalog calls the query variant functions as template functions.
2. We can reduce duplication in queries, particularly between lookup and search queries that are usually very similar.
3. Some operations that are impossible or very complex to express in plain SPARQL can be expressed in the template language.

Cons

1. Flat .rq files are easy to debug and collaborate on with third parties. Collaborators need to understand the template language and the (TypeScript) functions called from the templates to see what’s going on.

@EnnoMeijers What do you think?

https://docs.google.com/document/d/1AUeMAiBW_gNiWZM-OYJW-iY_zaDbalEriIPiDBxuQW4

https://reconciliation-api.github.io/specs/latest/

https://docs.openrefine.org/manual/reconciling

Questions

• Should we call each source simply by its name (e.g. ‘RKDartists’) or make it clear that the reconciliation is provided not by the source itself but by us (e.g. RKDartists via Termennetwerk)?
• Should we add our reconciliation sources to the list of public endpoints?
• Should we have another way for clients to discover our reconciliation service URLs? List of URLs is now available at https://termennetwerk.netwerkdigitaalerfgoed.nl/faq.

Progress

• #476
• #479
• #266

A proposal to restructure the Network of Terms repositories and code that we currently have:

• Rename this repository to network-of-terms.
• Use NPM 7 workspaces for a monorepo with the following structure:
  • catalog (= network-of-terms-catalog)
  • query (shared query logic), which requires catalog (and Comunica)
  • graphql (or graphql-api), which requires query
  • reconciliation (or reconciliation-api), which requires query
• Publish both catalog and query to NPM.
• Archive network-of-terms-catalog.
• Should we rename the packages from the unwieldy @netwerk-digitaal-erfgoed/network-of-terms-graphql etc. to @network-of-terms/graphql etc.?

A downside is the cascade of package updates if we make changes to catalog.

To make the contents of catalog better pluggable and easier to customise, we could apply a further subdivision:

• Make catalog purely RDF and add a web server (move TypeScript files from catalog to query).
• Host catalog as a separate app in the infrastructure; query then reads the catalog’s RDF from a configured HTTP address. Now query no longer has a package dependency on catalog.

When a single source fails, it causes all results to fail. Probably related to our use of Promise.all().

For instance:

query Terms {
  terms(sources: ["http://vocab.getty.edu/aat/sparql", "https://data.netwerkdigitaalerfgoed.nl/NMVW/thesaurus/sparql"], query: "griek*") {
    source {
      uri
      name
      creators {
        uri
        name
        alternateName
      }
    }
    terms {
      uri
      prefLabel
      altLabel
      hiddenLabel
      scopeNote
    }
  }
}

[2021-07-07T07:07:30.346Z]  INFO: Requesting https://query.wikidata.org/sparql {
  headers: {
    accept: 'application/n-quads,application/trig;q=0.95,application/ld+json;q=0.9,application/n-triples;q=0.8,text/turtle;q=0.6,application/rdf+xml;q=0.5,application/json;q=0.45,text/n3;q=0.35,application/xml;q=0.3,text/xml;q=0.3,image/svg+xml;q=0.3,text/html;q=0.2,application/xhtml+xml;q=0.18',
    'user-agent': 'Comunica/actor-http-native (Node.js v14.15.2; darwin)'
  },
  method: 'GET',
  actor: 'https://linkedsoftwaredependencies.org/bundles/npm/@comunica/actor-init-sparql/^1.0.0/config/sets/http.json#myHttpFetcher'
}
[[2021-07-07T07:07:43.010Z]  INFO: Identified as sparql source: https://query.wikidata.org/sparql {
  actor: 'https://linkedsoftwaredependencies.org/bundles/npm/@comunica/actor-init-sparql/^1.0.0/config/sets/resolve-sparql.json#mySparqlQuadPatternResolver'
}
[2021-07-07T07:07:43.014Z]  INFO: Requesting https://query.wikidata.org/bigdata/namespace/wdq/sparql {
  headers: {
    accept: 'application/sparql-results+json;q=1.0,application/sparql-results+xml;q=0.7',
    'content-type': 'application/x-www-form-urlencoded',
    'user-agent': 'Comunica/actor-http-native (Node.js v14.15.2; darwin)'
  },
  method: 'POST',
  actor: 'https://linkedsoftwaredependencies.org/bundles/npm/@comunica/actor-init-sparql/^1.0.0/config/sets/http.json#myHttpFetcher'
}
[2021-07-07T07:07:43.015Z]  INFO: Requesting https://query.wikidata.org/bigdata/namespace/wdq/sparql {
  headers: {
    accept: 'application/sparql-results+json;q=1.0,application/sparql-results+xml;q=0.7',
    'content-type': 'application/x-www-form-urlencoded',
    'user-agent': 'Comunica/actor-http-native (Node.js v14.15.2; darwin)'
  },
  method: 'POST',
  actor: 'https://linkedsoftwaredependencies.org/bundles/npm/@comunica/actor-init-sparql/^1.0.0/config/sets/http.json#myHttpFetcher'
}
Invalid SPARQL endpoint (https://query.wikidata.org/bigdata/namespace/wdq/sparql) response: undefined

Possible cause: breaking change in fetch-sparql-endpoint 2.0.0.

I checked out this package and it seems not to be working correctly with the latest vendor versions. 😢

Suggestions:

• Check in the package-lock.json to ensure we get a working setup any time in the future.
• Stick to Comunica 1.12.* for now, unless comunica/comunica#669 (a regression in 1.13.0) is fixed.

For the STCN Drukkers thesaurus new entities are defined when a printer moves from one place to another. For example printer http://data.bibliotheken.nl/doc/thes/p075573636 refers to Plantijn working in Antwerp and http://data.bibliotheken.nl/doc/thes/p075556251 refers to Plantijn working in Leiden. In the data this is expressed through the schema:addressLocality field. In the results the difference between both entities is not visibile. My suggestions is to add schema:addressLocality (if available) to the skos:scopeNote stating the locality of the printer.

Test our SPARQL queries with Comunica.

This is to prevent questions about the order that search results appear in. Our SPARQL CONSTRUCT queries preclude us from keeping the source’s ordering or providing our own ORDER BY. The sort should therefore happen on the client-side (resolvers?).

As noted by @sdevalk, https://github.com/netwerk-digitaal-erfgoed/network-of-terms-api/blob/master/src/services/terms.ts#L64 checks for SKOS version 2004 only. It should also support version 2008 (as predicateToPropertyMap already does).

https://homosaurus.org

Investigate the possibilities for inferring relations and add them to the CONSTRUCT queries. In many cases the relations are only unidirectional in the data. When browsing on URIs we could easily infer the inverse relations and present them so the user can follow the same path back.

Problem: our SPARQL queries are plain-text. How can we dynamically inject the terms into e.g. bif:contains clauses?

Optionally available in query data: netwerk-digitaal-erfgoed/network-of-terms-catalog#104.

The catalog is tested separately. What kind of tests can we add for the API?

1. Start with high-level, end-to-end tests against the GraphQL endpoint to get as much coverage as quickly as possible (forgetting about error localisation for now).
2. Can we provide a mock catalog with a local endpoint so we don’t depend on the availability of sources for our tests to pass?
3. The Register already has some Fastify tests, so have a look at those.

E.g. when quering AAT for ‘jan’ with our default LIMIT of 1000 chops off the result:

<http://vocab.getty.edu/aat/300164767> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .
<http://vocab.getty.edu/aat/300164767> <http://www.w3.org/2004/02/skos/core#prefLabel> "luchtvervuiling binnenshuis"@nl .
<http://vocab.getty.edu/aat/300164767> <http://www.w3.org/2004/02/skos/core#broader> <http://vocab.getty.edu/aat/term/1000486928-nl> .
<http://vocab.getty.edu/aat/term/1000486928-nl> <http://www.w3.org/2004/02/skos/core#prefLabel> "<vervuiling naar locatie of context>"@nl .
<http://vocab.getty.edu/aat/300164767> <http://www.w3.org/2004/02/skos/core#broader> <http://vocab.getty.edu/aat/term/1000486929-nl> .

As you can see, the last broader object (http://vocab.getty.edu/aat/term/1000486929-nl) gets no prefLabel, which breaks our GraphQL resolver.

As far as I know, this is normal behaviour in SPARQL: the LIMIT applies to the number of triples returned rather than the number of results (subjects).

How should we solve this?

• ignore related terms for which we have no prefLabel;
• or is there a way to solve this on the SPARQL query level?

At least a certain set of errors are scoped to the sources we query, which makes GraphQL’s top-level error property less suitable. Therefore, add types to our schema, introducing a union type Terms | TimeoutError | ServerError (or something similar). Clients can then conditionally retrieve results.

For inspiration: https://medium.com/@sachee/200-ok-error-handling-in-graphql-7ec869aec9bc and https://blog.logrocket.com/handling-graphql-errors-like-a-champ-with-unions-and-interfaces/.

Try to keep the query interface as simple as possible and not break BC.

Add support for skos:exactMatch and skos:related, see Brinkman thesaurus: https://data.bibliotheken.nl/doc/thes/p075598604

Experimented a bit, and a query like the following, which combines both query search and URI lookup, seems to work:

CONSTRUCT {
  ?uri <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept>.
  ?uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?prefLabel.
  ?uri <http://www.w3.org/2004/02/skos/core#altLabel> ?altLabel.
  ?uri <http://www.w3.org/2004/02/skos/core#hiddenLabel> ?hiddenLabel.
  ?uri <http://www.w3.org/2004/02/skos/core#scopeNote> ?scopeNote.
  ?uri <http://www.w3.org/2004/02/skos/core#broader> ?broader_uri.
  ?uri <http://www.w3.org/2004/02/skos/core#narrower> ?narrower_uri.
  ?uri <http://www.w3.org/2004/02/skos/core#related> ?related_uri.
  ?uri <http://www.w3.org/2004/02/skos/core#exactMatch> ?exactMatch.
  ?broader_uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?broader_prefLabel.
  ?narrower_uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?narrower_prefLabel.
  ?related_uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?related_prefLabel.
}
WHERE {
  {
    ?uri <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept>;
      <http://www.w3.org/2004/02/skos/core#inScheme> <http://data.bibliotheken.nl/id/scheme/brinkman>.
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?prefLabel.
      FILTER((LANG(?prefLabel)) = "nl")
    }
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#altLabel> ?altLabel.
      FILTER((LANG(?altLabel)) = "nl")
    }
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#hiddenLabel> ?hiddenLabel.
      FILTER((LANG(?hiddenLabel)) = "nl")
    }
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#scopeNote> ?scopeNote.
      FILTER((LANG(?scopeNote)) = "nl")
    }
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#broader> ?broader_uri.
      ?broader_uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?broader_prefLabel.
      FILTER((LANG(?broader_prefLabel)) = "nl")
    }
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#narrower> ?narrower_uri.
      ?narrower_uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?narrower_prefLabel.
      FILTER((LANG(?narrower_prefLabel)) = "nl")
    }
    OPTIONAL {
      ?uri <http://www.w3.org/2004/02/skos/core#related> ?related_uri.
      ?related_uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?related_prefLabel.
      FILTER((LANG(?related_prefLabel)) = "nl")
    }
    OPTIONAL { ?uri <http://www.w3.org/2004/02/skos/core#exactMatch> ?exactMatch. }
    ?uri ?predicate ?label.
    VALUES ?predicate {
      <http://www.w3.org/2004/02/skos/core#prefLabel>
      <http://www.w3.org/2004/02/skos/core#altLabel>
    }
    FILTER(((LANG(?label)) = "nl") && (IF("" != "", bif:contains(?label, ""), false) || ?uri IN (<http://data.bibliotheken.nl/id/thes/p07568439X>)))
  }
}
LIMIT 1000

The important bit is:

    FILTER(((LANG(?label)) = "nl") && (IF("" != "", bif:contains(?label, ""), false) || ?uri IN (<http://data.bibliotheken.nl/id/thes/p07568439X>)))

I also had to move the VALUES clause to the bottom of the query to prevent an – unexplained – Virtuoso 37000 Error SP031: SPARQL compiler: No suitable triple pattern is found for a variable $label in special predicate bif:contains() at line 59 of query .

The question is: is this query still maintainable enough?

Monitor and (publicly) graph the amount of queries executed per term source. We could use Prometheus.

See the first example query in the README.md:

Cultuurhistorische Thesaurus: query SPARQL endpoint

bin/run sources:query --identifiers cht --query fiets

This query returns an empty result set, it should list multiple terms containing 'fiets'.
I tested the query from the catalog direct on the CHT endpoint (https://digitaalerfgoed.poolparty.biz/PoolParty/sparql/term/id/cht) that worked fine.

I tend to default to the MIT license.

@EnnoMeijers @sdevalk Any preference?

A terminology source can be slow or unreachable. If it takes too much time to query the source, we should abort the request and inform the user about this. The default timeout of Comunica is 60 seconds, but this is too long for our use case. We should change this to e.g. 5 or 10 seconds.

If I send the query underneath to the Network of Terms...

https://termennetwerk-api.netwerkdigitaalerfgoed.nl/playground

query Terms {
  terms(
    sources: [
      "https://data.cultureelerfgoed.nl/PoolParty/sparql/term/id/cht"
    ]
    query: "kas"
  ) {
    source {
      uri
      name
      creators {
        uri
        name
        alternateName
      }
    }
    result {
      __typename
      ... on Terms {
        terms {
          uri
          prefLabel
          altLabel
          hiddenLabel
          scopeNote
        }
      }
      ... on Error {
        message
      }
    }
  }
}

...then an error is returned: Cannot read property 'id' of undefined.

bif:contains should be enclosed in quotes.

Last week's fix introduces a new bug:

If I execute the query...

bin/run sources:query --identifiers nta --query "Wieringa" --loglevel info

...the relevant part of the SPARQL query looks like this:

?label <bif:contains> "'Wieringa'"^^<http://www.w3.org/2001/XMLSchema#string>.

Although the apostrophe isn't necessary, this query returns terms. However, if I execute the query...

bin/run sources:query --identifiers nta --query "Wieringa OR Mulisch" --loglevel info

... the relevant part of the SPARQL query looks like this:

?label <bif:contains> "'Wieringa OR Mulisch'"^^<http://www.w3.org/2001/XMLSchema#string>.

This query doesn't return terms. The previous version of the code - without the fix - did.

The part of the SPARQL query should look like this, without apostrophe:

?label <bif:contains> "Wieringa OR Mulisch"^^<http://www.w3.org/2001/XMLSchema#string>.

My guess is that we should find a way to only add apostrophes if the search query of the user doesn't contain operators such as OR or AND.

The dataset identifiers that we now use are made-up (albeit common) abbreviations of dataset names, for instance ‘rkdartists’ and ‘cht’. Should we replace these identifiers with proper IRIs?

Some considerations:

• Short strings like our current identifiers look more familiar to GraphQL users than IRIs.
• When the number of term sources grows, identifier collisions become more likely, especially if they are provided by term source managers themselves rather than NDE.
• IRIs can be resolved for further information about the dataset, whereas identifiers are a dead end.

@sdevalk Should we allow identification only by IRI or also keep supporting the identifiers?

We can add some GraphQL comments that show up in the generated docs.

Use NTA (KB) for testing purposes.

When I perform the query:

{"query":"query Terms ($sources: [ID]!, $query: String!) {\n                terms (sources: $sources query: $query) {\n                  source {\n                    name\n                    uri\n                    alternateName\n                    creators {\n                      name\n                      alternateName\n                    }\n                  }\n                  result {\n                    ... on Terms {\n                      terms {\n                        uri\n                        prefLabel\n                        altLabel\n                        hiddenLabel\n                        scopeNote\n                        seeAlso\n                        broader {\n                          uri\n                          prefLabel\n                        }\n                        narrower {\n                          uri\n                          prefLabel\n                        }\n                        related {\n                          uri\n                          prefLabel\n                        }\n                      }\n                    }\n                    ... on Error {\n                      __typename\n                      message\n                    }\n                  }\n                }\n              }","variables":{"sources":["https://data.netwerkdigitaalerfgoed.nl/rkd/rkdartists/sparql"],"query":"Joan Miró"}}

I get the error:

Invalid SPARQL endpoint response from https://api.data.netwerkdigitaalerfgoed.nl/datasets/rkd/rkdartists/services/rkdartists/sparql (HTTP status 500):Virtuoso 37000 Error XM029: Free-text expression, line 0: Invalid character in free-text search expression, it may not appear outside quoted string at �SPARQL query:define sql:big-data-const 0 define output:format "HTTP+TTL text/turtle" CONSTRUCT {  ?uri <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept>.  ?uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?schema_name.  ?uri <http://www.w3.org/2004/02/skos/core#altLabel> ?schema_alternateName.  ?uri <http://www.w3.org/2004/02/skos/core#scopeNote> ?schema_description.}WHERE {  {    ?uri <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?type.    VALUES ?type {      <http://schema.org/Person>      <http://schema.org/Organization>    }    ?uri ?name ?label.    VALUES ?name {      <http://schema.org/name>      <http://schema.org/alternateName>    }    OPTIONAL { ?uri <http://schema.org/name> ?schema_name. }    OPTIONAL { ?uri <http://schema.org/alternateName> ?schema_alternateName. }    OPTIONAL { ?uri <http://schema.org/description> ?schema_description. }    FILTER(<bif:contains>(?label, REPLACE(REPLACE("Joan Miró", "[.,]", " "), "(?<!AND)(?<!OR)[[:space:]]+(?!AND)(?!OR)(?!$)(?![[:space:]])", " AND ", "i")))  }}LIMIT 1000

It looks like terms with diacritical marks must be quoted when passed to bif:contains: manually testing with url -H "Content-Type: application/sparql-query" -d '@/tmp/query.txt' https://api.data.netwerkdigitaalerfgoed.nl/datasets/rkd/rkdartists/services/rkdartists/sparql and the following query:

CONSTRUCT
  {    ?uri <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept>.
    ?uri <http://www.w3.org/2004/02/skos/core#prefLabel> ?schema_name.
    ?uri <http://www.w3.org/2004/02/skos/core#altLabel> ?schema_alternateName.
    ?uri <http://www.w3.org/2004/02/skos/core#scopeNote> ?schema_description.
  }
WHERE
  {
    {
      ?uri <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?type.
      VALUES ?type {      <http://schema.org/Person>      <http://schema.org/Organization>    }
      ?uri ?name ?label.
      VALUES ?name {      <http://schema.org/name>      <http://schema.org/alternateName>    }
      OPTIONAL { ?uri <http://schema.org/name> ?schema_name. }
      OPTIONAL { ?uri <http://schema.org/alternateName> ?schema_alternateName. }
      OPTIONAL { ?uri <http://schema.org/description> ?schema_description. }
      FILTER(<bif:contains>(?label, "Joan AND 'Miró'"))
    }
  }
LIMIT 1000

does work, while without the quotes it produces the error similar to the one above.

The new GTAA endpoint will require an authentication key. Currently, the Network of Terms doesn’t support authenticated endpoints.

@wmelder Can you elaborate a bit on what that authentication will look like? A single API key in an HTTP header or something else?

Some sources (for example WO2 Thesaurs, see https://data.niod.nl/WO2_Thesaurus/8176.rdf) have also topConceptOf fields, these could help to improve browsing through the relations in the new UI.

netwerk-digitaal-erfgoed/network-of-terms-demo#364

@sdevalk Do you agree?