accessURI listed as identifier for images

[CecSve]

I don't know if this is only happening in UAT, but for this example the accessURI is listed in the identifier field below the image although the information is correct in the multimedia section. Can the identifier under the image be similar to the identifier in the media extension?

@MortenHofft can you take a look?

[CecSve]

I can understand that the information can come from multiple fields if the publisher uses extensions and we only have one identifier field in the occurrence table for media. Perhaps for clarity, the UI could instead call the field below the image image link or something similar, so it does not clash with a potential field provided by the publisher containing another value.

I have also created a tech docs issue for this https://github.com/gbif/tech-docs/issues/92#issuecomment-2312372645.

[MortenHofft]

This is the information listed in the API https://api.gbif-uat.org/v1/occurrence/165680322

"media": [
{
"type": "StillImage",
"format": "image/jpeg",
"creator": "Christiaan de Vries",
"rightsHolder": "Christiaan de Vries",
"identifier": "https://observation.org/photos/88951456.jpg"
}
],

And this information is under the image

Creator Christiaan de Vries Rights holder Christiaan de Vries Identifier https://observati...otos/88951456.jpg

it is the exact same as far as I can see.

if you want to see the fill information available in the extension there is a section in the bottom https://www.gbif-uat.org/occurrence/165680322

The list of images is using the media field from the API which is a mapped version from various sources, simple multimedia and audiovisual extension. And they use different naming for fields. So no, I do not think they can be the same. But we could consider changing the API to only allow one way to provide images or always map them to audioVisual

[MortenHofft]

I actually like that we name things consistently between the api and the ui. I'm not sure that would be less confusing if it was called something else.

[CecSve]

using the media field from the API which is a mapped version from various sources, simple multimedia and audiovisual extension.

I think this part is what needs to be documented better.

I actually like that we name things consistently between the api and the ui. I'm not sure that would be less confusing if it was called something else.

Yes, I agree. I was just hoping it could be a UI fix and not an API fix, if needed. But if we could just point to documentation, I would not see a need for changing names of any fields.

[MortenHofft]

That said I agree that is is confusing that identifier do not mean the same thin in the two images standards. But perhaps someone should deprecate one of them then. I sound like I'm being contrary - sorry. I agree it is confusing. But I'm not convinced inventing new terms is a good idea.

How would you like the UI to display the information? are there help texts or other things we should point to?

[CecSve]

That said I agree that is is confusing that identifier do not mean the same thin in the two images standards. But perhaps someone should deprecate one of them then. I sound like I'm being contrary - sorry. I agree it is confusing. But I'm not convinced inventing new terms is a good idea.

How would you like the UI to display the information? are there help texts or other things we should point to?

Until we write up the documentation on the information, it may be relevant to include a small help text stating that the content of the field is derived from the internal mapping of supplied values in the core and extension tables?

[MortenHofft]

It isn't just one field though, but all over. There are also people publishing as ABCD. They use names such as RecordBasis and SiteCoordinates. Those are also mapped to other fields. So perhaps any such help text should be more generic?

[CecSve]

It isn't just one field though, but all over. There are also people publishing as ABCD. They use names such as RecordBasis and SiteCoordinates. Those are also mapped to other fields. So perhaps any such help text should be more generic?

Ok. Then a text stating something like?:

The image URL is derived from the GBIF-interpreted media-relevant values supplied by the publisher.

Then a link to tech-docs can be added once the pipeline process is documented.

[MortenHofft]

The image URL is derived from the GBIF-interpreted media-relevant values supplied by the publisher.

I find that quite hard to read and understand I must admit

[MortenHofft]

I do not imagine that users are particularly intersted in a lot of text explaining that the images on the page could have been published in 3 ways and those 3 approaches use different naming and we therefor map it into one common simplified form.

The only one that cares is probably the publisher that wonders why identifier has changed to be the accessURI if they published as audioVisual and now see new field names.

So it seems more like a generic section about how data is transformed as going into GBIF. ABCD names change. audiovisual names change. We populate fields based on other fields. We exclude some populated fields etc. It could be a section for publishers with a link to a faq item?

plastering the page with comments intended for the audience of 1 person seems like noise.

Or perhaps I'm underestimating the audience for this

[CecSve]

You are right, the explanation is hard to read and does not inform the reader. I still think it is worth documenting in tech docs, probably in different ways (but linked) in data publishing and data processing. Then perhaps the page can link to tech docs, but it may be unnecessary as long as we can point to information if more users notice the difference.