W3C home > Mailing lists > Public > public-solid@w3.org > January 2023

Re: Detailed response to Ruben's blog

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Sun, 15 Jan 2023 02:08:44 +0100
Message-ID: <CAKaEYhKhX2mfkfH2wNTd608W-UMp6u2+BRE6+hsXd+FjGpRtqA@mail.gmail.com>
To: angelo.veltens@online.de
Cc: public-solid <public-solid@w3.org>, Henry Story <henry.story@gmail.com>
so 14. 1. 2023 v 8:19 odesílatel <angelo.veltens@online.de> napsal:

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

In Solid different quads are different data

Conversely the same quads are the same data

Quad reuse is through client-client standards

> Kind regards
> Angelo
> Sent from MailDroid <https://goo.gl/ODgwBb>
> -----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"
Received on Sunday, 15 January 2023 01:09:09 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 15 January 2023 01:09:10 UTC