On each instance, we could have an agent listening for incoming search requests.
Such a request could be like: GET http://search.localhost:8001/users?skills=12,33&city=toulouse (localhost:8001 represents the instance 1).
The agent would use comunica to query the indexes on its associated instance:
If there is no result the agent return a 404 (for example).
If there are results, the agent writes them in a document on the POD of the instance. This document is returned to the caller and could be reused later to respond to the same query (if data did not change). Is it useful?
The app would be querying the whole federation like...:
GET http://search.localhost:8001/users?skills=12,33&city=toulouse
GET http://search.localhost:8002/users?skills=12,33&city=toulouse
...
GET http://search.localhost:8032/users?skills=12,33&city=toulouse
...And gather the results like it want.
The agent discovery could be done thanks to a predicate in the instance WebID or anywhere else defined by the client-to-client standard.
The agent could advertise it's search URL thanks to a dedicated ontology.
The agent could implement LDP paging to return only a subset of the results. For instance, a querying app could ask for at most 5 users on each instance of the federation:
GET /users?skills=12,33&city=toulouse HTTP/1.1
Host: search.localhost:8001
Accept: text/turtle
Prefer: return=representation; max-triple-count="5"
On each instance, we could have an agent listening for incoming search requests.
Such a request could be like:
GET http://search.localhost:8001/users?skills=12,33&city=toulouse(localhost:8001 represents the instance 1).The agent would use comunica to query the indexes on its associated instance:
The app would be querying the whole federation like...:
GET http://search.localhost:8001/users?skills=12,33&city=toulouseGET http://search.localhost:8002/users?skills=12,33&city=toulouseGET http://search.localhost:8032/users?skills=12,33&city=toulouse...And gather the results like it want.
The agent discovery could be done thanks to a predicate in the instance WebID or anywhere else defined by the client-to-client standard.
The agent could advertise it's search URL thanks to a dedicated ontology.
The agent could implement LDP paging to return only a subset of the results. For instance, a querying app could ask for at most 5 users on each instance of the federation: