Standardise content negtiation

[SimonShapiro]

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?

[RubenVerborgh]

These are very important questions to raise. My preliminary view on some answers is in https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/, but other approaches exist.