VOCAB review: new unified vocab for LengthMeasurementType

[odontaster]

RDBES requires a few more codes for the same concept, and RMG suggests to try to use the same CodeType. In the near future single codes can be linked to specific databases so even if the list is longer, a governance group can decide to not allow some of the codes. https://github.com/ices-eg/DIG/issues/174

Governance group should also agree to have this new Code Type without AC_ (new vocab web features will allow visualization of lists for specific databases in a easy way)

[HjalteParner]

@odontaster this step forward (or backward perhaps) is not trivial as applications relying on this vocabularies will need to implement a new business logic i.e. not to look at codes which isn't relevant - including the work needed on vocab.ices.dk itself btw.

It doesn't really help what a given governance group agrees on, if it's not implemented in practise, so we need to be careful here.

[odontaster]

We really need a discussion on this, we are trying to make ICES databases as FAIR as possible, and again, "I" goes for interoperability. Acoustic database should find a way to adapt to changes that might not be 100% related to their content, but will allow interoperability and coherence in the bigger picture. We can discuss on timelines, and also maybe on improvements on how to communicate changes in the format to stakeholders in an efficient manner.

[odontaster]

@HjalteParner it is too bad that the decission to unify vocabs as much as possible came not too long after the ceration of very neat acoustic vocabs, but I really think it is a step forward, maintaining several lists with almost the same (but not exactly the same) codes makes no sense at all, not only from a maintenance perspective but also for an external user.

[HjalteParner]

@odontaster we just need to think carefully about this. As an example, if you have a list of fruits and one dataset makes use of all fruits while another one makes use of only the citrus fruits, what's the right way to handle this? Is it to change the business logic of the vocabulary and the app that uses citrus fruits only so one filter has to be applied both for the users, vocab and app or is it to create another list with only citrus fruits that's linked to the overall fruit lists? Now the app using all fruits are happy as well as the app using only citrus fruits, both without any change needed. And what would be the FAIR benefit of only having one list which need a complex business logic to be used from different apps with different needs and no other apparent links whatsoever.

All I'm saying is that we need to separate out concerns and keep it simply stupid ... in my point of view.

But lets discuss :-)

[HjalteParner]

@odontaster another example, what if one set of users understands one thing by a given term, while another set of users (community) have another understanding of the presumably same term by spelling? How should this be handled? Should we try to change the understanding of the same term by spelling, or should we just create two lists having the same term by spelling but not same definition by understanding and then not do a linking?

Again I would go for the latter, to be FAIR

But lets discuss :-)

[HjalteParner]

@odontaster I have raised above in RMG at https://github.com/ices-eg/DIG/issues/303

[CiaranOD]

Needs update from those proposing

[odontaster]

The vocab to which I referred has changed a lot and is not fit for purpose https://vocab.ices.dk/?codetypeguid=0984da4e-e781-4cb3-96f8-043dbe6aea58 It would be more complex for the submitter and I would not reccomend that.