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

st 1. 11. 2023 v 16:45 odesílatel Nathan Rixham <nathan@webr3.org> napsal:

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

I think there is a way to both give everyone what they want, and make a
very useful system that isnt overly complex.

- Allow all the forms or RDF with the right extensions .ttl .jsonld etc. --
as it is today
- Allow .json and .html -- as it is today
- Make content negotiation an extension not a MUST -- as it was in the
first 10 years of solid
- Make directory listing (ie LDP) an extension not a MUST -- as it was in
the first 10 years of solid
- Use WebID in its latest form as a spec, which is can be JSON-LD 1.1 too

As far as I can see everyone gets what they want.  The system works
beautifully, bug free with interop, test-suite compatible, and full upgrade
path to Big Solid, for those that want it.

Researchers can show case advanced features in RDF and Linked Data

Casual developers can get started with a low learning curve

The system is interoperable and extensible by design, leading to a rich
ecosystem of servers, apps and user choice


>
> Best, Nathan
>