Re: Detailed response to Ruben's blog

Thanks Henry , this is an important point to make. So having "copies" of data like Ruben states it is actually not a problem, but a feature to express different points of views of the world. I could have a birth date in an official birth certificate, as well as in my address book and in my list of birthdays. All of these documents can have different permissions and different amounts of trust. It could even considered to be a feature that I can be able to lie about a birthdate in one document, while I could use the signed birth certificate in places where it matters.

But still the practical problems for Solid app developers persist. When does which app update what data? The brithday app and the contacts app would write to different documents and the promise of data re-use is not fulfilled. Perhaps the birthday app could have a feature to copy dates from my contacts of I give the permission, but it all leaves the problem of keeping data in sync that Ruben addresses.

Kind regards
Angelo

Sent from MailDroid

-----Original Message-----
From: Henry Story <henry.story@gmail.com>
To: public-solid <public-solid@w3.org>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Fr., 13 Jan. 2023 21:39
Subject: Re: Detailed response to Ruben's blog

Hi Melvin,

Thanks for alerting us to this discussion.

> On 12. Jan 2023, at 14:58, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> IMHO, Insightful article on Solid architecture from TimBL.  I found myself agreeing.
> 
> Worth a read.  In particular, I liked this observation:
> 
> "The Pod, in RDF terms, is a quadstore, not a triple store. A triples store is not powerful enough. The 4th part of the quad, the ID of the graph, we call a 'Document' to make it match with the way people talk. They might be called Named Graphs or Linked Data Resources but "Documents" is simpler. The fact that the ;inked data in a pod is basically a set of distinct graphs is really important."
> 
> https://www.w3.org/DesignIssues/2023/RubenBlogResponse.html


Yes, that is the key argument. Graphs stores are good for expressing one perspective
on the world, one coherent point of view. Each new relation added to the store
is one more monotonic fact added to the database. It brings with it the view of truth
as a (maximal) database of facts. Pushed to the logical conclusion we end up with a
possible world: the complete set of coherent facts about a world.

But
1. no person is perfectly consistent or knows everything
2. the world is full of competing and cooperating agents
3. truth is discovered by a dialogic process, of argument and counterargument,
  of asking for and giving reasons for one’s statement.

So just that means we need ways to seperate perspectives, statements, ...

In a plain graph database one can only deal with this inconsistency
by refusing to do reasoning. And indeed those databases don’t do reasoning.
They could not, unless they enforced one oracle to manage the truth
of all statements. That could work for one organisations, but it
won’t for the world wide web. Just think of China, Russia, US, Saudi Arabia,
Japan, Israel, Palestine, and all the other countries as agents, each of
which having very different interests and points of views. The world is
a multi-agent system since a billion years at least.

A document is a statement of something by someone in a certain mode
(could be fictional mode or factual). The fourth element of our quads
is what is needed to name the result of the act of saying something.
The same graph produced in two different places is not the same saying,
and may have very different trust properties for example, even if they
have the same meaning. The statement by a doctor that I should take some
medication does not have the same value as someone in a bar telling me to.

One can it is true accomodate multiple sayings in a graph database:
by turning the nodes for individual RDF graphs into a node of type
rdf:XMLLiteral with a content that would be an RDF/XML string. But the
nodes would be opaque to the reasoning of the rest of the graph, just as
named graphs in a quad store don’t interact, unless one asserts a number
of them to be true, or true in a world, or true in a point of view.

Next. If we look at the naming hierarchy dimension of Ruben’s argument.
Oddly Ruben only mentions the placing of files on the file system and
the naming of those hierarchied but I did not see anything about following
links to find the data. This is the error made by the Web 2.0 APIs in current
use: they set a fixed URL naming framework for placing data on the web, instead of
working with a linked data ontology, where following links is the way to
find the data. In that case the location of the data is relatively
unimportant. That is what I thought HATEOAS was about [1].

Henry

PS.

* The original blog post by Verborgh is:
  https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/

* And thanks Melving for pointing to the archived version
  https://cloudflare-ipfs.com/ipfs/QmSB8WpxXAtd3Ny9G2ZsW39RJnRsfAt2X6Q7iNTGGWo9HE

[1] https://en.wikipedia.org/wiki/HATEOAS
   "Hypermedia as the Engine of Application State"