Getting a single property of many resources in a container


Hi there!

I have a container containing many resources that all have (“name”) and (“text”) properties. I’d like to get a list of the name values without having to retrieve all of the text values from the server - I anticipate the text values getting very large and the list of resources getting pretty big, so I’d like to be able to display all the names without downloading all the text.

It seems like it’s theoretically possible to do this by executing a SPARQL query against each resource in the container, but when I tried to do this using LDFlex like:

for await (const resource of data[containerRef].ldp_contains) {
  console.log("name", await data[resource][])

I can see in the network tab of my browser’s debugger that the full resource representations were all transferred in their entirety, including the text values.

Is this possible now? It seems to me right now that this is theoretically possible but perhaps not fully supported by the server and client implementations in February 2020 - is that right or am I missing something?

Thank you!


Why not store the text in a document of its own and have the main document point to it. Something like

<> :name "foo"; :hasText <uriOfTextDocument>,

Another option, though this may change with the spec is to use the .meta file of the container. E.g. for container foo in foo/.meta, list the name of the files. The names can now be retrieved by reading the container.


Ah yea - that might work well for me.

I’m generally interested whether a “get a partial representation of many resources in a container with a single query” pattern is something the Solid spec writers/implementors anticipate supporting in the future or whether this is a Linked Data antipattern that I should move my brain away from :slight_smile:


Unfortunately no, at this point in time it’s not possible to fetch partial Documents or fetch multiple ones in a single request. The Query Panel seems to concern itself with that, but I’m not sure how active that is. I wouldn’t expect anything in this area anytime soon, anyway.


It is currently part of the specification¹, but NSS (the mainly used pod server for now) never implemented it². Also note that it is not clear if it will stay in the spec, there is at least one PR suggesting to remove it³. For now I’d suggest you to split your file up and/or use client side SPARQL.

If NSS would follow the spec you could use “a subset of SPARQL 1.1” in a similar way to this:

# SELECT * WHERE { ?s ?p ?o . }
GET /data/?query=SELECT%20*%20WHERE%20%7B%20%3Fs%20%3Fp%20%3Fo%20.%20%7D HTTP/1.1
  1. Spec:
  2. NSS:
  3. PR for removing SPARQL Get from spec: