search

gbif / gbif-api

GBIF API
Apache License 2.0
28 stars 5 forks source link

Update rank enumeration #148

Open mdoering opened 2 weeks ago

mdoering commented 2 weeks ago

The Rank enum hasn't been updated in a while, with the latest version of the rank vocabulary living in the name-parser-api project. Should we keep updating the gbif-api version from the name parser one or would it make sense to simply inherit/use the name parser one? ChecklistBank is already build on top of the name parser api.

djtfmartin commented 2 weeks ago

FWIW i've been removing references to the gbif-api Rank enum in favour of the rank vocab living in the name-parser-api project. This includes the work on matching-ws, key-value-store, pipelines, occurrence repos for col / multi-taxonomy support.

CecSve commented 2 weeks ago

@djtfmartin it is not the plan to use the resource on the vocabulary server?

mdoering commented 2 weeks ago

@CecSve many java code I know of uses methods and features of the Rank enumeration which the vocab server cannot supply. Personally I don't think we should force all vocabularies to the vocab server and the java enums provide some benefits we would otherwise lose (e.g. methods, distinct versions bundled with code, reproduceable tests, persistency by ordinal, name changes, ...). But we should be very clear for which vocabulary it is being used and not manage the same kind of vocabs in different places. Maybe we should all sit together once more and discuss pros/cons to come up with a plan when enums and when the vocab server is to be used? For checklistbank work I am certain I can never get rid of the java rank enumeration without a huge fallout.

CecSve commented 2 weeks ago

Yes, I would appreciate that. I am not proposing that the vocabulary server resources should always be used but a clear plan would be good. Next year, I plan to migrate the rest of the vocabularies to the vocabulary server. In the initial phase, I can make a list of the vocabularies and we can all sit down and go through it.

MattBlissett commented 2 weeks ago

Perhaps we should add a new type of vocabulary to the vocabulary server, backed by a Java enumeration, so we can use the vocabulary server for managing parsing/matching and translations, but not defining the English terms.

(Although before anyone implements this, we need to check what we actually need and how it would be used.)