@reiver @thisismissem @mfru

Here's the diagram btw: https://social.coop/@smallcircles/116113963712755122

The problem of #SolidProject knowing what it is, is more an inherited problem of #LinkedData / #SemanticWeb knowing what it is.

Semantic web always was "if only all information on the web were semantic and machine-readable, then...". And there it stopped. Presumably magic would happen.

And perhaps it would. But to make such a big leap, a paradigm shift of the entire web, along the way you have inspire a whole lot of people to set the (r)evolution in motion and keep it going.

If you look at what linked data is, it is a very low-level format. Nice if you have it, but now what are you going to build with it? There are some good application areas, but the case for linked data elsewhere is not a given.

Still today there are regular discussions on 'what would be the killer app for Solid' or linked data in general. Saw some interest for LLM's fed semantic data to make them more deterministic. I'm not interested.

@mfru @nextgraph @activitypods that sounds super interesting indeed, would love to know more!

@reiver @thisismissem @mfru

The chicken/egg of getting good tool support for Linked Data et al remains a serious issue.

The standards are complex and intertwined with each other in intricate ways. Regular devs need to be shielded from that, and have tools that allow them to focus on solving problems, building solutions, satisfying needs.

Without the tools, barrier to entry is real high. But because of that there are also less folks who build and improve tools.

Last problem that is important to mention, is more a social issue. The generalized "dev community" has made up their mind that they dislike linked data, just as they did before on XML, for instance. It is a particular mindset that has taken hold, caused by the first hype cycle around Semantic web, where it didn't deliver.

I'd advise anyone in LD space to incrementally prove value solution-side, and not emphasize too much on linked data as unique selling point. Alongside strengthen the ecosystem to get better tool support.

Hi @thisismissem,
yes, IMHO the question is, how big should the mental burden be implementing simple things?
Does AP want to be basic infrastructure, then it should strive to be basic.
I liked the line of thought of @mariusor in a chat with @steve on C2S complexity on C and S sides (keeping servers basic and let lients elaborate). Can't find the post right now.

> @smallcircles@social.coop said:
>
> the Solid team and Inrupt were not really interested in their community, hardly giving attention while people were building interesting stuff there.

Yeah, the Inrupt leader ship were all not startup people. They didn't get devrel or really startups. There were more managers at Inrupt when I left than people actually doing the work when I left. (at least, that's how it felt). I think after I left like 2-3 other people also had enough and left.

@mro@digitalcourage.social yeah, for protocols to succeed they need to know when to be complicated and when to get out of developers way. There's some complexity that you can do on the server side, but the client needs to be why you solve that complexity. A server can easily do things like filtering over a dataset. For a client that can be really expensive, since it means retrieving a bunch of data you don't need.

@thisismissem just stumbled over your comment here.

Why did the developers need to come up with a "schema" in the first place? Proper data modeling is hard (as you say too)

Devs can just define their JSON objects and store them on a Pod, and read them from the Pod in their app. You _can_ simply ignore the LD part here. (My students always do that first when they are already used to web dev)

Doing data modeling for LD (which we should! ) just gives you more features from the RDF world, no?

@uvdsl@w3c.social because you usually need to have some understanding of the data you work with.. database schemas exist because we like structure to things. Dealing with "any" data doesn't really allow you to build an application. It's kinda like how MongoDB's big feature was "no schema! no migrations" and sure enough people who bought into that have realised that this actually meant "all the migrations are in every single code path that you need to access data to interact with it", which ends up being costly in tech debt.

Schema simplifies things by giving you a known shape of data to work with.

@thisismissem Ah, you are assuming that the dev is also doing the data modeling. Gotcha, makes sense for Indie-Devs or small ventures.

Still, what you describe is not particular to JSON-LD. Devs can simply store their JSON objects in a Pod.

In my experience, the "confused dev" that you described above occurs when the devs are forced to use JSON-LD without understanding the basics of RDF. Proper on onboarding is crucial here, tooling like LDO and similar do exist to ease LD development ...

I mean, yeah, of course you can store arbitrary blobs in a pod, but all the tooling tries to incentivise you to use json-ld / rdf.