Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add links to narrower terms #289

Open
doerners opened this issue Jun 7, 2021 · 5 comments
Open

Add links to narrower terms #289

doerners opened this issue Jun 7, 2021 · 5 comments
Assignees

Comments

@doerners
Copy link

doerners commented Jun 7, 2021

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
Copy link
Contributor

acka47 commented Jun 7, 2021

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:

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

@b2m
Copy link

b2m commented Jul 5, 2022

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
Copy link
Contributor

acka47 commented Jul 14, 2022

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
Copy link

b2m commented Jul 14, 2022

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
Copy link
Contributor

acka47 commented Jul 14, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants