You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we don't always provide a SPARQL endpoint to SemApps instances, it would be important to at least be able to filter LDP containers (and AS collections !), which is where SPARQL is the most relevant. The ldp.container.get action already accept a filter param, but it is not available on the API.
We have several options:
With a ShEx shape
Pass a SHACL/ShEx shape when GETting a LDP container, so that only resources matching the shape are returned.
Sarven comment:
Interesting. Typically GET is not used that way, i.e., passing a URI for the server to use / look-up. I can imagine that might be a security issue for a server, especially if they're to use anything unknown. But then again, even things like HTTP signatures have a pubkey that can be a URI... so I don't know entirely where things stand out there.
Could you dig into if/what the SHACL WG may have discussed on this matter? That could be useful input for us.
Alternatively, POST can be used since the payload would give the instructions to process something, but that's not particularly what you are looking into either.. as you seem to want a subset of some information from a resource. Which is why I thought of the Prefer header.
I think a SPARQL query may be most fit for the purpose.
Unfortunately there seems to be no spec available to do a SPARQL query only on a single resource or container. Libraries like Communica allow it, but they fetch the resource/container, and then apply the SPARQL query. What we would need is to do that on the server side.
With Linked Data Fragments
The Linked Data Fragments server is too heavy for this use case, and we would need to develop a WAC extension like we did for Fuseki. But we could use the LDF spec to query the container itself.
Use case mentionned here: filter followers/following list by keywords (we would need to dereference the actors), so that we can quickly search through followers when we want to mention them.
If we don't always provide a SPARQL endpoint to SemApps instances, it would be important to at least be able to filter LDP containers (and AS collections !), which is where SPARQL is the most relevant. The
ldp.container.get
action already accept afilter
param, but it is not available on the API.We have several options:
With a ShEx shape
Pass a SHACL/ShEx shape when GETting a LDP container, so that only resources matching the shape are returned.
Sarven comment:
https://www.w3.org/TR/ldp/#prefer-parameters
https://www.w3.org/TR/ldp/#prefer-examples
https://www.w3.org/TR/ldn/#constraints
https://solidproject.org/ED/protocol#constraints-problem-details
Would require some kind of Shape-to-SPARQL converter
With a SPARQL query
Unfortunately there seems to be no spec available to do a SPARQL query only on a single resource or container. Libraries like Communica allow it, but they fetch the resource/container, and then apply the SPARQL query. What we would need is to do that on the server side.
With Linked Data Fragments
The Linked Data Fragments server is too heavy for this use case, and we would need to develop a WAC extension like we did for Fuseki. But we could use the LDF spec to query the container itself.
See https://linkeddatafragments.org/specification/triple-pattern-fragments/#http-based-implementation
With a custom Header or query string
If all other solutions fail, we can always use a custom header or query string.
Related issues
search
parameter to the LDP container service #235The text was updated successfully, but these errors were encountered: