search

hbz / lobid-gnd

UI and API to the Integrated Authority File (Gemeinsame Normdatei, GND)
http://lobid.org/gnd
Eclipse Public License 2.0
26 stars 5 forks source link

Use generic abbreviatedName property insted of specific ones #229

Open acka47 opened 5 years ago

acka47 commented 5 years ago

First, the generic property has to be added to GNDO. From https://github.com/hbz/lobid-gnd/issues/228#issuecomment-531223305:

I opened an issue at https://jira.dnb.de/browse/GND-112 and will open another issue here for using the property instead of the specific properties as soon as it is added.

acka47 commented 3 years ago

The property will be added to GND Ontology on 2022-02-08, from the announcement:

Neuerung: Die generische Property „gndo:abbreviatedName“ vom Typ „owl:AnnotationProperty“ wurde eingerichtet.

acka47 commented 2 years ago

The property is now part of GNDO. Removing "upstream" tag and assigning @fsteeg to implement the change in the data. (We will probably have to discuss whether we should retain statements with specific properties to not break any applications.)

fsteeg commented 2 years ago

Use generic abbreviatedName property insted of specific ones

I think we should add the generic property but retain the specific ones, which seem to be still used instead of the generic one, e.g. https://d-nb.info/gnd/600110-5/about/lds.rdf. Even if that changes with the next baseline dump, the specific properties are still in the ontology, so we should keep supporting them.

Deployed to test, see https://test.lobid.org/gnd/context.jsonld (but no data yet).

acka47 commented 2 years ago

Even if that changes with the next baseline dump, the specific properties are still in the ontology, so we should keep supporting them.

I don't agree. We don't support specific properties for preferredName, see #3 and should not do this for other name properties if we want to be consistent. As the needed information is given with type, the specific properties add redundancy which we do not need.

fsteeg commented 2 years ago

I don't agree. We don't support specific properties for preferredName, see https://github.com/hbz/lobid-gnd/issues/3 and should not do this for other name properties if we want to be consistent.

Right, I think I get what you mean. If we'd do it like for preferredName, we'd no longer have the specific fields in our data, and therefore wouldn't have to support them in the context or the reconciliation queries.

But, as you wrote yourself above:

(We will probably have to discuss whether we should retain statements with specific properties to not break any applications.)

We basically can't be fully consistent if we don't want to introduce an API break here. And if we keep the old specific properties, we don't gain much by adding the generic one.

We might consider the API break, but as hinted in #227, I think doing it the right, consistent way for all these *Name properties would be in the current DNB (or a new MARC-to-JSON) transformation. Implementing that first here, and then the clean way later seems like redundant work.

Though it's probably not that much effort, if you feel that adding the generic property would be a big gain.

acka47 commented 2 years ago

As discussed offline, we aim at the consistent approach for all name properties, i.e. using *Name only and getting rid of specific versions like *NameOfTheCorporateBody but will not implement this right now.