Missing IDs array for PDF files in the thesaurus API response

albert__

Hello,

We are building the new exposition site for oroibidea.es using the thesaurus API, and we've run into a missing property in the API response for thesaurus terms.

Each term in the exposition thesaurus can have related PDFs, and the API currently returns two properties for them: pdf_resolved (an array of resolved URLs) and pdf_title (an array of titles), but there is no property with the raw array of IDs. We need this array so we can fetch each document individually or use the resolve_portals_custom request parameter to resolve them on demand, the same way we do with images and audiovisuals.
Could a pdf (or pdf_data) property be added to the thesaurus API response, returning the array of raw IDs for the related PDF documents?

As a side note, we noticed some inconsistency in the naming of these raw/resolved properties across different related content fields:

image (raw IDs) → identify_image (resolved URLs)
other_images (raw IDs) → other_images_resolved (resolved URLs)
location_data (raw IDs) → location (resolved names)

It would be great if a consistent naming convention could be adopted, like always using a _data suffix for the raw IDs arrays.

Thank you

Alex

Hi!

Yes of course, a pdf_data property is necessary... 🙂

It was introduced into the ontology:

2026-06-02T08:20:20+02:00
v 6.8.10

Update your installation to obtain it.

albert__ It would be great if a consistent naming convention could be adopted, like always using a _data suffix for the raw IDs arrays.

Yes... and we try to unify it, but, some definitions was done at the beginning of the diffusion ontology > 15 years ago and we can not change the current common definitions freely, because, is necessary to sustain current public webs. The question here is, how make a transition without breaking the current web development?

The community is thinking to change the API for the v7 (it really needs an upgrade) and maybe here we can define more clearly the rules as you say, and maybe, the common diffusion ontology must to be reference only and the projects should defines diffusion ontology by itself, with its rules, or the common projects rules... ????
What do you think?

Best

albert__

Thanks for the response.

It makes sense to avoid changes that could break existing sites, especially with definitions that have been in use for so long.

A v7 API would be a good opportunity to improve the current ontology. If a project has special needs, defining its own diffusion ontology is definitely the way to go, but it could be really helpful to keep a solid default ontology that works out of the box for simple projects and covers the most common fields and data structures.

Best