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

On 11/1/23 7:25 AM, Melvin Carvalho wrote:
>
>
> st 1. 11. 2023 v 12:08 odesílatel Jonas Smedegaard <jonas@jones.dk> 
> napsal:
>
>     Quoting Melvin Carvalho (2023-11-01 11:41:36)
>     > st 1. 11. 2023 v 11:24 odesílatel Aron Homberg
>     <info@aron-homberg.de>
>     > napsal:
>     >
>     > > Hi Jonas,
>     > >
>     > > first of all, thank you for your feedback. That was an
>     interesting read
>     > > and it brought me to a few more, deeper thoughts. Please find
>     my comments
>     > > inline:
>     > >
>     > > > Jonas Smedegaard <jonas@jones.dk> hat am 01.11.2023 16:56 WITA
>     > > geschrieben:
>     > > >
>     > > >
>     > > > Quoting Aron Homberg (2023-11-01 06:51:07)
>     > > > > And ["serverless" environments lacking a filesystem
>     altogether] is
>     > > only one concern. What if the future lies within some sort of
>     federated
>     > > cloud storage based that we can't even imagine today? How could
>     > > implementation details like that ever be well-tested?
>     > > > [...]
>     > > > > To keep things simple, can we please simply speak JSON as
>     a MUST in
>     > > Solid Lite? (and maybe RDF and others as a SHOULD, not
>     enforcing it)
>     > > >
>     > > > I like your point that perhaps in future is becomes a major
>     drag.
>     > > >
>     > > > I dislike how you create a potential major drag by mandating
>     JSON.
>     > >
>     > > I just want to clarify that I'm solely coming from the place
>     that in order
>     > > to have a simple solution, the serialization format that is
>     the most common
>     > > in the industry (and likewise the one that has the broadest
>     library
>     > > support), seems to be, for my understanding, the best choice
>     for a "Solid
>     > > Lite".
>     > >
>     > > For newcomers (which was one of the intentions of Solid Lite,
>     to attract
>     > > them), it's already a bit of a learning curve to get into
>     > > linked data in general, JSON-LD, WebID, Solid-OIDC, and all
>     the related
>     > > concepts. This is why I'm simply trying to reflect on reality,
>     rather than
>     > > trying to create a major drag. If in reality, RDF would be the
>     more adopted
>     > > serialization format, I'd have voted for RDF in the first place.
>     > >
>     > > I hope this explains a bit better, where I'm coming from.
>     > >
>     >
>     > I think would be informed by 3 loose principles:
>     >
>     > 1 we should try to support standards
>     > 2 we should be as simple as possible but no simpler
>     > 3 we should be backwards compatible with the existing web
>     >
>     > The de-facto semantic web, as it exists today, is schema.org
>     <http://schema.org>.  Which is
>     > based on JSON-LD and HTML.  This is backwards compatible with
>     the existing
>     > web and has had enormous success.
>     >
>     > I think after all is said and done, both html and schema.org
>     <http://schema.org> type json will
>     > have to be supported to satisfy 1-3.
>     >
>     > Conversely, I dont think anything else ticks those 3 boxes. 
>     XHTML never
>     > caught on, and is not likely to in the next few years, if ever. 
>     Turtle
>     > seemed like a good bet at the time, but 10 years later, it's
>     failed to gain
>     > the adoption that we all hoped for.  Not to say that they are
>     bad or should
>     > not be included, they can be modules, aligned to the test suite,
>     as can
>     > n3.  A bit like lego bricks.  The lite spec will just be a set
>     of lego
>     > bricks put together in a certain way.
>     >
>     > We could inform ourselves by looking at the common crawl
>     statistics, but I
>     > think it's overwhelmingly going to point to a default being that the
>     > de-facto standards for the (semantic) are to use html and JSON(-LD).
>     >
>     > Remembering also DanC's words:  "The important word in Semantic
>     Web is
>     > 'Web'"
>
>     How are standards better supported by a spec requiring "MUST use JSON"
>     instead of recommending "SHOULD use JSON"?
>
>     How is it simplest possible and not simpler when a spec requires "MUST
>     use JSON" instead of recommending "SHOULD use JSON"?
>
>     How is is more backwards compatible with the existing web to have
>     a spec
>     require "MUST use JSON" rather than recommend "SHOULD use JSON"?
>
>     (Please not, that nowhere in above questions are implied any converse
>     requirements for RDF/Turtle nor RDF/XML nor any other dislikes of
>     some).
>
>
> A small addendum here.  I have thought about this problem for many 
> many years.
>
> One of the "ah ha" moments that I had was that most people use the 
> web, and even use solid via HTML.
>
> The original idea of Solid as "Social Linked Data" was to create a 
> social web using linked data
>
> Now that implies that you have profile links on the web in the browser.
>
> So the only way you can click on a hyperlink in the browser is to get 
> back HTML.  AFAIK there's no other options.
>
> So if you want to support the browser, and you want profiles that you 
> can click on, you have to support HTML.
>
> Supporting the browser and HTML seems to me also pretty much mandatory 
> if you want to be backwards compatible with the web.
>
> There may be a flaw in this logic!


How about this breakdown, to clarify the critical role of HTML:

1. Identity --  using resolvable identifiers (e.g., HTTP(S) schemes)
2. Identification  -- a profile document readable by existing Web user 
agents (i.e., HTML)
3. Authentication -- verifying claims in profile doc
4. Authorization -- acls expressed using entity relationships and tested 
against an authenticated identity
5. Storage -- to wherever via HTTP(S)

-- 

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