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

On 10/31/23 3:51 PM, David Mason wrote:
>
> 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
>

Hi David,

I encourage you to think in terms of storage abstraction where DBMS 
(Tables or Graph based Relations) vs Filesystems are implementation 
details.

Solid should be storage agnostic leaving such details to server 
implementers. As you can already see, whenever the discussion steps out 
of the appropriate abstraction layer -- confusion reigns supreme.


My $0.22 :)

-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Home Page:http://www.openlinksw.com
Community Support:https://community.openlinksw.com
Weblogs (Blogs):
Company Blog:https://medium.com/openlink-software-blog
Virtuoso Blog:https://medium.com/virtuoso-blog
Data Access Drivers Blog:https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers

Personal Weblogs (Blogs):
Medium Blog:https://medium.com/@kidehen
Legacy Blogs:http://www.openlinksw.com/blog/~kidehen/
               http://kidehen.blogspot.com

Profile Pages:
Pinterest:https://www.pinterest.com/kidehen/
Quora:https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter:https://twitter.com/kidehen
Google+:https://plus.google.com/+KingsleyIdehen/about
LinkedIn:http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal:http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
         :http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this