Getting all links to an item through the REST API

Hello, everyone!

Right now, if I retrieve an item through the REST API, using “api/items?id=30”, I can get all of its object properties and the ids of the items that they point to. However, the incoming connections aren’t listed. Is there a way to obtain that information through the API?

I tried doing something like “api/items?property[0][type]=res&property[0][text]=30”, but it doesn’t work (it simply lists all the data, as if there were no parameters). If I use “api/items?property[0][property]=315&property[0][type]=res&property[0][text]=30”, it seems to work, but, as expected, it only lists the items connected to item 30 through an specific object property (with ID 315).

Considering that I’m currently using the Records in Contexts ontology, items can be connected through several different object properties, making it impractical for me to check every single possible property. For that reason, I would like to ask if there is a way to retrieve all connections TO a specific item through the REST API, regardless of the object properties being used.

I’m currently using Omeka S, version 3.1.0.

Edit: just to provide proper references to anyone stumbling on this topic in the future, search based on property value is covered here (under “Parameters for RDF resources”) and here.

1 Like

Yes, it’s something we do want to implement. Thankfully the JSON-LD spec provides reverse properties, so it shouldn’tbe too much of a problem to include. Thanks for the feature request.


Hello! Thank you for your answer! It is great to know that it is a feature already being considered!

However, right now, is there some kind of way to get all the items connected to an item without having to provide a specific property ID?

Using specific property IDs, I could expand the example I provided in my previous message to include multiple conditions, joined by “or”, like in property[0][property]=315&property[0][type]=res&property[0][text]=30&property[1][joiner]=or&property[1][property]=339&property[1][type]=res&property[1][text]=30, where I get all items connected to item 30 through properties 315 and 339. However, I ask because it isn’t an appropriate approach in my case, because there are hundreds of possible object properties and, if I included all of them in a request, the parameters would have several thousand characters (the small example I just gave already has 160 characters) and I would face problems with the server or with the browser.

No, there is currently no way to do this using the API or the search interface. The only way to get the reverse properties of an item is the “Linked Resources” section of the item show page.

1 Like

I really thank you for your answers! Tomorrow I’m going to check how I could modify the theme I’m currently using to provide that information in proper way for me to use. I might also check if I can create a module to extend the API to support my use case, but I’m not really confident with this particular approach because I’m not familiarized with Laminas.

Once again, thank you for your support!

Note that this is already implemented in module Advanced Search.

One extra clarification: you don’t have to narrow a “property” search to a specific property. If you set the “property” sub-key to 0 the search is across all properties.

Thank you Daniel_KM and jflatnes for your answers!

I just tested here and, using api/items?property[0][property]=0&property[0][type]=res&property[0][text]=30 I apparently got all items with object properties pointing to item 30 (regardless of the object property being used).

As for the module Advanced Search, interestingly, I already had it installed here in my test environment. With it, I managed to get all items linked from and to item 30 using api/items?property[0][property]=0&property[0][type]=lres&property[0][text]=30&property[1][joiner]=or&property[1][property]=0&property[1][type]=res&property[1][text]=30.

I really thank you all for your support!

With advanced search (last version), you can try types “lex”/“nlex” (is a linked resource) or “lres”/“nlres” (linked with resources with id). There is a pull request too for Omeka (