gbif / hp-new-zealand

Hosted portal for GBIF New Zealand
1 stars 0 forks source link

Add news posts -- Local Contexts/Biocultural Labels #18

Open AaronWilton opened 2 years ago

AaronWilton commented 2 years ago

create a high level news item for the GBIF_NZ portal about Local contexts

MortenHofft commented 6 months ago

Hi @AaronWilton Would it make sense to publish the Local Context project information in projectId field as a first iteration. That would give me some data to work with.

I know there is such a field for occurrences ( pipe separated | for multiple projects). And I believe there is also such a field in EML.

Occurrences/specimens If you added e.g. projectId: https://localcontextshub.org/api/v1/projects/106eeba8-1c47-410c-9cfd-89bcb5e22656then that would be enough (as far as I understand) to show project information such notices and labels on the occurrences that have Local context project identifiers.

dataset eml One or more project Ids in the EML would allow us to show notices on the dataset.

Allan Herbarium (CHR) for example could be our test dataset?

Does that sound like a meaningful approach to you please?

AaronWilton commented 6 months ago

HI @MortenHofft - this issue is about creating a news item/post for the hosted-portal about LC rather than linking records with a LC project.

I suggest we move this discussion onto a new item?

BUT no, i don't really like that approach.

WRT linking a data source to a local context project need to consider
1) there will be projects at different levels (full collection, parts of collections etc) 2) there will be multiple projects linked to specimens.

ie there is a many to many relationship here so I would not want to manage that thru IPT metadata (only) -> we need to do it through properties of each occurrence record (noting again this will be a 0 to many for each specimen - though for MWLR this will be a 1 to many as we include all specimens in at least a default project.)

I have been starting work towards a Local Context IPT extension - which I think would be the more appropriate way of passing this information.

While I think having the project id will be enough for GBIF to display labels dynamically, I am uncomfortable only including that level of detail in an archive/record - for example, there can be changes in labels over time & we need to preserve that information so there is transparency in the context that data was downloaded and used e.g., if data used in commercial context then a non-commercial label added later.

cheers A

MortenHofft commented 6 months ago

Thanks. The suggestion was never to only have it in EML. But support both options - dataset level or/and record level and multivalue as mentioned. But obviously neither would capture changes over time if that isn't reflected in the data - either in the LC API as a history of changes OR updating projectIDs in the published data if there is a breaking change.

Anyway, I will not do anything further at this point. And sorry for misreading the issue btw