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

st 1. 11. 2023 v 13:19 odesílatel Aron Homberg <aron.homberg@mailbox.org>
napsal:

>
>
> Am 01.11.2023 19:25 schrieb Melvin Carvalho <melvincarvalho@gmail.com>:
>
>
>
> 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.  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 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"?
>
>
> I think the idea behind always having at least one MUST is that when
> there's only SHOULDs, two servers could meet that are incompatible with
> each other (one only talking e
> g. RDF vs. the other only talking JSON) and this would probably be the
> worst case.
>
> This is why in all protocols I know there is at last one MUST for the data
> format.
>
>
> 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.
>
>
> Well, in the modern frontend world, we'll much more likely see actual
> HTML/CSS generated based on some JSON that has been fetched from a server.
>
> In the modern web we usually have user data going over the line, encoded
> as JSON, and then there's some JavaScript framework rendering the actual
> HTML/CSS. This might be React, Vue, Svelte, Angular, you name it. Nowadays
> we often see SSR and SSG techniques involved and static rendered
> HTML/CSS/JS/* files might exist, but these aren't "user data" by
> definition. It's more like a build result. So, the question of "How is my
> data presented in the browser" is usually considered to be the
> responsibility of the frontend, not the server.
>
> The server, however, would often still serve the static files that make up
> the codebase of the frontend, such as the JS framework source code, some
> data files, config files, images and an initial index.html. Sometimes,
> depending on the frontend framework, also more pregenerated HTML files (SSG
> case).
>
> To have support for serving that, it would probably be enough to just
> define that  static files can be served by the HTTP server "as is", just
> like any typical webserver would behave, when a file in the serve directory
> on disk is matching the path in the URL bar (=> URI exact match).
>
> For example, if / is acessed on the server, index.html will be served
> which would reference some app.dj385k.js file which has the built and
> bundled code to fetch data from the server and render it. And
> app.dj392.css, for example, would have the built and bundled CSS of the
> frontend. A favicon.ico file that remains in the same folder would be
> fetched by the browser to show the favicon and so.
>
> I hope I managed to explain it welll enough. I might come up with a very
> basic implementation to make a little example.
>

Yes, very well explained.  I should clarify

What I meant more specifically was.  If you click a hyperlink, AFIAK
there's no way to change the accept header so that you dont request HTML.


>
> It might be helpful to experiment with different ideas in such a codebase
> to see the cause and effect early on, while specing.
>
>
>
> There may be a flaw in this logic!
>
>
>
>
> Kind regards,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  * Sponsorship: https://ko-fi.com/drjones
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
>
>