Re: files or database for solid pods [Was: Towards Solid Lite]

On Tue, Oct 31, 2023 at 03:26:46PM +0100, Sjoerd van Groning wrote:
> Op 31/10/2023 om 14:31 schreef David Mason:
> >On Tue, Oct 31, 2023 at 01:52:50PM +0100, Melvin Carvalho wrote:
> >>    You've described a use case that requires merging, and given a beautiful
> >>    example of how a triple store makes merging cheaper.** I agree.
> >>    However making merging cheaper comes at a cost.
> >>    Now I need a whole data base infrastructure of use cases that dont require
> >>    merging.** Such as storing a document.** Saving a note.** Creating a
> >>    profile, and so on.
> 
> That deviated quickly from a simpler spec (Solid Lite) to new features.
> Please don't kidnap threads this way. Lite means cutting stuff out.

I'm sorry if it seemed like I was "kidnapping" a thread. It is hard for many
people to have full depth on these topics, which makes revisits inevitable.

I should make it more clear that I was not proposing new features. I was
proposing that interfaces are supported (auth, authn, authz, query, update),
with very basic implementations provided, and I talked about interesting
use cases that could be built on that, for 2023. Perhaps with a more
streamlined spec, others could add additional features such as those outlined
that would show how the very high level of information re-use and graph/linked
data features are compelling compared to other systems. The window of
expectations is shifting in the mainstream based on broad graph features.

> For the current spec I think a filesystem is a very logical and not complex
> solution, making implementation a lot easier.

imo the proposition is really reduced if no database is included /
made natural, in fact I was shocked when I realized it wasn't an immediate
Solid concern, but I could just be in the wrong place (-:. Without a database,
there will quickly be cases of conflicts / duplication between one idea of
contacts, for example, and another. imo the opportunity is to create coherence
around documents and data.  WhatsInAPod talks about the kinds of disconnects
that will happen if it's all documents.  

> The whole DB versus FS discussion brings back the blog from Ruben:
> https://solidlabresearch.github.io/WhatsInAPod/

This is interesting because, from my read, it seems to point to a graph
approach, not file, not "classic" linked data, though it's not clear what graph
implementation is meant.

> In the end requiring every small bit of data a separate access list would be
> technically challenging (but not impossible ofcourse) and very difficult for
> a consent list UX.

I guess in the simplest implementation there would be two access levels,
as a single user instance, logged in or not, at the resource level, in classic
unix terms "u" or "o". 

> Here are some thoughts we had about it:
> https://www.linkedin.com/pulse/solid-do-we-need-little-helpers-sjoerd-van-groning/
> https://www.linkedin.com/pulse/solid-different-views-linked-data-sjoerd-van-groning/

Helpers sound kind of arbitrary, using GraphQL/CouchDB...  And transformers, I
can see where you are going, after all internally apps can use whatever data
format they want, but I think there is value in driving things to
interoperability and providing a very consistent approach to access control. If
every View (handler?) is responsible for this, chaos might result.

Is this approach because of inadequacies in current "pure" Linked Data
components, libraries, tooling?

> I am very interested in feedback on our thoughts about it. We prefer a
> filesystem. Much easier (especially for Solid Lite).

I hesitated before sending this email because I really am not an expert and
have not been following this space closely, so I'm going to drop it if I'm
going nowhere. But I hope the lite with interfaces idea makes sense. A
filesystem with helpers, transformers, views for any kind of non-basic
functionality could also be compatible with the idea of interfaces
for different concerns.

David

Received on Tuesday, 31 October 2023 19:51:39 UTC