solid / solid/data-interoperability-panel

Standardise content negtiation

Open
#21 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

proposal
Dominant language
Bikeshed
Stars
58
Forks
18
PR merge metrics
No merged PRs in 30d

Description

I propose that we set out some conventions for content negotiation.

There are two forces at play:

  1. The POD owner has full control over what and how data is stored and accessed.
  2. An app provider needs to respond to this while at the same time provide common set of features that has a data shape in mind.

My experimental example is an app that works with the bookmarks that were originally created by MarkBook's application.

I can currently move from webid via publicTypeIndex on the profile to the location of the bookmarks. My app keeps it own data shape in order to drive its UI. So I have the location of the data on a users pod and I have my apps shape requirement. But there is a lot more that I need:

  • Is the location a single file with mixed content, some of which are bookmarks; or a directory of individual bookmarks; if it is a directory, is it recursive?

Once I understand this, I can build the graph of the data and perform sparql queries on it. But I need much more information to round out the functionality of the app.

  • Should I expect the users data to be in the shape of my app? If not, where do I find the graph that describes the mapping between the app's expected shape and the user's actual shape?

  • What should I do in the case where the two shapes have some overlap but either the app shape or user shape or both have predicates not in common?

  • How do I provide an identity to new subjects with that type?

  • How do I replace data, both modified and new on the user's POD in a manner consistent with the user's expectations?

Contributor guide

No contributing guide indexed for this repository

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

Start with the issue's questions about content negotiation, POD storage locations, data-shape mappings, identity for new subjects, and replacing data. Review the linked MarkBook example, the profile and publicTypeIndex path, and the proposed SPARQL queries. Done means documenting conventions that answer each question consistently.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.