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

st 1. 11. 2023 v 2:42 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
napsal:

>
> On 10/31/23 9:23 PM, Melvin Carvalho wrote:
>
>
>
> st 1. 11. 2023 v 2:02 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
> napsal:
>
>>
>> On 10/31/23 5:54 PM, Nicolas Chauvat wrote:
>> > Le Tue, Oct 31, 2023 at 03:41:40PM -0400, Kingsley Idehen a écrit :
>> >> That's exactly how we use Solid atop our Virtuoso platform (which is a
>> DBMS,
>> >> WebDAV file server, Middleware combo). Basically, you can work using
>> >> fileystem interaction patterns while the underlying data is accessible
>> via a
>> >> number of interfaces and returned in a variety of negotiated formats.
>> > We tried to do the same a few months back, based on our own semweb
>> > framework <https://www.cubicweb.org> but we got lost in what seemed
>> > like a maze of specs in which we did not manage to trace a clear path
>> > to reach our goal within the time we had available.
>> >
>> > My guess is that other people would be tempted to give a shot at their
>> > own implementation with their preferred toolset and that there is
>> > value in having a clear reading path for implementers in that set of
>> > documentation / recommandation / test suite.
>> >
>> > Is that a problem that Solid-Lite would address in some way ?
>> >
>>
>> I certainly sense that's the goal of a Solid-Lite i.e., a simpler spec
>> that enables broad implementation.
>>
>
> Broad implementation of course a goal, facilitated by an easy set of
> requirements
>
> Looking at it in reverse, an easy, bug-free server implementation will
> inform the elements that are selected, at least at first, for solid lite,
> from the bigger Solid spec
>
> There is a caveat that timbl has always said that http:// and file://
> spaces are part of the web.  I'm sure this is part of the original vision.
> The web space and file space working together in a read-write way.
>
>
> I take a photo on my phone, it goes into my shared folder, and my friends
> get a notification.  This seems quite fundamental?
>
>
> That can all happen with any underlying storage specificity. A server
> implementer can pull that off by just implementing interfaces (from a spec)
> as they see fit.
>
> The spec, and what's deemed simple or hard are separate things.
>
> A reference implementation shouldn't be affected by any of this, it just
> needs to be implemented by whoever is so motivated to do so etc..
>
>
>
> So if this is not mandatory, it should be in one of the early optional.
> I'm not 100% convinced it's not mandatory, maybe Tim will say one day.  But
> it's fine to compromise on this issue.
>
>
> The only thing that should be mandatory is an ability to perform
> read-write operations using a protocol where the following are
> loosely-coupled:
>
> 1. Identity
>
> 2. Identification
>
> 3. Authentication
>
> 4. Authorization
>
> 5. Storage
>
>
> If an implementation results in JSON-LD being stored in a filesystem with
> regards to points 1-5, then so be it; likewise, if the data ends up in a
> DBMS. These details simply shouldn't matter.
>
> If a group of motivated individuals seeks to build an implementation, then
> of course, among them, these storage preference issues require some kind of
> team agreement. However, that shouldn't have anything to do with the spec
> they are implementing.
>

Sounds good.  I've tried to capture some of the feedback into a motivation
document:

The simplest possible subset that can make a viable server should be the
starting point.

https://solid-lite.github.io/draft-spec/MOTIVATION

I think it could be done in a way that gives everyone what they want by
combining modules tested against the test suite.

I'd love clarification from Timbl whether he thinks file:// is core to
solid or not.  But ultimately that's an implementation detail, that could
be a unit test, I suppose.

Other than that, I dont see much in the way of blockers.


> Kingsley
>
>
>
>
>>
>> --
>> 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
>>
>>
>>
> --
> 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
>
>