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

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.
>    Then there are things which a triple store cant do.** Such as saving my
>    family photos.** Storing a song or playlist.** Uploading a video.
>    The web started out by linking documents so it stands to reason that
>    flavours of solid should inherit this ability, in the general case.
>    Does it make sense?

I would completely expect both. The individual "documents" are a source for
the graph. Which is a feature, not a bug, once you've worked out
syncrhonization. Step one could be just to store metadata at the file level,
and use that for folder views and permissions. Then index for search, import
recognized data. 

Nicolas mentioned a graph database, which is different than a triple/quad
store. Linked Data naturally aligns to the latter. While it's new and
relatively untested, CozoDB is an interesting combination of graph (via
Datalog), search and vector storage that can be scaled up horizontally or run
in the browser. It's possible to build a quadstore on a Datalog database like
CozoDB, but that would be another project. I'm a bit fixed on CozoDB because it
seems like such a timely combination, but it would be incredibly interesting
to pair a Solid LDP with it. You would have the source documents with auth and
data management, search, reasoning, and semantic relationships via embeddings
in one system.

David

Received on Tuesday, 31 October 2023 13:31:35 UTC