change of observatory contacts

[isanti]

There was a change of
contact_name
contact_email
contact_orcid

Options:

1. add the new name, email, orcid and remove previous ones. Are they saved in earlier versions of the metadata logsheets is github? Will we know when the change happened?
2. add terms contact_name_old (or similar) for the past contact details and use contact_name for current contact details. I guess we would need to know until when the contact_name_old was active. So we should add another term for this??
3. ignore this, keep the previous contact. Emails and information would be redirected from the previous contact to the new contact. Risky!

@cpavloud @kmexter opinions?

[kmexter]

hmm, this is in the observatory tab I assume?
It depends on what you want the contact information to be related to

1. we want to know who is the contact for event that happen at a certain time - so if last year was contact a, then we need to retain that contact information for all data of last year, and the new contact is associated with all events of this year, etc
2. we only ever want one contact for all and any events from any date - then we only ever need one set of contact information

To answer your questions
1- they are saved but we will not know they have changed unless we look for it manually. do we want an alert of this type? I think it is better that the alert comes from the station to you, rather than in the logsheet, however
2- we only need to do this if we want the old contact to be potentially contacted about data/events from the timeframe in which they were a contact. I think it is easier to manage this manually
3- we should either have all (previous) contacts and the new one, or the new contact only, I would say

[cpavloud]

Could we have two new columns in the observatory sheet, e.g. "contact_valid_from" and "contact_valid_until", or maybe only the "contact_valid_until" column, so that we can record until when each contact person is responsible for the observatory?
If we do that, we could copy the observatory details in a second line in the logsheet and change only the contact related columns. @kmexter I think this could be easy to code, i.e. you could easily check which line would correspond to which sampling campaign and retrieve the correct metadata. What do you think?

It could be something like that (small preview with hidden columns to make it more visually appealing)

[isanti]

Or we could have just a "valid_until" column, which will refer to all info in this row. When we have a change in the observatory variables, we create a new row including all observatory info and updated with the only the new info where necessary. This is because in the future changes might be in other variables too.
This way the first row will include all info valid until "valid_until" date. Second row will contain again all observatory info updated as necessary. This time in second row will include all obs info same as the first row and only the contacts will be changed.
Sometime in the future we will have contacts and coordinates changed (because something might happen in the site), and this will create a new third row with only the contacts and coordinates changed.

[kmexter]

so then everything in a row is valid until the date given, and all events up to that date are assigned this info?
can be done, but I think it will require a change in the emobon ontology as we assumed that the observatory info never changed. @laurianvm can you comment?

[kmexter]

Some important questions
1- do we want the old contact details to be linked to the old events, or only the new contact details? if we want the old ones to be retained with the old events, then indeed we need to document both old and new contacts people, but if not then we do not
2- what else can change and the observatory retain the same name? Can anything chance - lat, long, depth also? currently we have these as fixed properties of an observatory and hence an event, but do we need to accommodate possible changes of every parameter except the observatory name and ID?

[cpavloud]

We want the old contacts to be linked to the old events.

Coordinates and depth might also change, as in Ioulia's example above.

[kmexter]

handing over the @laurianvm to see how to implement this in our data model/ontology before we agree on how to make the change in the googlesheets and then the QC scripts and the templates to conver to ttl.
Because this will need changes to all stages of the data workflow - not big changes, but lots of them - I would like to know what your priority for this is, @isanti

[isanti]

medium or low priority
Data linked to the new contact will arrive much later (2026?). This can wait for end of 2025 or something.

[kmexter]

has something already been changed in the googlesheets or they will only change at end of year? the first comment sounds like a change has already happened?

[isanti]

I haven't changed them in the logsheets. I am waiting to see what we decide here. But the change has happened in real life. Although, the data associated with the new contact_name will be in batch 6, which is far from producing data.

@isanti When the contacts change in the logsheets, we should also update this https://github.com/emo-bon/governance-data/blob/main/observatories.csv and https://github.com/emo-bon/governance-data/blob/main/logsheets.csv