- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 21 Feb 2023 11:02:40 -0500
- To: public-solid@w3.org
- Message-ID: <d2c696cd-00e0-ad83-08d3-56a9b546955a@openlinksw.com>
On 2/20/23 4:48 AM, Melvin Carvalho wrote:
>
>
> út 14. 2. 2023 v 17:03 odesílatel Kingsley Idehen
> <kidehen@openlinksw.com> napsal:
>
>
> 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
>
>
> Thanks Kingsley, that's a great blog post.
>
> I like the way it ties together different identities (webid, twitter,
> linkedin) -- I think this has a lot of value
>
> It seems to me from the profile point of view you just add a predicate
> from a vocab, and the vocab uses owl. The rules was inserted, but I
> think can be inferred from the library, such as SolidOS. Then the
> query or lookup uses those inferencess. Again I think SolidOS could
> do this, I'd need to check.
>
> The example you gave was with foaf:mbox with solid/webID
>
> There is an issue with using foaf mbox in that
> - not everyone likes to make their mbox public
> - there are other identifiers that people use that are IFP
>
> We are also missing a predicate to use your webid/solidID itself as a
> predicate from another profile, would that be a useful IFP?
Hi Melvin,
Co-reference is handled via an owl:sameAs relation.
Example
{ <mySolidWebID> owl:sameAs <some-other-dataspace-netid>} .
Other relations can be designated as being inverse-functional too, if
you want the owl:sameAs relation inferred -- as long as said relation is
that way inclined.
Everything is in place, tools just need to make use of the relations
that exist based on semantics defined in their respective ontologies --
IMHO .
Kingsley
>
>
> 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
>
--
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, 21 February 2023 16:02:59 UTC