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

Quoting Melvin Carvalho (2023-11-01 12:25:08)
> st 1. 11. 2023 v 12:08 odesílatel Jonas Smedegaard <jonas@jones.dk> napsal:
> > 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.

It would surprise me if the original idea did not more generally imply
that you have profile links on the web in the *user agent*.

That may sound like nitpicking above, but in the very next sentence
below you derive from your choice of framing above that HTML content is
essential, which really it isn't when talking about "user agents" more
generally.

Also, funny enough, what sparked this conversation is an emphasis on
JSON, which is tied to contemporary non-HTML-based APIs.


> So the only way you can click on a hyperlink in the browser is to get back
> HTML.  AFAIK there's no other options.

Even within those constraints you establish (looking only at human users
and only when interfacing with the web through "browsers"), I see other
options. Popopular ones (as popularity seems to influence your choice of
constraints) are browser plugins where you click on widgets in the
browser chrome, and JavaScript-rendered content that may *internally* in
the web browser make use of HTML but rarely as *interface* uses HTML.
Both plugins and JavaScript commonly interface using JSON APIs.

Until 6 years ago, a popular plugin framework internally used RDF, and
it was not far-fetched to imagine that being extended to also become
popular also for network interfaces.  Mentioning here since you yourself
tie your reasoning to the historical roots of Solid.


> So if you want to support the browser, and you want profiles that you can
> click on, you have to support HTML.

I disagree with your MUST above.

I would instead phrase it as "..., you really should not ignore HTML".

I.e. a SHOULD, but no need for a MUST.


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

If by "pretty much mandatory" you mean "not exactly mandatory", then I
find it flawed in a conversation about absolutes or not to use phrases
like "have to support HTML".


 - 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