Add links to narrower terms

[doerners]

From a users perspective it would be nice to be able to browse every hierarchy direction, i.e. to follow links for broader as well as narrower terms.
Context: The GND does link to narrower terms or data entries of them, respectively under the designation "Untergeordnet" (see e.g. http://d-nb.info/gnd/4195058-6), however, to get to the subordinate data-entries you need at least two klicks which is not too user friendly. It would be nice if a more direct linkage could be present within the lobid-gnd web interface as well as the graph visualisation.

@acka47 from checking the RDF representation of the data entry it seems to be an upstream issue.

[acka47]

Thanks for the request, @doerners! It looks like this is a subissue of #142 but it sounds like a good use case to start with (instead of directly showing all the resources that point to a displayed GND resource).

Generally, we won't need additional data upstream as we can query lobid-gnd for all the entries pointing to an entry with a specific property (see below).

Interestingly, in this case two different "broaderTerm" properties are used to relate the eight subjects subjects shown in the DNB catalog with "Kirchentonart"/4195058-6:

• broaderTermGeneral (obal in MARC21): result list, GND Ontology
• broaderTermGeneric (obge in MARC21): result list, GND Ontology

This should probably be unified in the source data but as I said, we could generally add this.

[b2m]

It is confusing that there are generally no results for the relations narrowerTermGeneral, narrowerTermGeneric, narrowerTermInstantial and narrowerTermPartitive.

For example you may use the lobid GND API for OpenRefine and narrowerTermGeneral is available e.g. for data reloading but always empty.

[acka47]

It is confusing that there are generally no results for the relations narrowerTermGeneral, narrowerTermGeneric, narrowerTermInstantial and narrowerTermPartitive.

You are right, these properties are apparently not used in the GND Linked Data, see http://lobid.org/gnd/search?q=_exists_%3A%28narrowerTermGeneral+OR+narrowerTermGeneric+OR+narrowerTermInstantial+OR+narrowerTermPartitive%29

I assume, that there are more properties like this that are defined in GNDO but not in use. In this concrete case, I am not sure whether these properties make any sense at all (do they have a counterpart in MARC21?) or whether they also might marked as deprecated.

However, in the past, there already had been other properties that hadn't see any usage but have been used be at a later point. So it make some sense for us to generally support all GNDO properties. @b2m, it would make sense, though, to open a ticket for removing properties not used from the suggest API of the reconcilation endpoint at suggest/property. Please do so if this behaviour is a problem for you.

[b2m]

The properties narrowerTermGeneral, narrowerTermGeneric, narrowerTermInstantial and narrowerTermPartitive do not have counterparts in MARC21 as they are defined as the owl:inverseOf the broaderTerm*-group.

flowchart LR
    broaderTermGeneral
    narrowerTermGeneral

  subgraph broader
    broaderTermGeneric
    broaderTermInstantial
    broaderTermPartitive
  end
  subgraph narrower
    narrowerTermGeneric
    narrowerTermInstantial
    narrowerTermPartitive
  end
  broaderTermGeneral <--inverseOf--> narrowerTermGeneral
  broaderTermGeneric <--inverseOf--> narrowerTermGeneric
  broaderTermInstantial <--inverseOf--> narrowerTermInstantial
  broaderTermPartitive <--inverseOf--> narrowerTermPartitive

  broaderTermGeneric & broaderTermInstantial & broaderTermPartitive --subPropertyOf --> broaderTermGeneral
  narrowerTermGeneric & narrowerTermInstantial & narrowerTermPartitive --subPropertyOf --> narrowerTermGeneral

Loading

So yes, removing them from the suggest/property endpoint would be one solution.. calculating them based on the broaderTerm*-group and supporting them as properties would be the preffered one 😁 .

[acka47]

So yes, removing them from the suggest/property endpoint would be one solution.. calculating them based on the broaderTerm*-group and supporting them as properties would be the preferred one

We should probably do both as I assume there are other properties that are not inverses and that are not used in the data. (This is even more probable if we use the up-to-date version the ontology with some added properties – which is another task...)

We will start with this issue and add inverse statements of broaderTermGeneral and its subproperties.