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

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


>
> >
> > I believe I understand your concern, in that it (unlike backend storage
> > handling) directly affects interoperability.  But still I disagree with
> > mandating any single serialization.  What is a MUST to me is merely
> > reckognition that multiple serializations exist, while allowing
> > relevancy of each to vary over time and between domains.
> >
> > Classic HTTP also didn't mandate GIF, and we can be thankful for that.
>
> Right, it's good that we have many image formats. File formats are
> standardized to solve different optimization problems (=>
> encoding/decoding/transcoding problem), usually to address file size,
> quality, and features. Serialization formats target optimization problems
> in network protocols.
>
> If we try to find a comparison here, let's maybe compare protocols with
> protocols, not file formats. I'll pick HTTP for simplicity. Usually, the
> early and simple versions of network protocols did not come with a
> "container serialization formats" model that would allow for more than one
> serialization format.
>
> HTTP defined clear text. Even when, back in the day, every byte weighted
> more on the line, the decision was made for one popular, most easily
> adoptable choice. It could have been easily decided for something
> protobuf-like, or a dual-mode spec that would allow for more than one
> serialization format in the protocol.
>
> I believe that the complexity of HTTP would have skyrocketed in case there
> would have been more than one serialization format. The first webservers
> were buggy even with only clear text -- that's one of the  reasons why
> Apache was created and got this name in the first place, when I remember
> correctly... :)
>
> Well, I would just like to express my unpopular opinion again: If the door
> is open for more than one serialization format, then I believe, they will
> come. After RDF/Turtle, a few more popular choices will knock on the door
> as well. At what point will "Lite" still mean "Lite"?
>
> I absolutely agree with the idea that it's good that we have many
> serialization formats for (linked) data. They all fulfill a purpose and
> they are all doing their own job pretty well.
>
> But the "Full Solid Spec" already has that and Solid Lite focuses on
> simplicity, right?
>
> And although I think, that there are plenty reasons for why RDF fits in
> perfectly as a primary serialization format, JSON is still the most adopted
> serialization format, that most developers know and understand very well.
> Solid Lite shall attract developers and get traction? Well, then maybe we
> better choose for the low entry barrier format?
>
> I think that we can agree, that supporting more than one serialization
> format would eventually add complexity, and result in code sizes to grow
> for Solid Lite implementations? There's also a whole class of error, called
> "data transformation bug potential" that can be eliminated by focusing on
> one serialization format.
>
> If simplicity and attractiveness for newcomers is truly the focus of this
> spec, I still believe, focusing on one serialization format, namely JSON,
> for it's popularity and wide-spread adoption, also across programming
> languages, would be a pretty good decision.
>
> Again, this is not "against" any other serialization formats. I believe
> that RDF/turtle etc. are important. But we already have the full-fledged
> Solid to support it?
>
> > That some user agents cannot render some visual artifacts of some
> > websites does not mean that those websites don't speak HTTP, only that
> > what they say is that their domain has handicaps for visually impaired
> > agents. At an extreme, a website *only* serving GIF content is
> > web-compliant.
> >
> > Some domains strongly rely on operating systems with POSIX filesystems,
> > whereas other domains strongly use ephemeral data exchanges.
> >
> > Some domains strongly rely on RDF/Turtle, whereas other domains strongly
> > use JSON-based data exchanges.
> >
> > You propose to render services that choose to only serve RDF/Turtle as
> > non-compliant with Solid-lite.  I find that an unnecessary constraint.
>
> Hmm, I think that I understand, where you're coming from. But I believe
> services that support RDF/Turtle already have implemented the means to
> transform from RDF/turtle to JSON (as this is a MUST in the LDP spec) too.
>
> Therefore, in practice, they wouldn't be non-compliant (if I'm not
> mistaken). They would just identify "Oh, there's a Solid Lite server" and
> transform to JSON -- done, it works; and vice-versa for incoming data from
> Solid Lite servers.
>
> > Please, pretty please, consider treating no single serialization format
> > as MUST, only use SHOULD for serialization formats.
> >
> > The web SHOULD be a welcoming place for all agents, but if all agents
> > MUST have eyes then we simply shift the unwelcoming part to be embedded
> > in the spec.  Unnecessarily.
> >
> >
> >  - 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
>
> Thank you and best,
> Aron
>
> ---
>
> Aron Homberg
> Web & AI Technology Expert
>
>
> 📅 Schedule a Meeting
> 📱 +49 170 5474455
> 📧 aron.homberg@fluctura.com
> 🌐 www.fluctura.com
>
>
> Precision Engineering in AI-Driven SaaS Solutions & PWAs
>