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

Hello,

I very am very strongly in favor of Linked Data. We tried social
networking without linked data already. There are a lot of existing
projects that use a certain form of extensible JSON without linked data
(or XML for that matter), and they ultimately fail to get much
popularity because interoperability becomes too hard after a certain
point, each schema being both too complex and too simple for everyone
to agree on it. The result is, the social network is fragmented between
applications that do things that standardize differently.

That being said, the Linked Data Platform actually supports non-linked-
data quite well. The only problem we have is:

  - the profile;
  - the basic containers.

I will leave ACL alone, because i think a lite specification where
every resource is either private to the owner or publicly readable can
already achieve some good.

Non-linked-data applications need to:

1. Find the root storage, given a webid, where they can write files. 
Then, a non-interoperable non-linked data application can just write
its preferences to "<storage>/my-application/preferences", and start
processing its data under other well-known names. It can write non-RDF
sources as JSON with a specific schema. It can also peek into data
collected by other non-linked-data applications, if it thinks it can
achieve interoperability that way;

2. Find the OIDC issuer, given a webid;

3. Maybe discover the user name and other general information, although
I don’t think it is critical for the application to discover it instead
of asking the user;

4. List the resources in a container, so that other applications can
just drop data in a container without having to register these files in
an index.

Currently, 1. is already available: you just HEAD the profile document,
and look for a http://www.w3.org/ns/pim/space#Storage HTTP link. 2. can
use a Link header too, and 3. could if we wanted to.

As I understand, Solid specification for Basic Containers is the
metadata for a container is not user-parametrable, it is 100% computed
dynamically.  So we could also mandate that the basic containers
respond to content negociation with a JSON representation of these
metadata, and we would have 4.

Now, in the other direction, linked-data applications in a non-linked-
data server may need content negociation, although now we can have RDF
in (X, please)HTML pages so the machines can read ontologies even in
human-readable documents. We however need to have a consistent RDF
control over the profile and RDF resources. This means that non-rdf
application forbid themselves to modify the profile and resources that
are not non-RDF JSON with a schema they understand.  A non-RDF server
may work for RDF applications, if:

1. It can generate RDF metadata for containers (serve containers both
as JSON and RDF);
2. It can serve HTTP Link headers for the profile document (storage,
OIDC issuer);
3. It remembers the content-type of resources, so that non-linked-data
and linked-data applications can cohabit peacefully.

(Also, I wanted to say about the database vs filesystem debate, that
it’s not easy to get a Last-Modified value for a filesystem directory
that only changes when the list of files change, so maybe we should
rather use ETags.)

Best regards,

Vivien

Received on Wednesday, 1 November 2023 08:18:26 UTC