solid / solid/specification

Querying multiple subjects in one request

Open
#162 4 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

category: new functionality doc: Ecosystem topic: querying
Dominant language
HTML
Stars
563
Forks
108
Avg merge
4d 13h
Merged PRs (30d)
3

Description

In an RDF based app I was working on, we started out with a RESTful RDF API where the client used one request to fetch one resource (one GET to each subject). This was quite costly, since every HTTP request has some overhead, and in many single page views, many resources would need to be fetched. To fix this, we implemented a 'bulk-API' which basically boils down to an endpoint where you could post a body of new-line-deliniated URLs, and the server would reply with one large n-triples document that contains all the statements for the requested subjects. Not a pretty solution, but it helped make the app faster.

Currently, most solid apps work like our old API: one request per subject. In order to provide a snappy UI, we need a more performant way to query pods.

Options

SPARQL endpoint

SPARQL is a very powerful query language that will definitely solve this problem, but it can be hard for new developers and costly on the server. Exposing a SPARQL endpoint is often not a great solution for production apps.

TPF endpoint (+ multiple subjects!)

Triple Pattern Fragments were designed as a easier, low-cost SPARQL alternative. However, the spec does not allow for querying multiple subjects in one request. If we allow multiple subjects in the subject field, this would the the aforementioned usecase.

Perhaps there are other options, would love to hear your thoughts.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by comparing the proposed SPARQL and TPF approaches, including how multiple subjects would be represented in one request and the response format. Done means the project has agreed on a concrete querying approach and the corresponding specification scope.

Written by the indexing model from the issue text.

Assessment

Domain
api, backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.