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

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

Received on Wednesday, 1 November 2023 10:24:20 UTC