- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 14 Feb 2023 11:02:09 -0500
- To: public-solid@w3.org
- Message-ID: <15414e9a-b8a6-5392-d509-7e6e64990b08@openlinksw.com>
On 2/10/23 8:56 PM, Melvin Carvalho wrote:
>
>
> út 17. 1. 2023 v 15:55 odesílatel Kingsley Idehen
> <kidehen@openlinksw.com> napsal:
>
>
> On 1/15/23 8:12 AM, Henry Story wrote:
>
>
> Hi Henry and others,
>
>
> >> 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.
>
>
> Yes, the goal is to have a system rooted in unambiguous identity
> which
> is what identifiers constructed using Linked Data principles are
> about
> -- fundamentally.
>
>
> > 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.
>
>
> Yes, I always believed Solid was about applying Linked Data
> principles
> to read-write operations associated with a Data Space / Pod.
>
> As per Windows 3.1 analogy, that's how life was before global
> adoption
> of the HTTP protocol that enabled the World Wide Web.
>
>
> >
> > 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.
>
>
> Yes, there are specific machine computable relationship type
> (relations)
> semantics for handling personally identifiable information e.g.,
> inverse
> functionality as per the owl:InverseFunctional property type
> defined in
> the OWL Ontology.
>
> Basically, reconciling disparate identities is a reasoning and
> inference
> matter.
>
>
> Thanks Kingsley 💯
>
> Possibly warrants a new thread, but do you have some modern examples
> of how InverseFunctinoal properties (IFP) can work in the real world?
>
> It seems to be that there is a lot of value here in being able to
> stitch together different pieces of software and giving users a better
> experience, and integration with the social web
>
> I am aware of how it works in tabulator / mashlib (solidOS) with
> smushing, FOAF and other historical patterns +
> https://www.w3.org/wiki/InverseFunctionalProperty
>
> Do you have a recipe or example of how IFPs are currently deployed in
> "production"?
Hi Melvin,
Yes, it boils down to a server applying reasoning and inference informed
by the entity relationship type semantics of an inverse-functional
relation. For instance, foaf:mbox is well defined for making such
inferences.
Related
1.
https://medium.com/virtuoso-blog/using-a-semantic-web-of-linked-data-to-reconcile-disparate-identities-83ab7a315568
2.
https://github.com/OpenLinkSoftware/SPASQL-Utility-Showcase-Queries/blob/master/kidehen-ifp-reasoning-test.sql
Kingsley
>
>
> > (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.
>
>
> Yes.
>
>
> >
> >> 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
>
>
> As per my comment above, tools need to understand the importance of
> unambiguous identity, identity authenticity, access controls, and
> reasoning informed by relations semantics.
>
> I've always seen Solid as an effort to simplify loose-coupling of the
> following items for app developers:
>
> 1. Identity -- via identifiers constructed using Linked Data
> principles
> 2. Identification -- credentials (or profile) documents comprising
> relations where subject and objects are denoted by identifiers
> (constructed using Linked Data Principles)
> 3. Authentication -- various protocols for verifying credentials
> 4. Authorization -- access controls informed by reasoning and
> inference
> applied to identity principals, groups, and resources
> 5. Storage -- Filesytem or DBMS modalities
>
> IMHO, these issues shouldn't be contentious circa 2023.
>
> Happy New Year!
>
> Kingsley
>
> >
> >> 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"
> >>
> >>
> >>
> >>
> >>
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog:
> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
> http://kidehen.blogspot.com
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
> :
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>
>
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Home Page:http://www.openlinksw.com
Community Support:https://community.openlinksw.com
Weblogs (Blogs):
Company Blog:https://medium.com/openlink-software-blog
Virtuoso Blog:https://medium.com/virtuoso-blog
Data Access Drivers Blog:https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
Personal Weblogs (Blogs):
Medium Blog:https://medium.com/@kidehen
Legacy Blogs:http://www.openlinksw.com/blog/~kidehen/
http://kidehen.blogspot.com
Profile Pages:
Pinterest:https://www.pinterest.com/kidehen/
Quora:https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter:https://twitter.com/kidehen
Google+:https://plus.google.com/+KingsleyIdehen/about
LinkedIn:http://www.linkedin.com/in/kidehen
Web Identities (WebID):
Personal:http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
:http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 14 February 2023 16:02:26 UTC