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

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"?

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).


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