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

út 31. 10. 2023 v 23:14 odesílatel Nathan Rixham <nathan@webr3.org> napsal:

> On Tue, 31 Oct 2023, 20:33 Kingsley Idehen, <kidehen@openlinksw.com>
> wrote:
>
>> I encourage you to think in terms of storage abstraction where DBMS
>> (Tables or Graph based Relations) vs Filesystems are implementation details.
>>
>>
>> Solid should be storage agnostic leaving such details to server
>> implementers. As you can already see, whenever the discussion steps out of
>> the appropriate abstraction layer -- confusion reigns supreme.
>>
> Agree, however being both storage agnostic and media type agnostic (RDF)
> is a big set of requirements for a 'lite' anything.
>
> Perhaps the benefits of being just a protocol, outweigh those of being
> many-typed.
>
> Perhaps such a solidy/readwrite-webby thing based on a strict subset of
> json-ld (json with schema and uri support via id + properties via the
> curies/schema) would be enough to simplify to something broadly
> implementable, simple to specify, and still viewable as rdf.
>

Serializations is going to be one of the key questions.  They json-ld
subset approach is quite common at the W3C these days, following on from
activitypub.  However I think the activitypub model could be much more
closely aligned with Solid.  For example HR15 style fragids are in the AP
spec, but not used in practice.  Solid Lite could support fragids in the
profile examples.  The AP context contains some weird things such as the
default vocab is a bnode, we can likely make a better context than this.
The OWL vocabulary is missing and non normative in AP and missing.  A form
of JSON-LD that is well aligned with Solid's clean data models, could offer
a lot of advantages over current w3c standards, and also be interoperable
with both AP and Solid, and also schema.org as kind of a middle ground.
All up for discussion, but I've thought for a while something like this
would be great for web developers.


>
> Not to rewind the conversation by a decade or anything.
>
> Best, Nathan
>