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

On Wed, Nov 1, 2023 at 1:30 PM Jonas Smedegaard <jonas@jones.dk> wrote:

> Quoting Nathan Rixham (2023-11-01 13:07:22)
> > Pivot back, and we get HTTP+URL+[ONE-THING] = web of data.
> > What is the most widely utilized data bearing media type on the broad
> > internet / web? JSON
> > How do you make it more webby? add first class support for URLs
> > How do you make it widely understandable in a shared manner? add GETable
> > schema's.
>
> Seems we disagree on the very goal.
>
> I agree that with a goal of "web of data" the natural choice is
> replacing document-oriented HTML with efficiently-memory-dumpable JSON.
>
> I just assume the different goal of "web of semantic data", where the
> natural ONE-THING is not JSON but RDF.
>
> RDF is a ONE-THING with multiple serializations, and I really thought
> that we all along agreed that this discussion was about which of the RDF
> serializations, not about ditching RDF altogether.
>

At the abstract level it's a one-thing, and at the concrete syntax level,
it's multiple. To remove the conneg requirement and get something lite, you
need one concrete syntax only.

So which?

I'm personally all for being viewable as RDF, that is translatable at
either side of the transfer protocol interface, such that implementations
either side are not constrained and can reap the real benefits of URIs, and
implied benefits of machine readable ontologies, from typed data validation
through to machine understanding, and the logical implications which can be
entailed via rules when you do so. Such that anybody can use a flat file or
an rdbms, document store, graph, whatever.

Herein though lays the eternal blocker, agreeing on one concrete syntax,
and factoring in the nuances of them which have crept to being tooling
requirements by being each having to be compatible with the base abstract
model of rdf, itself composed from the nuances of designing around each
historical rdf media type.

Whichever is selected, if that's even possible to agree within a group to
select one, there will still be legacy issues to deal with which will
complicate implementations for those hitting the spec from other tech areas
of the web, where they'll make concessions and be non-conformant giving
unexpected results, or where they'll try to cover all the requirements of
the concrete syntax and get lost in the details trying to implement.

Let's pick one at random, JSON-LD, let's say it's the one-thing, now every
implementor coming from the wild must conform to
https://www.w3.org/TR/json-ld/ instead of https://www.json.org/json-en.html,
then you use a bit of LDP and need to implement turtle, because to be LDP
conformant you MUST respond with turtle if it's requested, and you're back
to MUST conneg.

See the issue here?

You cannot have a solid lite which includes RDF, because the second you do,
you must support conneg and multiple concrete syntax types.

Simply, solid-lite which requires RDF results in full solid.