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

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

> Quoting Nathan Rixham (2023-11-01 15:18:22)
> > 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.
>
> Why is mandating a single serialization *needed*?
>

To remove the conneg requirement, and the implied requirement that any
implementation must support full rdf, and the entailed requirements of
being able to store abstract rdf then recompose it to various concrete
syntaxes.


> I do not recognize that the web of semantic data inherently *need* a
> single mandated RDF serialization.  I recognize how ignoring
> complexities of some aspects can simplify working with other aspects,
> and I respect if some decide to explore a reduction of solid where RDF
> is omitted, despite me personally viewing RDF as the center piece.
>

How do you ignore complexities (part of RDF) and still conform to
supporting it?


> What I do not understand is the argument that it is not a balancing act.
>

As above.

That we MUST mandate a serialization.  We mandated zero graphics
> serializations for the web of documents, why is this any different?
>

Web of Linked Data, to form the web network of it you require a default
type which supports links. The focus on HTML because it was the dominant
link providing type, link to a gif and it's a dead end.

You might argue that graphics is optional for the web of documents, but
> do you then imply that RDF is optional for the web of semantic data, or
> that solid-lite is not about semantic data?
>

I certainly imply that you can do linked data and a semantic web, viewable
as rdf, without enforcing rdf concrete syntaxes. At the simplest level, if
you can establish a subject in a well defined manner, map a property to a
URI for shared schemas, and have a value which can be a URI, you have
linked data.


> > Simply, solid-lite which requires RDF results in full solid.
>
> No, but a solid-lite which requires a single RDF serialization results
> in a fuller solid.
>

A key point missed here, is what limitations are imposed by specifying a
single type, which parts of the rdf-stack of specs cannot then be used
because they require multiple type support? such as the LDP example
mentioned previously.

If you keep the support multiple rdf types (which is usually entailed by
requiring just one type), what parts of solid-full can you remove in order
to create a notably smaller and easier to implement solid-lite?

You could also argue that the complexities of solid, come from using rdf
based types which handle the complexities of being multi-typed, that is,
the very use of RDF is what makes it complicated.

Consider if it had been JSON+Links from the start only, what would you
require over basic HTTP verbs, would there even be a solid, or would it
just be spec an ident/auth mechanism and some vocabs.

Interesting conversation Jonas,

Best, Nathan