Re: Detailed response to Ruben's blog

> On 14. Jan 2023, at 08:19, angelo.veltens@online.de wrote:
> 
> 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.

It is not just a feature, but a necessity. Solid is not about just having a POD
to store just one’s own data, but to link to data on other pods, maintained by
others. If the main use case of Solid were just to store one’s own data on one’s
own server then we could go back to the 1980s and use a PCs with Windows 3.1.

I should not be updating the telephone numbers, addresses or birthdates of my friends
on my POD, rather I should link to their profiles where they keep that information
updated. (I should of course be able to keep a historical cache of what I saw, so that
egregious changes can be spotted). How do I do that? I have my WebID link to various
typed foaf:Groups, which each link to the WebID of my friends, Colleagues, etc…
on their pods, wherever they chose to place it.

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

One way to keep things in sync is for example not to duplicate birthday information
all over the place. Should I keep track of the birthdays of the people I know, or should
they make that available? I think that should be located on each indificual’s pod
in a way that is discoverable from the WebID by following ontologies that gain traction.
That is the standards part that TimBL was referring to.

This makes even more sense for phone number, living addresses, etc… There is
a pragmatic incentive to avoid duplication of information, just because duplication
is expensive.

Now if you write apps that follow links in linked data, then where you place the data
is a lot more flexible. You could place everything in one document, say like I
do with my WebID https://bblfish <https://bblfish/>.net/people/henry/card#me

Or you could place the main information in your WebID profile and place groups
in different resources, with different protection levels presumabley,

<#me> a foaf:Person;
   foaf:name ”Henry Story”
   foaf:group [ owl:sameAs </groups/friends#>;
                a solid:FriendGroup;
                foaf:name ”Group of Henry’s Friends”
              ];
   foaf:group [ owl:sameAs <https://co-operating.systems/groups/team#> ;
                foaf:name ”Co-Operating Systems Team” ];
   foaf:group [ owl:sameAs </groups/family#> ;
                foaf:name ”Henry’s family” ];
   medical:record <https://nhs.org/2023432/> .

etc…
Using linked data it is very easy to split the data into varioos equivalent
sets of graphs in a way that would allow a client to find the data
irrespective of its layout by following links.

For that one needs good client libraries. I gave a talk end of december 2014 on
such a library
  https://github.com/banana-rdf/banana-rdf/wiki

Somehow I spent a few years then studying Category Theory to make sure I was
thinking about this right. I got back to building this where I left off then in
the past 2 years. The latest work is linked to from here:

  https://github.com/co-operating-systems/solid-control

Don’t hesitate to contact me, to get a view of where things stand.

Henry Story

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