Solid Practitioners

We are starting up a new hub for Solid developers actively working on
projects aimed at end users.  Please visit
https://github.com/solid-contrib/practitioners/ and add your feedback on
the proposal.

I envision this as providing regular meetups where developers can discuss
their projects and share code and ontology work.  Questions and feedback
relating to the specifications would not be the main focus and will be
referred to the CG.

Please add your feedback to the github discussions or chat room listed at
the link above rather than replying to this email.

-- 
Jeff Zucker



On Tue, Oct 31, 2023 at 5:53 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> út 31. 10. 2023 v 13:47 odesílatel Nicolas Chauvat <
> nicolas.chauvat@logilab.fr> napsal:
>
>> Hi List,
>>
>> Le Tue, Oct 31, 2023 at 01:37:47AM +0100, Melvin Carvalho a écrit :
>> > Just covering this one point for now.  So a big design decision is
>> files vs
>> > database.  NSS is files, for example.
>>
>> Say I have an application that records contacts as first name, family
>> name and postal address and another application that records contacts
>> as first name, family name and phone numbers.
>>
>> With documents / LDP, my understanding is that each app will write the
>> first name and family name in two different documents /
>> triple-containers... and there we have two data silos within a single
>> pod.
>>
>> Unless... both apps agree on a common data model and share the same
>> document/triple-container, but then let's talk about that third app that
>> deals with contacts and has its reasons not to use the same data model
>> in whole... and we are back to two data silos within a single pod, one
>> used by two apps and the other by the third app.
>>
>> With a graph database, I would expect to have a single graph where to
>> store everything and that the two data models are just views/parts of
>> the whole graph (possibly with on-the-fly model mapping or inference
>> to share data between similar models). Of course, for it to work in
>> the real world where not everything is public, I need a mechanism to
>> authorize the access to parts of that graph.
>>
>> Using the above arguments, I fail to see why one would want to walk
>> the files path instead of the database one.
>>
>> Could someone explain to me why the files option seems reasonnable and
>> for which use cases ?
>>
>
> 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?
>
>
>>
>> --
>> Nicolas Chauvat
>>
>> logilab.fr - services en informatique scientifique et gestion de
>> connaissances
>>
>