Investigate creating new interface for file/sparql store backends

We should look into generalizing ResourceStore behaviour. E.g. if one of them rejects setting a Representation at a certain URI because there already is a container there, we want this to be consistent across stores. One idea is to have a DataResourceStore which handles all this behaviour and takes as input a DataAccessor (names totally up for change). DataAccessors would then have functions such as hasResource, createContainer, setResource, etc. which can be used to implement the behaviour. In the case of a file data accessor for example, hasResource would be implemented by fs.lstat, while in the case of a sparql backend it would be an ASK query.

The main question is if this can be done (cleanly) without losing any functionality. We would have to investigate which functions would all be needed and to make sure there is no drastic change in efficiency because of this.

Some potential issues I though of (but there probably are plenty more):

• Probably need a different function to write a Representation and its metadata since metadata is always going to be a Quad array while a Representation can be anything (unless there is some way to also handle this in the DataResourceStore).
• SPARQL stores only accept Quad streams as Representation, so there still needs to be a way to handle cases like this.
• PATCH/modifyResource calls probably still have to be sent directly to the accessor since in the case of SPARQL these get sent directly to the endpoint.

[RubenVerborgh]

Note: deleteSpecificResource can be deleteDocument (resources in LDP are either documents or containers).

[RubenVerborgh]

OK with your proposal at https://gist.github.com/joachimvh/e0e4cf89b5c889cfb81e331503c2af20

I would just give DataAccessor method names that are on the low level, such as read[Data], write[Data], change[Data], delete[Data].

Plus we need a detailed comment on DataResourceStore explaining how this design works, and its performance trade-off. (I would also name it DataAccessorBasedStore or so.)