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.

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