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

Kingsley, I agree with you. My point was that you could build A reference
implementation using Jena Fuseki, or Virtuoso, or DGraph, or Smart Dog.
There was a comment that each of these has some form of implementation
error that makes RDF a non-starter, but IF we are talking about needing
some form of data abstraction layer, then this shouldn't matter. My bigger
argument is that once you get outside of some RDF usage, there really isn't
any standardized entity relational model that has the same level of
adoption (I see OpenCypher as being weaker than RDF in that respect). File
systems by themselves are hierarchies (albeit DCGs rather than DAGs),
unless you talk about something like the Linux *ln* command for creating
links, at which point, they are graphs (DAGs).

*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>


On Wed, Nov 1, 2023 at 8:44 AM Kingsley Idehen <kidehen@openlinksw.com>
wrote:

>
> Hi Kurt,
> On 10/31/23 11:02 PM, Kurt Cagle wrote:
>
> I'd argue that you use Jena Fuseki as your reference RDF server, wrapped
> around nodejs as both principle service endpoint and as UX host. Keep the
> file system abstract as a property on the resource node. Use /fs/as the
> file system endpoint, with  /path/to/resource mapped to
> /fs/path/to/resource.
>
>
> Jena Fuseki is an implementation detail. This spec shouldn't include
> implementation details since the abstraction layer shouldn't be leaky.
>
> Implementation details that introduce product specificity == leaky
> abstraction.
>
> I made the following point earlier:
>
> We need clean spec that's abstract in nature.
>
> Teams seeking to implement the spec will naturally orient to their
> preferred implementation options for storage e.g., file system or DBMS.
>
> We have to keep the spec distinct from products otherwise it won't make
> any progress -- IMHO.
>
>
> Please do not strip the RDF from solid or solid lite.
>
>
> RDF is just standardization for entity relationships using a variety of
> notations and serialization formats. The letters R-D-F don't matter that
> much. What matters is that the structure of data is represented using an
> entity relationship graph.
>
> Solid is inherently about an entity relationship graph for structured data
> representation combined with a read-write abstraction where the following
> are loosely-coupled:
>
> 1. Identity
>
> 2. Identification
>
> 3. Authentication
>
> 4. Authorization
>
> 5. Storage
>
>
> It is honestly the only real good feature that Solid has. You can
> associate a Pouch DB database for JSON storage and a key/value for  store
> for binaries, if you do not use base64 encoding.
>
> I also would recommend creating a CLI to the node application that can be
> used to interact with the pod in either fs or rdf mode.
>
> Finally, incorporate a graphql endpoint. It's a relatively easy add and
> provides a level of discoverability that's hard to beat. File metadata can
> also be added at that time
>
>
> Many of these suggestions are for server implementation teams rather than
> generic spec design :)
>
> Kingsley
>
>
> On Tue, Oct 31, 2023, 12:46 Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> út 31. 10. 2023 v 20:41 odesílatel Kingsley Idehen <
>> kidehen@openlinksw.com> napsal:
>>
>>> Hi Melvin,
>>>
>>> On 10/31/23 8:52 AM, Melvin Carvalho wrote:
>>> > 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?
>>>
>>>
>>> A different angle:
>>>
>>> Triple Stores and Filesytems can exist behind a common abstraction layer
>>> provided by HTTP. This kind of abstraction is where Solid comes into
>>> play, by making such possible via Single Page Apps deployed via HTML.
>>>
>>> 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.
>>>
>>
>> Makes total sense.  That would be a great way to build client side apps.
>>
>> However a pain point right now is that it is hard to build a server, or
>> even find an existing server that is bug free.
>>
>> A specification to find a minimal subset of Solid to build a working, bug
>> free server, that passes tests in the test suite, is the challenge.
>>
>> The question is which parts of the spec could you take out, and still
>> have useful applications.
>>
>> Not everyone can build something like virtuoso overnight, so what
>> properties would create a minimal viable back end.
>>
>>
>>>
>>> --
>>> 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
>
>